Re: subversion license, formal determination of Free/Open

[Stefan Sperling <st...@elego.de>]

On Thu, Apr 30, 2009 at 01:31:07PM -0400, David Weintraub wrote:
> I see no reason why you couldn't package Subversion. There isn't even
> a requirement that you have to package the Subversion source code as a
> package. You can submit the Subversion license to the Open Source
> Institute or the FSF, but I have a feeling that these organizations
> would need CollabNet to be the submitter.

Packagers need to take into account that scripts in contrib/ may
have different licenses than the rest of the distribution.
Beware: Some of contrib/ does not even have a license, and we're
contemplating removing those scripts.

Greg, you could mark Subversion (except for stuff from the contrib directory)
as "Apache 1.1" license, if you really need to use a standard OSI-approved
license name. Subversion's license is essentially Apache 1.1 with customizations
that (IIRC) mostly or exclusively relate to trademark stuff.

We recognise that the custom license is a nuisance, and the project plans
to switch to Apache 2.0 soon for that reason.

Stefan

> On Wed, Apr 29, 2009 at 7:48 PM, Greg Troxel <gd...@ir.bbn.com> wrote:
> > I maintain the packaging entries for subversion in pkgsrc, the native
> > packaging system on NetBSD and Dragonfly, and also widely used on mac
> > and solaris.  Previously, we marked non-Free software with a LICENSE=
> > variable so that people could refrain from accidentally building it.
> > Now, we are adding free software licenses to the system, but with a
> > default that the build will proceed for licenses that are either Free
> > per FSF or Open Source per the Open Source Institute.
> >
> > I see many places on the net that claim that subversion is
> > licensed under the apache license:
> >
> >  http://directory.fsf.org/project/subversion/
> >  http://en.wikipedia.org/wiki/Subversion_(software)
> >
> > But, the COPYING file is different (also at
> > http://subversion.tigris.org/license-1.html).
> >
> > COPYING contains an obviously reasonable non-copyleft license,
> > apparently "modified BSD" plus the advertising clause for documentation
> > only, plus a prohibition on using "Tigris" as part of the name of a
> > derived work.  So that seems clearly Free and Open Source.
> >
> > But I can't find the subversion license at:
> >
> >  http://opensource.org/licenses/alphabetical
> >  http://www.fsf.org/licensing/licenses/
> >
> > It seems, however, that the subversion 1.0 license is identical to the
> > apache 1.1 license:
> >
> >  http://www.apache.org/licenses/LICENSE-1.1
> >
> > So do I have this right?  Would it make senes to submit the subversion
> > license for review to FSF and OSI?  If not, it might be good to call it
> > the apache 1.1 license, or at least point out that it is the same terms
> > but merely with different names.
> >
> >    Thanks,
> >    Greg
> >
> > ------------------------------------------------------
> > http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1987643
> >
> > To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
> 
> 
> 
> -- 
> David Weintraub
> qazwart@gmail.com
> 
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1998465
> 
> To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

Re: subversion license, formal determination of Free/Open

[Greg Troxel <gd...@ir.bbn.com>]

Stefan Sperling <st...@elego.de> writes:

> On Thu, Apr 30, 2009 at 01:31:07PM -0400, David Weintraub wrote:
>> I see no reason why you couldn't package Subversion. There isn't even
>> a requirement that you have to package the Subversion source code as a
>> package.

It's been packaged for a long time...  I'm just trying to clean up
license designations in pkgsrc.  pkgrsc has no notion of "source
package".  The control files refer to the original sources released by
the upstream maintainers (DISTFILE), and then have any necessary patches
and code to build the package.  But we do mark DISTFILES as
non-redistributable when licensing prohibits distribution.

>> You can submit the Subversion license to the Open Source
>> Institute or the FSF, but I have a feeling that these organizations
>> would need CollabNet to be the submitter.

Now that I've convinced myself it's the same license as apache-1.1 I
don't feel the need, especially if svn moves away from 1.1.

> Packagers need to take into account that scripts in contrib/ may
> have different licenses than the rest of the distribution.
> Beware: Some of contrib/ does not even have a license, and we're
> contemplating removing those scripts.

Good point.  But, it seems the contents of contrib does not get
installed, so the binary package won't have those bits.  The
subversion-base package on my system has

/usr/pkg/bin/svn
/usr/pkg/bin/svnadmin
/usr/pkg/bin/svndumpfilter
/usr/pkg/bin/svnlook
/usr/pkg/bin/svnserve
/usr/pkg/bin/svnsync
/usr/pkg/bin/svnversion
/usr/pkg/share/doc/subversion/INSTALL
/usr/pkg/share/doc/subversion/README
/usr/pkg/share/doc/subversion/cvs-crossover-guide.html
/usr/pkg/share/doc/subversion/lj_article.txt
/usr/pkg/share/doc/subversion/svn-best-practices.html
/usr/pkg/share/examples/subversion/backup/hot-backup.py
/usr/pkg/share/examples/subversion/cgi/tweak-log.cgi
/usr/pkg/share/examples/subversion/hook-scripts/commit-email.pl
/usr/pkg/share/examples/subversion/hook-scripts/svnperms.conf.example
/usr/pkg/share/examples/subversion/hook-scripts/svnperms.py

plus includes, libs, locale files.

It would be good to clean up the distfile to remove all unlicensed bits,
and maybe go so far as put bits not licensed under apache-1.1 or public
domain to another contrib tarball.

> Greg, you could mark Subversion (except for stuff from the contrib
> directory) as "Apache 1.1" license, if you really need to use a
> standard OSI-approved license name. Subversion's license is
> essentially Apache 1.1 with customizations that (IIRC) mostly or
> exclusively relate to trademark stuff.

Thanks - I have done that.  The customizations are really not in license
terms, just substitution of names of entities, so from the pkgsrc POV
it's the same license.

> We recognise that the custom license is a nuisance, and the project plans
> to switch to Apache 2.0 soon for that reason.

It was more confusing - if you called it the Apache 1.1 license it would
be fine.  But apache-2.0 is recognized as Free/Open so that's perfectly
fine too.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2046500

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].