[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: subversion license, formal determination of Free/Open

From: Greg Troxel <gdt_at_ir.bbn.com>
Date: Sun, 03 May 2009 11:00:51 -0400

Stefan Sperling <stsp_at_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_at_subversion.tigris.org].

  • application/pgp-signature attachment: stored
Received on 2009-05-03 17:01:51 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.