You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@lyra.org> on 2000/11/16 23:10:18 UTC
Re: CVS update: subversion/subversion/libsvn_client add.c apply_edits.c checkout.c client.h commit.c delete.c status.c update.c
Look for more license fixups in a while. Stepping out for some errands now.
Cheers,
-g
On Thu, Nov 16, 2000 at 11:00:53PM -0000, gstein@tigris.org wrote:
> User: gstein
> Date: 00/11/16 15:00:53
>
> Modified: subversion/tests-common svn_test_editor.c
> subversion/libsvn_ra_dav commit.c fetch.c ra_session.h
> session.c
> subversion/libsvn_ra_dav/tests ra-dav-test.c
> subversion/libsvn_client add.c apply_edits.c checkout.c
> client.h commit.c delete.c status.c update.c
> Log:
> fix URL in license. should be: http://www.Collab.Net/
--
Greg Stein, http://www.lyra.org/
Re: SVN licensing (was: Re: CVS update: ...)
Posted by Brian Behlendorf <br...@collab.net>.
On Thu, 16 Nov 2000, Greg Stein wrote:
> Answer: don't refer to a *file*. Refer to a URL that contains the
> license. As the sole owner/admin of that URL space, you can make sure
> that the URL always contains the proper license.
>
> I would also recommend versioning the license URL. I do this with mod_dav,
Excellent ideas. I'm asking our legal now if there's any reason not to do
this. Of course, the question of "what happens if the URL goes away" may
become relevant. =)
Brian
SVN licensing (was: Re: CVS update: ...)
Posted by Greg Stein <gs...@lyra.org>.
Two comments on this:
1) You [CollabNet] are effectively the owner of the Copyright on Subversion.
If you're comfortable with referential license, then we can definitely do
it that way.
2) Personally, I feel it is more than sufficient to use that approach:
a) The file asserts a Copyright. By virtue of Copyright law, a person
cannot make any copies at all. The license is what gives them those
rights, so a strict reading of the file itself (without reference to
the LICENSE file) will give them NO rights.
b) A reference in the file to the LICENSE is what provides the ability to
make copies.
However, Roy has a point here about "what happens when the file is
outside of the package with the LICENSE file?" Even worse, what
happens if somebody repackages with a LICENSE that states something
funny?
Answer: don't refer to a *file*. Refer to a URL that contains the
license. As the sole owner/admin of that URL space, you can make sure
that the URL always contains the proper license.
I would also recommend versioning the license URL. I do this with mod_dav,
referring people to http://www.webdav.org/mod_dav/license-1.html. Should I
desire to change the license in the future, I can change it to
license-2.html and release the software with the new reference. Anybody with
the old software still refers to license-1.html and can work with it under
that license.
Note: I started on the license updating below because I found some files in
subversion/client/ that had the *wrong* license. Not just typos or tweaks,
but flat out wrong. I wrote a script to find all the problematic files and
have been tweaking those; just not at the client files yet.
In any case, I'll continue with the tweaking of the licenses until I hear
that you would prefer a reference-style of license (which I believe is a
Good Thing and would recommend).
Cheers,
-g
On Thu, Nov 16, 2000 at 03:55:44PM -0800, Brian Behlendorf wrote:
>
> Thanks tons, Greg.
>
> I'd certainly be fine with putting the license in a single file and
> referring to that at the top of each source file, instead of duplicated
> elsewhere; Roy Fielding argued against this with Apache code because it'd
> make it easier for someone to accidentally not follow the license, he
> claimed (imagine someone getting a .c file but not a copy of
> LICENSE). Thoughts?
>
> Brian
>
> On Thu, 16 Nov 2000, Greg Stein wrote:
> > Look for more license fixups in a while. Stepping out for some errands now.
> >
> > Cheers,
> > -g
> >
> > On Thu, Nov 16, 2000 at 11:00:53PM -0000, gstein@tigris.org wrote:
> > > User: gstein
> > > Date: 00/11/16 15:00:53
> > >
> > > Modified: subversion/tests-common svn_test_editor.c
> > > subversion/libsvn_ra_dav commit.c fetch.c ra_session.h
> > > session.c
> > > subversion/libsvn_ra_dav/tests ra-dav-test.c
> > > subversion/libsvn_client add.c apply_edits.c checkout.c
> > > client.h commit.c delete.c status.c update.c
> > > Log:
> > > fix URL in license. should be: http://www.Collab.Net/
> >
> >
>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> CollabNet | open source | do what's right | now hiring
>
--
Greg Stein, http://www.lyra.org/
Re: CVS update: subversion/subversion/libsvn_client add.c apply_edits.c checkout.c client.h commit.c delete.c status.c update.c
Posted by Karl Fogel <kf...@galois.collab.net>.
Whoa -- thanks for pointing this out, otherwise I would probably have
gone off and written a sed script or something. I'll use the python
script, when the time comes.
Greg Stein <gs...@lyra.org> writes:
> On Fri, Nov 17, 2000 at 12:14:29PM -0600, Karl Fogel wrote:
> > Karl Fogel <kf...@galois.collab.net> writes:
> > > Unless anyone objects, I'll make every file refer to the COPYING file
> > > and to a URL. That should be sufficient.
> >
> > Okay, Brian: I'll hold off on this until I hear a confirmation from
> > you that the legal dept is okay with it, and whether or not there's a
> > particular URL you want to use.
>
> Note that it is a simple tweak of my check-license.py script to do this
> replacement. Now that every .c and .h file has the *exact* same text, it is
> a simple, error-free, automatic replacement should we choose to do so.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
Re: CVS update: subversion/subversion/libsvn_client add.c apply_edits.c checkout.c client.h commit.c delete.c status.c update.c
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Nov 17, 2000 at 12:14:29PM -0600, Karl Fogel wrote:
> Karl Fogel <kf...@galois.collab.net> writes:
> > Unless anyone objects, I'll make every file refer to the COPYING file
> > and to a URL. That should be sufficient.
>
> Okay, Brian: I'll hold off on this until I hear a confirmation from
> you that the legal dept is okay with it, and whether or not there's a
> particular URL you want to use.
Note that it is a simple tweak of my check-license.py script to do this
replacement. Now that every .c and .h file has the *exact* same text, it is
a simple, error-free, automatic replacement should we choose to do so.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: CVS update: subversion/subversion/libsvn_client add.c apply_edits.c checkout.c client.h commit.c delete.c status.c update.c
Posted by Karl Fogel <kf...@galois.collab.net>.
Karl Fogel <kf...@galois.collab.net> writes:
> Unless anyone objects, I'll make every file refer to the COPYING file
> and to a URL. That should be sufficient.
Okay, Brian: I'll hold off on this until I hear a confirmation from
you that the legal dept is okay with it, and whether or not there's a
particular URL you want to use.
-K
Re: CVS update: subversion/subversion/libsvn_client add.c apply_edits.c
checkout.c client.h commit.c delete.c status.c update.c
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Karl Fogel wrote:
>
> Unless anyone objects, I'll make every file refer to the COPYING file
> and to a URL. That should be sufficient.
Check with Jon Stevens <jo...@latchkey.com>; his father is an
attourney, and Jon's been working out with him what these
things should look like for Apache.
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>
Re: CVS update: subversion/subversion/libsvn_client add.c apply_edits.c checkout.c client.h commit.c delete.c status.c update.c
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Nov 22, 2000 at 04:21:22PM -0500, Greg Hudson wrote:
> > As a user of software, I really dislike that "any later version"
> > phrase.
>
> The situations you describe are only troublesome for a license like
> the GPL, which tries to keep the software free. The collab.net
> license does not try to keep the software free; I could already make
> changes and release the modified code (including stuff you wrote)
> under the Pay Greg Hudson $100 Per Use License or whatever.
That isn't the scenario that concerns me. Please see my recent response to
Karl.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: CVS update: subversion/subversion/libsvn_client add.c apply_edits.c
checkout.c client.h commit.c delete.c status.c update.c
Posted by "Jonathan S. Shapiro" <sh...@cs.jhu.edu>.
A point of clarification:
Because users can always continue to use an older license, it is only
possible under this scheme for terms to become more liberal as new
licenses are created.
Jonathan
Karl Fogel wrote:
>
> 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).
>
> ...But it
> does give CollabNet the ability to retroactively rerelease things
> under even more liberal terms in the future.
Re: CVS update: subversion/subversion/libsvn_client add.c apply_edits.c checkout.c client.h commit.c delete.c status.c update.c
Posted by Karl Fogel <kf...@galois.collab.net>.
I've read those, and don't see what the problem or worry is.
?
-K
Mo DeJong <md...@cygnus.com> writes:
> Some might point to the Python license problems as a cautionary tale.
> It seems like exactly the sort of scenario that would worry me.
>
> http://linuxtoday.com/news_story.php3?ltsn=2000-09-07-011-21-OS-CY-SW
> http://www.python.org/1.6/license_faq.html
>
> Mo DeJong
> Red Hat Inc
Re: CVS update: subversion/subversion/libsvn_client add.c apply_edits.c checkout.c client.h commit.c delete.c status.c update.c
Posted by Mo DeJong <md...@cygnus.com>.
On 22 Nov 2000, Karl Fogel wrote:
> 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
Some might point to the Python license problems as a cautionary tale.
It seems like exactly the sort of scenario that would worry me.
http://linuxtoday.com/news_story.php3?ltsn=2000-09-07-011-21-OS-CY-SW
http://www.python.org/1.6/license_faq.html
Mo DeJong
Red Hat Inc
Re: CVS update: subversion/subversion/libsvn_client add.c apply_edits.c checkout.c client.h commit.c delete.c status.c update.c
Posted by Karl Fogel <kf...@galois.collab.net>.
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 <gs...@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 <gs...@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/
Re: CVS update: subversion/subversion/libsvn_client add.c apply_edits.c checkout.c client.h commit.c delete.c status.c update.c
Posted by Greg Stein <gs...@lyra.org>.
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 <gs...@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/
Re: CVS update: subversion/subversion/libsvn_client add.c apply_edits.c checkout.c client.h commit.c delete.c status.c update.c
Posted by Karl Fogel <kf...@galois.collab.net>.
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 <gs...@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
Re: CVS update: subversion/subversion/libsvn_client add.c apply_edits.c checkout.c client.h commit.c delete.c status.c update.c
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Nov 22, 2000 at 12:28:04PM -0800, Brian Behlendorf wrote:
> On 22 Nov 2000, Karl Fogel wrote:
> > Brian Behlendorf <br...@collab.net> writes:
> > > So the word back from our legal counsel is this is cool; we should put a
> > > copy of the license on subversion.tigris.org, version-numbered (so,
> > > perhaps, http://subversion.tigris.org/license_1.html), and each file
> > > reference both COPYING and the URL, and it's all good.
> >
> > Will do. I will say that each file is licensed under that licence or
> > any later version, on the theory that if/when we change the license,
> > we'd like people to be able to retroactively apply the new terms to
> > whatever copy of the software they have. Sound good?
>
> Sounds good.
Not to me.
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?
*) 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.
*) 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.
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.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: CVS update: subversion/subversion/libsvn_client add.c apply_edits.c
checkout.c client.h commit.c delete.c status.c update.c
Posted by Brian Behlendorf <br...@collab.net>.
On 22 Nov 2000, Karl Fogel wrote:
> Brian Behlendorf <br...@collab.net> writes:
> > So the word back from our legal counsel is this is cool; we should put a
> > copy of the license on subversion.tigris.org, version-numbered (so,
> > perhaps, http://subversion.tigris.org/license_1.html), and each file
> > reference both COPYING and the URL, and it's all good.
>
> Will do. I will say that each file is licensed under that licence or
> any later version, on the theory that if/when we change the license,
> we'd like people to be able to retroactively apply the new terms to
> whatever copy of the software they have. Sound good?
Sounds good.
Brian
Re: CVS update: subversion/subversion/libsvn_client add.c apply_edits.c checkout.c client.h commit.c delete.c status.c update.c
Posted by Karl Fogel <kf...@galois.collab.net>.
Brian Behlendorf <br...@collab.net> writes:
> So the word back from our legal counsel is this is cool; we should put a
> copy of the license on subversion.tigris.org, version-numbered (so,
> perhaps, http://subversion.tigris.org/license_1.html), and each file
> reference both COPYING and the URL, and it's all good.
Will do. I will say that each file is licensed under that licence or
any later version, on the theory that if/when we change the license,
we'd like people to be able to retroactively apply the new terms to
whatever copy of the software they have. Sound good?
-K
Re: CVS update: subversion/subversion/libsvn_client add.c apply_edits.c checkout.c client.h commit.c delete.c status.c update.c
Posted by "Jonathan S. Shapiro" <sh...@eros-os.org>.
I'm very glad to hear that the URL reference works. It makes inserting
copyright notices MUCH easier, and I believe that I'll adopt it for EROS as
well.
> Always good to have clueful counsel!
Ah, but even more significant: there is now an *existence proof* for clueful
counsel!
Sorry. It was there.
Jonathan
Re: CVS update: subversion/subversion/libsvn_client add.c apply_edits.c
checkout.c client.h commit.c delete.c status.c update.c
Posted by Brian Behlendorf <br...@collab.net>.
So the word back from our legal counsel is this is cool; we should put a
copy of the license on subversion.tigris.org, version-numbered (so,
perhaps, http://subversion.tigris.org/license_1.html), and each file
reference both COPYING and the URL, and it's all good.
Always good to have clueful counsel!
Brian
On 17 Nov 2000, Karl Fogel wrote:
> I'd *love* not to have those licenses weighing down the top of every
> file; and the cost of someone accidentally not following the license
> is not very high (just recognition foregone, and that only for a file
> or two).
>
> Unless anyone objects, I'll make every file refer to the COPYING file
> and to a URL. That should be sufficient.
>
> Thoughts?,
> -Karl
>
Re: CVS update: subversion/subversion/libsvn_client add.c apply_edits.c checkout.c client.h commit.c delete.c status.c update.c
Posted by Karl Fogel <kf...@galois.collab.net>.
Brian Behlendorf <br...@collab.net> writes:
> I'd certainly be fine with putting the license in a single file and
> referring to that at the top of each source file, instead of duplicated
> elsewhere; Roy Fielding argued against this with Apache code because it'd
> make it easier for someone to accidentally not follow the license, he
> claimed (imagine someone getting a .c file but not a copy of
> LICENSE). Thoughts?
I'd *love* not to have those licenses weighing down the top of every
file; and the cost of someone accidentally not following the license
is not very high (just recognition foregone, and that only for a file
or two).
Unless anyone objects, I'll make every file refer to the COPYING file
and to a URL. That should be sufficient.
Thoughts?,
-Karl
Re: CVS update: subversion/subversion/libsvn_client add.c
apply_edits.ccheckout.c client.h commit.c delete.c status.c update.c
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Brian Behlendorf wrote:
>
> I'd certainly be fine with putting the license in a single file and
> referring to that at the top of each source file, instead of
> duplicated elsewhere
I'm +1; it works for GNU -- or will until there's a test case.
We just need to remember that at some point we may need to
revert..
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>
Re: CVS update: subversion/subversion/libsvn_client add.c apply_edits.c
checkout.c client.h commit.c delete.c status.c update.c
Posted by Brian Behlendorf <br...@collab.net>.
Thanks tons, Greg.
I'd certainly be fine with putting the license in a single file and
referring to that at the top of each source file, instead of duplicated
elsewhere; Roy Fielding argued against this with Apache code because it'd
make it easier for someone to accidentally not follow the license, he
claimed (imagine someone getting a .c file but not a copy of
LICENSE). Thoughts?
Brian
On Thu, 16 Nov 2000, Greg Stein wrote:
> Look for more license fixups in a while. Stepping out for some errands now.
>
> Cheers,
> -g
>
> On Thu, Nov 16, 2000 at 11:00:53PM -0000, gstein@tigris.org wrote:
> > User: gstein
> > Date: 00/11/16 15:00:53
> >
> > Modified: subversion/tests-common svn_test_editor.c
> > subversion/libsvn_ra_dav commit.c fetch.c ra_session.h
> > session.c
> > subversion/libsvn_ra_dav/tests ra-dav-test.c
> > subversion/libsvn_client add.c apply_edits.c checkout.c
> > client.h commit.c delete.c status.c update.c
> > Log:
> > fix URL in license. should be: http://www.Collab.Net/
>
>
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
CollabNet | open source | do what's right | now hiring