Licensing
Gabriel Sean Farrell
notices to each file. They currently read:
# Copyright 2007 Casey Durfee
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing,
software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
# See the License for the specific language governing permissions
and
# limitations under the License.
In that discussion, dbs convinced Dan Chudnov (dchud) and I that the
simplest way to deal with additional authors is to add names to the
copyright for each file other authors significantly modify. Hence,
for a file that dbs and Mike Beccaria have added to, the above header
might begin:
# Copyright 2007 Casey Durfee
# Copyright 2007 Mike Beccaria
# Copyright 2007 Dan Scott
#
# Licensed under the Apache License, Version 2.0 (the "License");
...
Okay, so maybe "convinced" isn't the right word, at least in my case,
and dchud didn't like it either. I still want an AUTHORS file. The
presence of a different, but similar, copyright header for each file
seems clunky (not very DRY, that's for sure). And frankly, I'd
rather
not have to remember to add my name to each file I touch. So I did
some research, and after some disappointing Googling, I looked at
the code for Django.
I came to the same realization I often come to with Django: they've
solved the problem in the way that makes the most sense to me. See
http://code.djangoproject.com/browser/django/trunk if you don't have
an svn'd working copy handy. Behold a LICENSE file and an
AUTHORS file. That's it! No copyright statement in every file, no
adding one's name everywhere.
There are other examples of copyright application to codebases that I
could point at, but the Django one really does present my ideal.
Therefore, I propose we follow one of three courses (in order of my
priority):
1. Adopt the Django licensing setup pretty much directly. Include
LICENSE and AUTHORS files, with "Copyright 2007 Casey Durfee" in
the LICENSE file, and even move to the BSD-style license they've used.
2. Same as #1, but keep the Apache 2.0 license. The advantage here is
we don't have to do a license shift, but it's not the way prescribed
in the
Apache license for its use.
3. Keep copyright messages in each file, but leave all copyright with
Casey, and include an AUTHORS file for acknowledgment of the work
of others.
I understand the concerns dbs has raised, and if there are reasons
we didn't follow Django licensing in the first place, I'd like to hear
them.
Considering the size of the Django project, however, and the fact
that
lawyers *have* been involved (see the informative discussion at
http://groups.google.com/group/django-developers/browse_thread/thread/4f41f7a1afa77f3c/),
I believe theirs is a good model to follow. If two small files can
cover
Django's ass, they should be able to cover ours as well.
gsf
Dan Scott
<snip>
> 1. Adopt the Django licensing setup pretty much directly. Include
> LICENSE and AUTHORS files, with "Copyright 2007 Casey Durfee" in
> the LICENSE file, and even move to the BSD-style license they've used.
Oddly enough, I couldn't find either of these files in the Django SVN
repository. There's a license.txt, and a LICENSE.txt, but those are
for subsets of the project (dispatch and utils/simplejson
respectivley). Maybe they merge these into the tarballs?
> 2. Same as #1, but keep the Apache 2.0 license. The advantage here is
> we don't have to do a license shift, but it's not the way prescribed
> in the
> Apache license for its use.
>
> 3. Keep copyright messages in each file, but leave all copyright with
> Casey, and include an AUTHORS file for acknowledgment of the work
> of others.
>
I don't like options 2 (if we're going to use the Apache 2.0 license,
not following the prescribed means of applying the license doesn't
make sense to me -- yeah, I know, I've let it slide for 9 months now)
or 3 (assuming the project grows, having an explicit copyright
statement in each file that only mentions Casey will make less and
less sense, especially as brand new files are added).
I can almost live with option 1 (assuming we're talking about the
Modified BSD License at http://www.xfree86.org/3.3.6/COPYRIGHT2.html#5
which is GPL-compatible), and am okay with relicensing my
contributions under the BSD license. I'm not okay with a copyright
statement that only lists one person, however.
The definitive statement from that discussion thread that you cited is
ridiculous:
"""We don't; my conversations with the company lawyers seemed to
indicate that you're implicitly assigning copyright simply by
submitting code to an OSS project."""
Either the company lawyers are complete and utter idiots, or (more
likely) the telephone game is in effect and Jacob is confusing
copyright with a grant of license. I can understand the argument that
by submitting code to an OSS project, you are agreeing to place that
code under the project's license - but it would be a very different
and very difficult argument to make that you are also assigning your
copyright to the project.
In a like vein, when I post messages to a public mailing list, I
implicitly grant permission for others to quote my (probably
completely incorrect) statements. But I still retain copyright over
the content of my messages: if someone was foolish enough to reproduce
my statements in an article and claim that they were the author of
those statements, they would be liable for infringement. This is why
closed-access journals have lengthy legal forms for you to sign when
they insist on you assigning copyright to the publisher; they need to
cover their butts in a most serious fashion.
Sorry. I hate talking about copyright and licensing, but I apparently
can't stop myself.
So -- let's say we go with option 1, with the Modified BSD license.
How do we handle this clause?
"""1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer."""
The "above copyright notice" in ye olde XFree86 is:
"""XFree86 code without an explicit copyright is covered by the
following copyright:
Copyright (C) 1994-1999 The XFree86 Project, Inc. All Rights Reserved."""
So.... we're back at needing some explicit copyright statements again,
or else that section of the license makes no sense. Your suggestion
was to just list Casey as copyright owner, and I'm not comfortable
with that. So my counter-proposal is that we prepend the LICENSE with
a COPYRIGHT NOTICE section that contains a list of explicit copyright
statements, like:
Copyright (C) 2007 Casey Durfee
Copyright (C) 2007 Gabriel Sean Farrell
Copyright (C) 2007 Dan Scott
I think that should meet our needs, avoid a suggestion that copyright
is being assigned to just a single person, drop us back down to a
single LICENSE file for the whole project, and reduce DRY concerns. I
think.
--
Dan Scott
Laurentian University
Gabriel Sean Farrell
> On 10/12/2007, Gabriel Sean Farrell <gsf...@gmail.com> wrote:
> <snip>
>
> > 1. Adopt the Django licensing setup pretty much directly. Include
> > LICENSE and AUTHORS files, with "Copyright 2007 Casey Durfee" in
> > the LICENSE file, and even move to the BSD-style license they've used.
>
> Oddly enough, I couldn't find either of these files in the Django SVN
> repository. There's a license.txt, and a LICENSE.txt, but those are
> for subsets of the project (dispatch and utils/simplejson
> respectivley). Maybe they merge these into the tarballs?
>
http://code.djangoproject.com/browser/django/trunk, where the AUTHORS
and LICENSE files are plain as day.
> > 2. Same as #1, but keep the Apache 2.0 license. The advantage here is
> > we don't have to do a license shift, but it's not the way prescribed
> > in the
> > Apache license for its use.
>
> > 3. Keep copyright messages in each file, but leave all copyright with
> > Casey, and include an AUTHORS file for acknowledgment of the work
> > of others.
>
> I don't like options 2 (if we're going to use the Apache 2.0 license,
> not following the prescribed means of applying the license doesn't
> make sense to me -- yeah, I know, I've let it slide for 9 months now)
> or 3 (assuming the project grows, having an explicit copyright
> statement in each file that only mentions Casey will make less and
> less sense, especially as brand new files are added).
>
> I can almost live with option 1 (assuming we're talking about the
> contributions under the BSD license. I'm not okay with a copyright
> statement that only lists one person, however.
>
> The definitive statement from that discussion thread that you cited is
> ridiculous:
>
> """We don't; my conversations with the company lawyers seemed to
> indicate that you're implicitly assigning copyright simply by
> submitting code to an OSS project."""
>
> Either the company lawyers are complete and utter idiots, or (more
> likely) the telephone game is in effect and Jacob is confusing
> copyright with a grant of license. I can understand the argument that
> by submitting code to an OSS project, you are agreeing to place that
> code under the project's license - but it would be a very different
> and very difficult argument to make that you are also assigning your
> copyright to the project.
>
> In a like vein, when I post messages to a public mailing list, I
> implicitly grant permission for others to quote my (probably
> completely incorrect) statements. But I still retain copyright over
> the content of my messages: if someone was foolish enough to reproduce
> my statements in an article and claim that they were the author of
> those statements, they would be liable for infringement. This is why
> closed-access journals have lengthy legal forms for you to sign when
> they insist on you assigning copyright to the publisher; they need to
> cover their butts in a most serious fashion.
>
think you're right about Jacob probably misquoting the lawyers.
> Sorry. I hate talking about copyright and licensing, but I apparently
> can't stop myself.
>
> So -- let's say we go with option 1, with the Modified BSD license.
> How do we handle this clause?
>
> """1. Redistributions of source code must retain the above copyright
> notice, this list of conditions and the following disclaimer."""
>
> The "above copyright notice" in ye olde XFree86 is:
>
> """XFree86 code without an explicit copyright is covered by the
> following copyright:
> Copyright (C) 1994-1999 The XFree86 Project, Inc. All Rights Reserved."""
>
> So.... we're back at needing some explicit copyright statements again,
> or else that section of the license makes no sense. Your suggestion
> was to just list Casey as copyright owner, and I'm not comfortable
> with that. So my counter-proposal is that we prepend the LICENSE with
> a COPYRIGHT NOTICE section that contains a list of explicit copyright
> statements, like:
>
> Copyright (C) 2007 Casey Durfee
> Copyright (C) 2007 Gabriel Sean Farrell
> Copyright (C) 2007 Dan Scott
>
> I think that should meet our needs, avoid a suggestion that copyright
> is being assigned to just a single person, drop us back down to a
> single LICENSE file for the whole project, and reduce DRY concerns. I
> think.
>
LICENSE file at the base of the project with all of our copyrights and
the license? I could totally live with this. In fact, it would be
awesome.
gsf
Dan Scott
>
> On Dec 10, 11:30 am, "Dan Scott" <deni...@gmail.com> wrote:
> > On 10/12/2007, Gabriel Sean Farrell <gsf...@gmail.com> wrote:
> > <snip>
> >
> > > 1. Adopt the Django licensing setup pretty much directly. Include
> > > LICENSE and AUTHORS files, with "Copyright 2007 Casey Durfee" in
> > > the LICENSE file, and even move to the BSD-style license they've used.
> >
> > Oddly enough, I couldn't find either of these files in the Django SVN
> > repository. There's a license.txt, and a LICENSE.txt, but those are
> > for subsets of the project (dispatch and utils/simplejson
> > respectivley). Maybe they merge these into the tarballs?
> >
>
> Are you sure, Dan? My copy of the Django trunk matches
> http://code.djangoproject.com/browser/django/trunk, where the AUTHORS
> and LICENSE files are plain as day.
Ah - I'm just an idiot, as I checked out /trunk/django; I guess the
AUTHORS and LICENSE files are in the trunk directory.
Got my baggy pants on.
That's what I'm proposing, yessir. I'm elated & relieved to hear that
you like it.
Let's see what others have to say; if there are no objections by, say,
Wednesday, let's go ahead and implement this. We'll need an explicit
okay from Mike B. and Dan C. to relicense their contributed code under
the Modified BSD license, and it would be good to have the same from
Casey (although we could always operate under the "do whatever you
want with it" quasi-license he granted me via personal email, it would
be better for the project to have an explicit public "ok" and it's
always nice to ask).
Mike Beccaria
On 10/12/2007, Gabriel Sean Farrell <gsf...@gmail.com> wrote:
>
> On Dec 10, 11:30 am, "Dan Scott" < deni...@gmail.com> wrote:
> > On 10/12/2007, Gabriel Sean Farrell <gsf...@gmail.com> wrote:
> > <snip>
> >
> > > 1. Adopt the Django licensing setup pretty much directly. Include
> > > LICENSE and AUTHORS files, with "Copyright 2007 Casey Durfee" in
> > > the LICENSE file, and even move to the BSD-style license they've used.
> >
> > Oddly enough, I couldn't find either of these files in the Django SVN
> > repository. There's a license.txt, and a LICENSE.txt, but those are
> > for subsets of the project (dispatch and utils/simplejson
> > respectivley). Maybe they merge these into the tarballs?
> >
>
> Are you sure, Dan? My copy of the Django trunk matches
> http://code.djangoproject.com/browser/django/trunk , where the AUTHORS
Dan Chudnov
> In that discussion, dbs convinced Dan Chudnov (dchud) and I that the
> simplest way to deal with additional authors is to add names to the
> copyright for each file other authors significantly modify.
Er, for the record, I'm not convinced. I just don't think this is
really my choice, so I'll go along happily with any viable plan, or
grin and bear it otherwise.
> 3. Keep copyright messages in each file, but leave all copyright with
> Casey, and include an AUTHORS file for acknowledgment of the work
> of others.
Fwiw, this is the only plan that sounds viable to me. :) Unless I'm
grossly mistaken, this is what the overwhelming majority of projects
I've seen tend to do, and it seems to work, even years after the
original copyright holder has stopped being involved in any way.
That's exactly what copyleft is for - to allow/require us to retain
the original copyright and still have the explicit right to
redistribute with modifications.
It doesn't solve the problem of copyright assignment, but in the short
term, we can punt on that, imho, even though that's a terrible idea.
There's some text in the Apache 2.0 license about implicit assignment,
right? If so, and that's thorough enough to hold up in court, I'd
vote for that. i.e. "#3 with Apache 2.0 to cover our behinds on the
assignment issue".
But, that's just my opinion... I'll go along with the rest of the
group on whatever consensus arises.
Dan Scott
>
> On Dec 10, 2007, at 10:39 AM, Gabriel Sean Farrell wrote:
>
> > In that discussion, dbs convinced Dan Chudnov (dchud) and I that the
> > simplest way to deal with additional authors is to add names to the
> > copyright for each file other authors significantly modify.
>
> Er, for the record, I'm not convinced. I just don't think this is
> really my choice, so I'll go along happily with any viable plan, or
> grin and bear it otherwise.
Right, the lack of convincing (convincement? convinciness?) was clear
enough to me.
> > 3. Keep copyright messages in each file, but leave all copyright with
> > Casey, and include an AUTHORS file for acknowledgment of the work
> > of others.
>
> Fwiw, this is the only plan that sounds viable to me. :) Unless I'm
> grossly mistaken, this is what the overwhelming majority of projects
> I've seen tend to do, and it seems to work, even years after the
> original copyright holder has stopped being involved in any way.
> That's exactly what copyleft is for - to allow/require us to retain
> the original copyright and still have the explicit right to
> redistribute with modifications.
Well, I suppose I'm a pedant, and am scarred from having to work with
lawyers on open source work in a large corporation, but I'm scarred
enough to be convinced that the overwhelming majority of projects
probably do things "wrong" from a legal perspective. Most people don't
want to be bothered with licensing distractions, and I'm with them in
spirit - but I have this thing about doing things right (talk to my
wife about how fun life around the Scott household can be at times).
Both the GPL 2 and the Apache 2.0 license, for example, contain very
clear instructions that describe how to apply the license (involving
headers at the top of each file), yet many projects fail to carry out
these steps.
Erm, open source licenses in general are about allowing original
developers to retain copyright while granting the right (a license) to
redistribute with modifications. Copyleft licenses are a
specialization of open source license that requires any code that
incorporates the copylefted code to also adopt a copyleft-compatible
license. Think "free as in take this code and run with it"
(non-copyleft) vs. "free as in you can't lock away code derived from
this project from us" (copyleft).
> It doesn't solve the problem of copyright assignment, but in the short
> term, we can punt on that, imho, even though that's a terrible idea.
Heh, we punted on it for 9 months already. Precedent!
> There's some text in the Apache 2.0 license about implicit assignment,
> right? If so, and that's thorough enough to hold up in court, I'd
> vote for that. i.e. "#3 with Apache 2.0 to cover our behinds on the
> assignment issue".
Nope, there is not text in the Apache 2.0 license about copyright
assignment. There is clause 2 "Grant of Copyright License" which is a
significantly different thing; clause 5 "Submission of Contributions"
states that any contributions are understood to be contributed under
the terms and conditions of the Apache 2.0 license.
The Apache 2.0 license is a pretty quick read at
http://apache.org/licenses/LICENSE-2.0.html - see, for example, clause
4b on redistribution:
"You must cause any modified files to carry prominent notices stating
that You changed the files; and"
It's arguable that this clause only applies to an entity
redistributing the code outside of the project itself, but it's clear
that the aggregation of authorship is intended. For another quote on
this subject, from Havoc Pennington on copyright statements in Gnome
Foundation code:
"""btw a good habit everyone should try to have is, when you modify a
file add your name and date to the copyright list at the top. When
submitting or reviewing a patch, should check for this.
I know I often forget it when I review and submit patches, but it's
always correct and best to do this.
People sometimes feel shy about this but they should not - it's just a
statement of fact. If you wrote some code in the file you (or your
employer) will own the copyright, until/unless you sign a contract
relaying it elsewhere. So adding your name to the top is a statement
of this factual situation."""
(http://mail.gnome.org/archives/foundation-list/2007-August/msg00008.html)
> But, that's just my opinion... I'll go along with the rest of the
> group on whatever consensus arises.
I do think the list of copyright statements followed by the Modified
BSD license is the simplest way to both express the true copyright
over the code while allowing the broadest use of the code. The
Modified BSD is GPL-compatible -
http://www.gnu.org/licenses/license-list.html#ModifiedBSD - but is not
a copyleft license. So as long as we're okay with a commercial company
taking this code, putting some more lipstick on it, and selling it for
millions of dollars without returning those modifications to the
project, the Modified BSD is what we want.
If we want to ensure that any modifications by a person or company
that redistributes the code are returned to the project, then a GPL
license will be the best option (but we will also have to add headers
to each source file). If we want to ensure that any modification by a
person or company that uses the code in a hosted application gets
returned to the project, then I think the GNU Affero GPL v3 license is
the best option ... but I'm getting out of my depth there.
Me - I just want people to feel free to use the code, learn from it,
improve it, and hopefully return those contributions to the project,
and I would like the terms under which they can do this as clear as
possible. I wouldn't be comfortable giving the false impression that I
have assigned my copyright to someone else, and don't really want to
assign my copyright to anyone else.
Gabriel Sean Farrell
> >
> > On Dec 10, 2007, at 10:39 AM, Gabriel Sean Farrell wrote:
> > >
> > > In that discussion, dbs convinced Dan Chudnov (dchud) and I that the
> > > simplest way to deal with additional authors is to add names to the
> > > copyright for each file other authors significantly modify.
> >
> > Er, for the record, I'm not convinced. I just don't think this is
> > really my choice, so I'll go along happily with any viable plan, or
> > grin and bear it otherwise.
>
> Right, the lack of convincing (convincement? convinciness?) was clear
> enough to me.
>
not the right word. Guess that's what I get for being too clever in
my writing.
> > > 3. Keep copyright messages in each file, but leave all copyright with
> > > Casey, and include an AUTHORS file for acknowledgment of the work
> > > of others.
> >
> > Fwiw, this is the only plan that sounds viable to me. :) Unless I'm
> > grossly mistaken, this is what the overwhelming majority of projects
> > I've seen tend to do, and it seems to work, even years after the
> > original copyright holder has stopped being involved in any way.
> > That's exactly what copyleft is for - to allow/require us to retain
> > the original copyright and still have the explicit right to
> > redistribute with modifications.
>
> Well, I suppose I'm a pedant, and am scarred from having to work with
> lawyers on open source work in a large corporation, but I'm scarred
> enough to be convinced that the overwhelming majority of projects
> probably do things "wrong" from a legal perspective. Most people don't
> want to be bothered with licensing distractions, and I'm with them in
> spirit - but I have this thing about doing things right (talk to my
> wife about how fun life around the Scott household can be at times).
> Both the GPL 2 and the Apache 2.0 license, for example, contain very
> clear instructions that describe how to apply the license (involving
> headers at the top of each file), yet many projects fail to carry out
> these steps.
>
are doing it wrong, which model do you follow?
> Erm, open source licenses in general are about allowing original
> developers to retain copyright while granting the right (a license) to
> redistribute with modifications. Copyleft licenses are a
> specialization of open source license that requires any code that
> incorporates the copylefted code to also adopt a copyleft-compatible
> license. Think "free as in take this code and run with it"
> (non-copyleft) vs. "free as in you can't lock away code derived from
> this project from us" (copyleft).
>
[snip]
> this subject, from Havoc Pennington on copyright statements in Gnome
> Foundation code:
>
> """btw a good habit everyone should try to have is, when you modify a
> file add your name and date to the copyright list at the top. When
> submitting or reviewing a patch, should check for this.
>
> I know I often forget it when I review and submit patches, but it's
> always correct and best to do this.
>
> People sometimes feel shy about this but they should not - it's just a
> statement of fact. If you wrote some code in the file you (or your
> employer) will own the copyright, until/unless you sign a contract
> relaying it elsewhere. So adding your name to the top is a statement
> of this factual situation."""
> (http://mail.gnome.org/archives/foundation-list/2007-August/msg00008.html)
>
two copyright holders, even when more than a dozen people have done
commits. Now this might be because those commits have not been
significant enough, but more likely it's a sign of the lack of
accounting that led to Havoc's message. And I really want to avoid,
or at least minimize, these questions of who committed what where and
is it significant enough in this file or that. Hence the strong
desire for a single copyright file where all significant contributors
are listed.
> > But, that's just my opinion... I'll go along with the rest of the
> > group on whatever consensus arises.
>
> I do think the list of copyright statements followed by the Modified
> BSD license is the simplest way to both express the true copyright
> over the code while allowing the broadest use of the code. The
> taking this code, putting some more lipstick on it, and selling it for
> millions of dollars without returning those modifications to the
> project, the Modified BSD is what we want.
>
> If we want to ensure that any modifications by a person or company
> that redistributes the code are returned to the project, then a GPL
> license will be the best option (but we will also have to add headers
> to each source file). If we want to ensure that any modification by a
> person or company that uses the code in a hosted application gets
> returned to the project, then I think the GNU Affero GPL v3 license is
> the best option ... but I'm getting out of my depth there.
>
but dbs seems to be saying there's no way to do copyleft without doing
headers in each file, and I'm still too psyched about one license file
to rule them all (all the code in the project, that is) to give that
up in favor of copyleft. It's tempting, though.
> Me - I just want people to feel free to use the code, learn from it,
> improve it, and hopefully return those contributions to the project,
> and I would like the terms under which they can do this as clear as
> possible. I wouldn't be comfortable giving the false impression that I
> have assigned my copyright to someone else, and don't really want to
> assign my copyright to anyone else.
>
Still, then, for the sake of simplicity and compatibility, I say we go
with one Modified-BSD LICENSE file with individual copyright notices.
gsf
Daniel Chudnov
answering the exact questions we'd want to answer if we had to make a
thorough business decision. It's not important enough to me to justify
adding more to the muddling and unfocusing as I've contributed so far,
so I'll stop.
I really go along with what you decide.
Gabriel Sean Farrell
> Imho this conversation is muddled and unfocused on determining and
> answering the exact questions we'd want to answer if we had to make a
> thorough business decision. It's not important enough to me to justify
> adding more to the muddling and unfocusing as I've contributed so far,
> so I'll stop.
>
come down to the following:
1. Do we want a copyleft license (e.g., GPL)?
Given that the code has been under the Apache 2.0 License, I would
assume that people are okay with a non-copyleft license. No one has
spoken out against a copyleft license, either, so we could still go
either way here.
2. Does the license we choose demand copyright headers in each file?
This one is tricky, because organizations that have really dealt with
legal issues, such as Apache, GNU, and Mozilla, all place notices at
the top of each and every file, and, at least in the case of Apache
and GNU, instruct others to do so as well.
Some others, however, have not. Projects with copyright only in the
LICENSE file include Django (as I mentioned), Trac, NumPy, SciPy, and
Python itself.
For a minute I thought this was a Python thing, but PyGame and PyGTK,
both released under the GPL, have copyright in the file headers.
Zope, under the ZPL, also has copyright in the headers. Twisted,
under a Modified-BSDish license, has copyright assigned to a number of
people and organizations in the LICENSE file, but also "Copyright (c)
2001-2004 Twisted Matrix Laboratories" in the header for each file.
Talk about confusing.
As Dan Scott noted, it may not particularly beneficial to look at how
others are doing it, since most of them are doing it wrong. Still,
it's interesting to get a view of the field.
3. Does copyright need to be held by each contributor, or can it be
assigned to one entity?
I'm persuaded by Dan Scott's argument that one's copyright is not so
easy to give away, and I can understand his desire not to give it up
in any case. There's no real arguing this one, then, but I don't see
it as the burden I first took it to be.
> I really go along with what you decide.
ready to make a decision yet. Given my findings and the discussion so
far, I think we have 4 viable options:
1. Loose: Modified BSD LICENSE file with copyrights for each
contributor in that file. Nothing in the file headers.
2. Strict, non-copyleft: Apache 2.0 LICENSE file. Copyrights for each
contributor in the file headers.
3. Strict, copyleft: GPL LICENSE file. Copyrights for each
contributor in the file headers.
4. Rigid, strict, copyleft: AGPL LICENSE file. Copyrights for each
contributor in the file headers.
I'd say right now I'd rank them 3, 1, 4, 2. I know my preference for
3 goes against my argument earlier in this discussion for 1, but I'm
starting to think that as long as we're agonizing over this, we might
as well do it "the right way". Anyone who gives a damn one way or the
other, please post an opinion on these options.
gsf
Dan Scott
Thank for this, Gabe. I think that helps bring the discussion full
circle, back to the basics of what license do we want and how are we
going to apply it. I hate to do this, but for full clarity - for GPL
and AGPL, I assume we're talking GPL v3 and AGPL v3.
My ranking is similar to yours: 3, 4, 1, 2.
Yeah, surprise, given that I chose Apache 2.0 initially - but in the
course of these discussions, I learned that the FSF believes that the
Apache License 2.0 is _not_ compatible with GPL v2 - but is compatible
with GPL v3.
Gabriel Sean Farrell
> Thank for this, Gabe. I think that helps bring the discussion full
> circle, back to the basics of what license do we want and how are we
> going to apply it. I hate to do this, but for full clarity - for GPL
> and AGPL, I assume we're talking GPL v3 and AGPL v3.
>
> My ranking is similar to yours: 3, 4, 1, 2.
>
> Yeah, surprise, given that I chose Apache 2.0 initially - but in the
> course of these discussions, I learned that the FSF believes that the
> Apache License 2.0 is _not_ compatible with GPL v2 - but is compatible
> with GPL v3.
transpired, it looks like we have an agreement on option 3. That is,
we'll have the text of the GPLv3 license in the COPYING file at the
root of the code and permission statements pointing to it following
the copyright in the header of each source file, as described at
http://www.gnu.org/licenses/gpl-howto.html. Whenever anyone modifies
a file, he or she should check the copyright on that file and add his
or her name. I'll make those changes today.
gsf