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

Re: CVS update: subversion/subversion/libsvn_client add.c apply_edits.c checkout.c client.h commit.c delete.c status.c update.c

From: Karl Fogel <kfogel_at_galois.collab.net>
Date: 2000-11-22 20:15:41 CET

Ah, Greg H -- okay, I understand the complaint, although (in fact) it
wouldn't bother me if AOL/Netscape did that, because my original code
would still be free and I would presume their proprietary fork would
die off, as all such do. :-)

In any case, the specific license at issue here is the CollabNet
license, which already allows proprietary forks. Is there any
Subversion contributor who is worried about a possible future version
of the CollabNet license, and if so, why? If there's a scenario in
which CollabNet could change the license and cause your code to be in
a situation you don't want, then we shouldn't allow retroactive
license changes.

But at the moment, considering the current nature of the CollabNet
license, I can't think of such a scenario. Can anyone else?

-K

Greg Stein <gstein@lyra.org> writes:
> Not true. Most of those phrases say that you can release the code under the
> later license. In essence, you can make all of your changes and then release
> under Vn+1, thus disallowing people to use Vn for your changes.
>
> You're right that it doesn't affect *existing* developers/users. It affects
> changed/later versions of the software.
>
> Go back to the AOL/Netscape scenario. Let's say that they change the license
> to permit no copying and to no longer be Open Source. Now, let's say that
> they change a couple things in the browser: 1) eliminate some kind of
> compatibility [to create locking], and 2) add some really cool feature that
> users want. Now you have a scenario where their marketing engine is going to
> flood the market with a lockin-browser, and you have to duplicate their work
> to get the cool feature. And you have no source to do it. And you're a major
> contributor to Mozilla, and they went and did this with *your* work.
>
> Wouldn't that piss you off?
>
> Personally, I like to contribute to software under a license that I know
> will apply to everybody. I don't want that license to magically change
> underneath me, to something that I disagree with.
>
> Now, I recognize most of this is philosophical because it is all presumptive
> on CollabNet issuing a later version of the license that is draconian. But
> the philosophy is still important [to me]. Consider the evil case where
> CollabNet gets sucked up by their big buddy Sun. Sun says "wow, everybody on
> the 'Net is using SVN. Let's take advantage of that." They issue a new
> license with the evil form. Then they start updating and releasing new
> copies of SVN. Fine, no problem, you say... we just fork. But when we fork,
> we're still doing it with the "or later version" phrase in there! Sun could
> continue to take our work, integrate it into theirs, and release it under
> their V2 Draconian license.
>
> The counter case is if the license said "V1 only". We could fork and develop
> under the old license. Sun could not take our work and put it into their V2
> licensed software.
>
> Again, this is philosophy. But those darn licenses are philosophy to start
> with. They haven't and probably won't ever get tested in court. But if we're
> going to put pure philosophy into our code, then let's do it right.
>
> Cheers,
> -g
>
> On Wed, Nov 22, 2000 at 12:55:01PM -0600, Karl Fogel wrote:
> > Greg, those retroactive later-version licenses don't work the way
> > you're saying.
> >
> > Once you've released code under a particular license, no one can take
> > those terms away. However, you can give people the *option* of using
> > your code under a different license, or not (that's the "this version
> > X, or any later version" clause).
> >
> > Thus, people will always have whatever rights you originally released
> > the code under -- CollabNet cannot change that later. However, you'd
> > be explicitly granting them the right to *choose*, later on, to use
> > some other terms. Since our current license already permits
> > proprietary forks, this can't result in anything too awful. But it
> > does give CollabNet the ability to retroactively rerelease things
> > under even more liberal terms in the future.
> >
> > The scenarios you describe below don't happen:
> >
> > Greg Stein <gstein@lyra.org> writes:
> > > As a user of software, I really dislike that "any later version" phrase.
> > >
> > > *) consider the NPL/MPL: it has this "feature". Are you happy contributing
> > > to that project, knowing that AOL/Netscape can release a new NPL/MPL that
> > > says "nobody can copy this software without paying us our licensing fee"
> > > and attach it to the code you wrote? If you were a user, would you
> > > appreciate new licensing that said you must pay for using Mozilla?
> >
> > But that's not what happens, because you still always have the option
> > of choosing the earlier (original) terms. In fact, you (the user) get
> > to select whichever version of the license you like the most, from all
> > the versions since the earliest, inclusive.
> >
> > > *) consider the GPL: are you happy to contribute to that, knowing that RMS
> > > could release GPL V3 that states that you can only use the software on
> > > systems that contain zero proprietary software? He could do it, and
> > > software authors could elect to use V3 and there isn't much you can do
> > > about it since it *said* they could do that.
> >
> > Same rebuttal.
> >
> > > *) Linus removed that "any later version" phrase from (his portions of)
> > > Linux because he wasn't sure what RMS was going to do in V3, and he
> > > didn't want those changes to magically apply to his software.
> >
> > Same.
> >
> > > I say that software should be released under a specific license. If you want
> > > to change the license, then re-release the software with the change. Let the
> > > people decide whether they want to use the new or old license.
> > >
> > > But this whole "hey, we can change it" is a bit scary for developers and
> > > users of the software.
> >
> > Not scary if you realize all the options available to every user.
> >
> > -K
>
> --
> Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:15 2006

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

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