[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: David Weintraub <qazwart_at_gmail.com>
Date: Thu, 30 Apr 2009 13:31:07 -0400

A lot of projects simply write their own licenses, and it looks like
Subversion took this route. There are basically two types of OSS
licenses. The first is the BSD style license. This license merely
requires you give credit where credit is due. If you like to fork the
project and add a bunch of proprietary stuff, you are free to do so.

The other style is much more restrictive. It states that any changes
you make must also be open source. This is even true if you fork the
project and make your own changes. All changes you make must also be
under the same style OSS license. The GPL license is of this style.

There are several other issues involved too: Can you protect your
copyrights and trademarks (GPL doesn't allow you to do this)? What
about patent claims?

There are a lot of clashes between these two camps of licenses. The
BSD style guys claim that their license is more open and truly free.
The GPL style guys claim that someone could "steal" an OSS project by
forking the project, adding in their proprietary code, and making that
project non-open source. Thus, your OSS project will languish while
newer features will be placed into the proprietary project.

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.

On Wed, Apr 29, 2009 at 7:48 PM, Greg Troxel <gdt_at_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_at_subversion.tigris.org].

-- 
David Weintraub
qazwart_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1998465
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-04-30 19:32:13 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.