Good news, everyone! copyleft-next 0.2.0 has been released!
https://gitorious.org/copyleft-next/copyleft-next/blobs/raw/master/Releases/...
A summary of the principal changes relative to 0.1.1 will follow in due course.
- RF
I am late to this discussion, so my apologies if some of these points have been raised before.
On 20/02/13 03:16, Richard Fontana wrote:
Good news, everyone! copyleft-next 0.2.0 has been released!
https://gitorious.org/copyleft-next/copyleft-next/blobs/raw/master/Releases/...
* "This License does not exclude or limit any rights You have under applicable law."
Some licensing documents disclaim e.g. the application of the United Nations Convention on Contracts for the International Sale of Goods. Do they have good reason to do so, and we are _sure_ there are no rights of this sort we want to limit?
* "in a manner that fails to satisfy the Open Source Definition published by the Open Source Initiative as of 1 January 2013"
Who decides? That sounds like a recipe for lawyer argument. Is it better to refer to the OSI license list as of a certain date instead?
* "under the Apache License"
Perhaps you should give a version number. (Ah, I see you give one in the definitions - but I don't think people will obviously read "Apache License" as a defined term, because it normally has initial caps anyway.)
* "or "powered by" statements"
Is this too specific, or are we hoping a judge would understand this as referring to a class of statements? E.g. if there was a "FooBar Inside" statement instead of "Powered by FooBar"...
* "This condition may not be avoided through such means as separate distribution of portions of the Derived Work."
Is it considered that there is no need for a system library exception? Is that because the definition of Derived Work does not cover system libraries?
* "under any version of the GNU General Public License"
I look forward to the rationale for this change; I would worry that this would open the license up to the exploitation of flaws in e.g. GPLv1.
I presume that the intent is that the GPL's pass-through can be used to get to AGPL licensing.
* "15 years"
Is that a conservative opening bid? :-) I would say 10. 5 years is a bit short - the 5-years-old Linux kernel is still a pretty good bit of kit. But 15 years is a long period over which to track down contributors to get permission for some change.
* Has consideration been given to combining how section 2 works with how section 8 works?
Gerv
On 2013-02-20 at 13:35:44, Gervase Markham wrote:
- "This License does not exclude or limit any rights You have under
applicable law."
Some licensing documents disclaim e.g. the application of the United Nations Convention on Contracts for the International Sale of Goods. Do they have good reason to do so, and we are _sure_ there are no rights of this sort we want to limit?
Also, how does this sentence interact with the warranty and liability limitations of sections 12 and 13?
It seems like the point of these two sections is to limit and exclude rights that users might have under applicable laws.
Francois
On Thu, Feb 21, 2013 at 09:42:55AM +1300, Francois Marier wrote:
On 2013-02-20 at 13:35:44, Gervase Markham wrote:
- "This License does not exclude or limit any rights You have under
applicable law."
[...]
Also, how does this sentence interact with the warranty and liability limitations of sections 12 and 13?
It seems like the point of these two sections is to limit and exclude rights that users might have under applicable laws.
Good observation; while I consider these reconcilable I see how it is potentially confusing. If this is retained I think we'd want to add something like 'Except where this License explicitly states otherwise' or something. But I think it might be better to just get rid of it.
- RF
On Wed, Feb 20, 2013 at 01:35:44PM +0000, Gervase Markham wrote:
Some licensing documents disclaim e.g. the application of the United Nations Convention on Contracts for the International Sale of Goods. Do they have good reason to do so,
I don't actually know. I confess that as far as I can recall I've never looked at that Convention. The most coherent argument I have heard from a lawyer on this point was something to the following effect: 'no one really knows what's in that Convention, or whether it applies to software, but whatever is in it might be bad' (paraphrasing heavily of course). I think the main reason we see this being excluded is because someone initially decided to do so and this started a process in which lawyers drafting licensing agreements all followed suit.
and we are _sure_ there are no rights of this sort we want to limit?
No, but if there were we'd want to do it explicitly (like the licenses dealing with the UN Convention do).
- "in a manner that fails to satisfy the Open Source Definition
published by the Open Source Initiative as of 1 January 2013"
Who decides? That sounds like a recipe for lawyer argument. Is it better to refer to the OSI license list as of a certain date instead?
That was essentially what an earlier release did (IIRC). I'm really trying to define what 'proprietary licensing' is and I don't know a good way to do it. And the goal here isn't perfection, but rather to ward off practitioners of certain kinds of business models. I just want a way to signal "keep away" to a certain kind of potential licensor. The definition doesn't have to be perfect for that purpose.
That said, I'm not satisfied that this can't be made better, including perhaps in the way you've suggested.
- "under the Apache License"
Perhaps you should give a version number. (Ah, I see you give one in the definitions - but I don't think people will obviously read "Apache License" as a defined term, because it normally has initial caps anyway.)
Ah, that's a good point.
- "or "powered by" statements"
Is this too specific, or are we hoping a judge would understand this as referring to a class of statements? E.g. if there was a "FooBar Inside" statement instead of "Powered by FooBar"...
This is just a clarification of what kinds of things absolutely are not 'Legal Notices'. It isn't meant to be exhaustive, but I did recently add 'Powered by statements' because that is such a common form in which I've seen the problematic condition.
- "This condition may not be avoided through such means as separate
distribution of portions of the Derived Work."
Is it considered that there is no need for a system library exception? Is that because the definition of Derived Work does not cover system libraries?
Sort of. The old system library exception can be seen as built into the definition of 'Separate Work'. At least that was the intention. I am not at all of the view that this definition could not be made better.
- "under any version of the GNU General Public License"
I look forward to the rationale for this change; I would worry that this would open the license up to the exploitation of flaws in e.g. GPLv1.
We might as well exclude GPLv1. I think leaving it open-ended on the other side (GPLv2+) seems to make sense, but I suppose one could question it.
I presume that the intent is that the GPL's pass-through can be used to get to AGPL licensing.
Not exactly. Earlier versions stated that Covered Works were outbound-licensable under GPLv2+ or AGPLv3+. In the restructuring of that provision I realized that you didn't have to mention AGPLv3 because GPLv3 itself is AGPLv3 compatible (and we can reasonably [?] assume this will be so for all future versions of GPL and AGPL). And the political benefit of explicitly allowing AGPLv3 compatibility seems essentially nil, sadly.
- "15 years"
Is that a conservative opening bid? :-)
Not necessarily an opening bid, but I thought it was conservative.
I would say 10. 5 years is a bit short - the 5-years-old Linux kernel is still a pretty good bit of kit. But 15 years is a long period over which to track down contributors to get permission for some change.
True. I was mainly focusing on the policy issue of copyright duration there, through the proxy of copyleft duration. The side benefit of making license changes easier was serendipitous.
- Has consideration been given to combining how section 2 works with how
section 8 works?
I haven't thought about that, beyond being aware of the inelegance that I introduced in referring in section 2 to the Apache License (which I did in a recent change because I thought it might make the provision easier to understand -- this was a response to the comments on Martin's article on LWN.net).
- RF
On 21/02/13 05:40, Richard Fontana wrote:
I don't actually know. I confess that as far as I can recall I've never looked at that Convention. The most coherent argument I have heard from a lawyer on this point was something to the following effect: 'no one really knows what's in that Convention, or whether it applies to software, but whatever is in it might be bad' (paraphrasing heavily of course). I think the main reason we see this being excluded is because someone initially decided to do so and this started a process in which lawyers drafting licensing agreements all followed suit.
I have no idea what's in it either! :-)
Who decides? That sounds like a recipe for lawyer argument. Is it better to refer to the OSI license list as of a certain date instead?
That was essentially what an earlier release did (IIRC). I'm really trying to define what 'proprietary licensing' is and I don't know a good way to do it. And the goal here isn't perfection, but rather to ward off practitioners of certain kinds of business models. I just want a way to signal "keep away" to a certain kind of potential licensor. The definition doesn't have to be perfect for that purpose.
That said, I'm not satisfied that this can't be made better, including perhaps in the way you've suggested.
I think that having a clearly defined list is much easier. Then it's pretty obvious to all. In the current set up, I can imagine someone wanting to take advantage of that clause thinking "Hmm, I don't think their pseudo-open license meets the OSD, but they do. So what now?" Pseudo-open is currently observed (if not common), and we should plan for it possibly remaining so.
This is just a clarification of what kinds of things absolutely are not 'Legal Notices'. It isn't meant to be exhaustive, but I did recently add 'Powered by statements' because that is such a common form in which I've seen the problematic condition.
I wonder if we can think of a more generic phrase. Or we could go for the slightly linguistically ugly '"Powered by"-style statements.' Or you could try leaning on the legal definition of what makes a valid copyright statement, and say you only have to preserve those.
Is it considered that there is no need for a system library exception? Is that because the definition of Derived Work does not cover system libraries?
Sort of. The old system library exception can be seen as built into the definition of 'Separate Work'. At least that was the intention. I am not at all of the view that this definition could not be made better.
Reversing the question, how can we make it clear that it's OK to ship Windows binaries of copyleft-next code?
- "under any version of the GNU General Public License"
I look forward to the rationale for this change; I would worry that this would open the license up to the exploitation of flaws in e.g. GPLv1.
We might as well exclude GPLv1. I think leaving it open-ended on the other side (GPLv2+) seems to make sense, but I suppose one could question it.
I think + is certainly right, and GPLv2+ (which you did have) is probably right. Particularly if you don't have the "user product" stuff from GPLv3.
- Has consideration been given to combining how section 2 works with how
section 8 works?
I haven't thought about that, beyond being aware of the inelegance that I introduced in referring in section 2 to the Apache License (which I did in a recent change because I thought it might make the provision easier to understand -- this was a response to the comments on Martin's article on LWN.net).
I think there's clarity and self-containedness in having a "waive these sections" approach rather than a "use this totally different license" approach, if for no other reason that you don't have the issue which is addressed by the "if you change the license in this way, no additional rights are granted" language you now see in some licenses.
Gerv
On Thu, Feb 21, 2013 at 4:59 AM, Gervase Markham gerv@mozilla.org wrote:
On 21/02/13 05:40, Richard Fontana wrote:
Who decides? That sounds like a recipe for lawyer argument. Is it better to refer to the OSI license list as of a certain date instead?
That was essentially what an earlier release did (IIRC). I'm really trying to define what 'proprietary licensing' is and I don't know a good way to do it. And the goal here isn't perfection, but rather to ward off practitioners of certain kinds of business models. I just want a way to signal "keep away" to a certain kind of potential licensor. The definition doesn't have to be perfect for that purpose.
That said, I'm not satisfied that this can't be made better, including perhaps in the way you've suggested.
I think that having a clearly defined list is much easier. Then it's pretty obvious to all. In the current set up, I can imagine someone wanting to take advantage of that clause thinking "Hmm, I don't think their pseudo-open license meets the OSD, but they do. So what now?" Pseudo-open is currently observed (if not common), and we should plan for it possibly remaining so.
What about the Fedora list? Or on any one of the Debian, OSI or Fedora lists? Even if you disagree with the judgment of a particular list it will be a very fringe case, and I agree with Gerv that certainty is better than uncertainty in this case.
This is just a clarification of what kinds of things absolutely are not 'Legal Notices'. It isn't meant to be exhaustive, but I did recently add 'Powered by statements' because that is such a common form in which I've seen the problematic condition.
I wonder if we can think of a more generic phrase. Or we could go for the slightly linguistically ugly '"Powered by"-style statements.' Or you could try leaning on the legal definition of what makes a valid copyright statement, and say you only have to preserve those.
I think the problem is that some licenses require preservation of "attribution" statements. That's not necessarily the same as the name of the copyright owner in the copyright notice, so we can't limit it to preserving copyright notice only.
Pam
On Thu, Feb 21, 2013 at 09:17:27AM -0500, Pamela Chestek wrote:
On Thu, Feb 21, 2013 at 4:59 AM, Gervase Markham gerv@mozilla.org wrote:
>> Who decides? That sounds like a recipe for lawyer argument. Is it better >> to refer to the OSI license list as of a certain date instead?
[...]
I think that having a clearly defined list is much easier. Then it's pretty obvious to all. In the current set up, I can imagine someone wanting to take advantage of that clause thinking "Hmm, I don't think their pseudo-open license meets the OSD, but they do. So what now?" Pseudo-open is currently observed (if not common), and we should plan for it possibly remaining so.
True. I suppose at some point I felt that for purposes of keeping this provision from being too complex some lack of precision or introduction of pathological possibilities was tolerable. (I note that the OSI has, in the distant past (long before the tenure of current board members :), approved some rather questionable licenses, and has shown no inclination to revisit past decisions.)
But the 'prevent complexity' argument supports referring to the OSI list too.
What about the Fedora list?
That is out of the question, since Fedora has an intimate relationship with $DAYJOB and I have personally worked on the maintenance of that list with my $DAYJOB colleague Tom Callaway. It's bad enough that this mailing list is hosted on fedorahosted.org, which is only because I couldn't figure out how to set up GNU Mailman with a mail server in a working manner and this option happened to be readily available.
Or on any one of the Debian, OSI or Fedora lists?
In an alternate universe Debian would be nice, but in ours Debian is out of the question, because it has no true 'list' other than "whatever covers what we distribute in main". It is quite clear that Debian engages in little if any scrutiny of such licenses. At least the OSI has a well-defined process for approval of licenses.
So the best option is the OSI list, for all its faults. One that I also considered is the FSF list (or the bkuhn-style intersection of those two lists, but the FSF list of free and nonfree licenses has never aimed for comprehensiveness. That's true in a different sense for the OSI list, to be sure, but at least the OSI has a publicized process for what gets approved. The FSF list seems to be more like a set of interesting examples.
Even if you disagree with the judgment of a particular list it will be a very fringe case, and I agree with Gerv that certainty is better than uncertainty in this case.
That is true for the OSI list, and indeed the fringe case problem would exist under the current formulation, since one can very compellingly argue that a given fringe license that happened to be approved by the OSI in the early 2000s must meet the OSD which is maintained by the body that approved such license presumably in relation to the OSD.
I believe I may have been worried about the perception of a fairness problem, as hundreds of clearly-FLOSS (I would like to say 'clearly-OSD-compliant') licenses have not been and undoubtedly never will be approved by the OSI. But that's probably not a big problem, and in any case where it would be the solution would be to seek OSI approval for the license in question, which might be worthwhile for everyone.
- RF
On Thu, Feb 21, 2013 at 09:59:16AM +0000, Gervase Markham wrote:
Is it considered that there is no need for a system library exception? Is that because the definition of Derived Work does not cover system libraries?
Sort of. The old system library exception can be seen as built into the definition of 'Separate Work'. At least that was the intention. I am not at all of the view that this definition could not be made better.
Reversing the question, how can we make it clear that it's OK to ship Windows binaries of copyleft-next code?
That is a good way of stating the issue. In my experience, these days that's a common specific circumstance in which thinking about the system library exception (or some broader understanding of it) comes up.
- Has consideration been given to combining how section 2 works with how
section 8 works?
I haven't thought about that, beyond being aware of the inelegance that I introduced in referring in section 2 to the Apache License (which I did in a recent change because I thought it might make the provision easier to understand -- this was a response to the comments on Martin's article on LWN.net).
I think there's clarity and self-containedness in having a "waive these sections" approach rather than a "use this totally different license" approach, if for no other reason that you don't have the issue which is addressed by the "if you change the license in this way, no additional rights are granted" language you now see in some licenses.
Yes.
Maybe the mere change in the section title does a lot to make the point of the section clearer to the casual reader.
- RF
On Feb 21, 2013 11:15 PM, "Richard Fontana" fontana@sharpeleven.org wrote:
On Thu, Feb 21, 2013 at 09:59:16AM +0000, Gervase Markham wrote:
I think there's clarity and self-containedness in having a "waive these sections" approach rather than a "use this totally different license" approach, if for no other reason that you don't have the issue which is addressed by the "if you change the license in this way, no additional rights are granted" language you now see in some licenses.
Yes.
Actually, the sunset clause and the waiver of the copyleft clauses create a de facto permissive-next. That makes it important to take this license seriously now, rather than as a possible future project.
Is the de facto permissive-next a good license? What separates it from its peers, like "BSD-new" and MIT?
On Fri, Feb 22, 2013 at 01:31:09AM +0800, Claes Wallin (韋嘉誠) wrote:
Actually, the sunset clause and the waiver of the copyleft clauses create a de facto permissive-next. That makes it important to take this license seriously now, rather than as a possible future project.
Good point.
Is the de facto permissive-next a good license? What separates it from its peers, like "BSD-new" and MIT?
Well, it has an explicit patent license grant (with defensive suspension), a _de rigeur_ feature of what I believe Simon Phipps calls 'modern' open source licenses. [1]
Probably the better comparison would be to the Apache License 2.0, which seems to be put forward by some (including, most notably, the FSF) as the 'best' noncopyleft license available today.
It might be useful to actually create this de facto permissive-next as a separate document just to be able to think about it more clearly (e.g. to see how it compares to the Apache License).
- RF
[1] Careful followers of changes to the copyleft-next repository will note that I recently changed the README.md file to describe copyleft-next as "post-post-modern". :-)
On 21/02/13 15:15, Richard Fontana wrote:
On Thu, Feb 21, 2013 at 09:59:16AM +0000, Gervase Markham wrote:
Reversing the question, how can we make it clear that it's OK to ship Windows binaries of copyleft-next code?
That is a good way of stating the issue. In my experience, these days that's a common specific circumstance in which thinking about the system library exception (or some broader understanding of it) comes up.
OK... so I don't know the answer to this without reinventing the system library exception. Does anyone else?
Gerv
On Mon, Feb 25, 2013 at 04:46:30PM +0000, Gervase Markham wrote:
On 21/02/13 15:15, Richard Fontana wrote:
On Thu, Feb 21, 2013 at 09:59:16AM +0000, Gervase Markham wrote:
Reversing the question, how can we make it clear that it's OK to ship Windows binaries of copyleft-next code?
That is a good way of stating the issue. In my experience, these days that's a common specific circumstance in which thinking about the system library exception (or some broader understanding of it) comes up.
OK... so I don't know the answer to this without reinventing the system library exception. Does anyone else?
Not me, not yet.
The only thing I know for sure is that we don't want to use the GPLv3 version of the system library exception. :)
- RF
On Thu, Feb 21, 2013 at 12:40 AM, Richard Fontana fontana@sharpeleven.orgwrote:
On Wed, Feb 20, 2013 at 01:35:44PM +0000, Gervase Markham wrote:
Some licensing documents disclaim e.g. the application of the United Nations Convention on Contracts for the International Sale of Goods. Do they have good reason to do so,
I don't actually know. I confess that as far as I can recall I've never looked at that Convention. The most coherent argument I have heard from a lawyer on this point was something to the following effect: 'no one really knows what's in that Convention, or whether it applies to software, but whatever is in it might be bad' (paraphrasing heavily of course). I think the main reason we see this being excluded is because someone initially decided to do so and this started a process in which lawyers drafting licensing agreements all followed suit.
FWIW, that's my understanding too. But we may have gotten our understanding from the same person. :-)
- "or "powered by" statements"
Is this too specific, or are we hoping a judge would understand this as referring to a class of statements? E.g. if there was a "FooBar Inside" statement instead of "Powered by FooBar"...
This is just a clarification of what kinds of things absolutely are not 'Legal Notices'. It isn't meant to be exhaustive, but I did recently add 'Powered by statements' because that is such a common form in which I've seen the problematic condition.
When Gerv raised this, I wondered why the word "trademarks" isn't in there. When I suggested adding "trademark legends" I'm SURE I had a good reason not to add "trademarks," but for the life of me I can't figure it out now. Maybe I was thinking about the case where a name is also a trademark, so in the copyright notice the company name would also be trademark? But that seems a silly thing to worry might get misinterpreted.
So if no one else can think of a good reason not to say "trademark," doesn't it make sense to say "but does not include logos, other graphical images, _trademarks or_ trademark legends[, or "powered by" statements]." That will take care of all the "powered by," "built on," "inside" statements.
Pam
On Thu, Feb 21, 2013 at 09:07:50AM -0500, Pamela Chestek wrote:
> * "or "powered by" statements" > > Is this too specific, or are we hoping a judge would understand this as > referring to a class of statements? E.g. if there was a "FooBar Inside" > statement instead of "Powered by FooBar"... This is just a clarification of what kinds of things absolutely are not 'Legal Notices'. It isn't meant to be exhaustive, but I did recently add 'Powered by statements' because that is such a common form in which I've seen the problematic condition.
When Gerv raised this, I wondered why the word "trademarks" isn't in there. When I suggested adding "trademark legends" I'm SURE I had a good reason not to add "trademarks," but for the life of me I can't figure it out now. Maybe I was thinking about the case where a name is also a trademark, so in the copyright notice the company name would also be trademark? But that seems a silly thing to worry might get misinterpreted.
I believe something like that had occurred to me. *Maybe* it would be silly, but based on past experience I can anticipate *some* critical readers saying that there's a contradiction (or, worse, a trap) because you have to preserve copyright notices.
That said, if you'd used 'trademarks or trademark legends' in your version I suspect I would have used that.
So if no one else can think of a good reason not to say "trademark," doesn't it make sense to say "but does not include logos, other graphical images, _trademarks or_ trademark legends[, or "powered by" statements]." That will take care of all the "powered by," "built on," "inside" statements.
It's a good solution, apart from the concern noted above.
- RF
On Thu, Feb 21, 2013 at 10:23 AM, Richard Fontana fontana@sharpeleven.orgwrote:
On Thu, Feb 21, 2013 at 09:07:50AM -0500, Pamela Chestek wrote:
> * "or "powered by" statements" > > Is this too specific, or are we hoping a judge would understand
this as
> referring to a class of statements? E.g. if there was a "FooBar
Inside"
> statement instead of "Powered by FooBar"... This is just a clarification of what kinds of things absolutely are not 'Legal Notices'. It isn't meant to be exhaustive, but I did recently add 'Powered by statements' because that is such a common form in which I've seen the problematic condition.
When Gerv raised this, I wondered why the word "trademarks" isn't in
there.
When I suggested adding "trademark legends" I'm SURE I had a good reason
not to
add "trademarks," but for the life of me I can't figure it out now.
Maybe I was
thinking about the case where a name is also a trademark, so in the
copyright
notice the company name would also be trademark? But that seems a silly
thing
to worry might get misinterpreted.
I believe something like that had occurred to me. *Maybe* it would be silly, but based on past experience I can anticipate *some* critical readers saying that there's a contradiction (or, worse, a trap) because you have to preserve copyright notices.
It would be a pretty frivolous argument to make. Just because a word is both a trade name and a trademark doesn't mean that use as a trade name is use as a trademark. (I tried to figure out a clever formula with "=" and "!=" that you guys do but couldn't come up with one ...)
I say go with "trademarks or trademark legends."
Pam
copyleft-next [-0.1.1-] {+0.2.0+} ("this License") Release date: [-2013-02-08-] {+2013-02-19+}
- License [-Grants.-] {+Grants+}
Not a change, but does the word "License" add anything here?
Subject to the terms of this License, [-We-] {+I+} grant You:
a) A non-exclusive, worldwide, perpetual, royalty-free, irrevocable copyright license, to [-make, copy, Distribute,-] {+reproduce, distribute, prepare derivative works of,+} publicly perform and publicly display [-Covered Works, in any medium.-] {+My Work.+}
b) A non-exclusive, worldwide, perpetual, royalty-free, irrevocable patent license under Licensed Patents to make, have made, use, sell, offer for sale, and import Covered Works.
This License does not {+grant any rights in My name, trademarks, service marks, or logos.
Not a substantial change, but I wonder why the substance is needed. The grant is explicitly one of copyright. Lots of popular FLOSS licenses don't mention trademark.
This License does not+} exclude or limit any rights You have under applicable [-copyright-] law.
This seems like either superfluous (better for a FAQ), or bad policy. Are the contours of contemporary copyright exceptions really the right ones for software freedom? If one might be forced to comply with terms (ie releasing under copyleft-next and revealing source) even if they might be able to get away with it due to some copyright exception, might it not be a bad idea to explicitly eliminate the possibility?
[-No Trademark License.
This License does not grant any rights in Our name, trademarks, service marks, or logos.
Effect-] {+Nullification+} of [-Proprietary Relicensing.-] {+Copyleft/Proprietary Dual Licensing+}
Nice word.
If, more than one year after [-Our-] {+My+} first [-Distribution-] {+distribution+} of [-the Received-] {+My+} Work under this License, [-We-] {+I+} offer to license a [-work that would be a-] Covered Work [-had You prepared it, under terms other than (i)-] {+in+} a [-version of copyleft-next released by-] {+manner that fails to satisfy+} the [-Copyleft-Next Project, (ii) a license authorized under section 10, or (iii) a license approved-] {+Open Source Definition published+} by the Open Source Initiative as of 1 January 2013, [-sections 4 through 8 of this License no longer apply-] {+then I additionally license My Work+} to [-You.
4.-] {+You under the Apache License (excluding any preexisting material contained in My Work over which I do not hold copyright).
3.+} Distribution: General [-Conditions.-] {+Conditions+}
You may [-Distribute-] {+distribute+} Covered Works, provided that You (i) inform recipients how they can obtain a copy of this License; (ii) satisfy the applicable conditions of sections [-5-] {+4+} through [-8;-] {+7;+} and (iii) preserve all Legal Notices contained in [-the Received-] {+My+} Work (to the extent they remain pertinent). "Legal Notices" means copyright notices, license notices, license texts, and author attributions, but does not include logos, other graphical [-images or-] {+images,+} trademark [-legends.
5.-] {+legends, or "powered by" statements.
4.+} Conditions for Distributing Derived [-Works.-] {+Works; Outbound GPL Compatibility+}
If You [-Distribute-] {+distribute+} a Derived Work, You must license the entire Derived Work as a whole under this License, with prominent notice of such licensing. This condition may not be avoided through such means as separate [-Distribution-] {+distribution+} of portions of the Derived Work.
[-6.-]
{+You may additionally license the Derived Work under any version of the GNU General Public License published by the Free Software Foundation ("GPL"), so that the recipient may further distribute the Derived Work under either this License or the GPL.
I agree with comment elsewhere that I can't find now that v2+ would be good to specify.
5.+} Condition Against Further [-Restrictions.-] {+Restrictions+}
When [-Distributing-] {+distributing+} a Covered Work, You may not impose further restrictions on the exercise of rights in the Covered Work granted under this License. This condition is not excused merely because such restrictions result from Your compliance with conditions or obligations extrinsic to this License (such as a court order or an agreement with a third party). Mere [-Distribution-] {+distribution+} of a Covered Work incorporating material licensed under the Apache License [-2.0-] does not impose further restrictions under this section.
[-7.-]
{+6.+} Conditions for Distributing Object Code [-in Products.-]
You may [-Distribute-] {+distribute+} an Object Code form of a Covered [-Work in a physical product or tangible storage medium ("Product"),-] {+Work,+} provided that [-You-] {+you+} accompany the [-Product-] {+Object Code+} with [-either: (i) a durable physical medium customarily used for software interchange that contains the Corresponding Source of the Covered Work, or (ii)-] notice of a network location through which [-such-] {+the+} Corresponding Source is {+made+} available, at no charge, {+by some standard or customary means of providing network access to source code.
If you distribute the Object Code in a physical product or tangible storage medium ("Product"), the Corresponding Source must be available through such a network location+} for two years from the date of Your most recent Distribution of the [-Covered Work-] {+Object Code+} in the Product. [-In either case,-] {+However, if You accompany the Product with a durable physical medium, customarily used for software interchange, that contains the+} Corresponding [-Source must be provided under-] {+Source, You need not also comply with the first paragraph of+} this [-License.
Conditions for Network Distribution-] {+section.
Each recipient+} of [-Object Code.-] {+the Covered Work from+} You [-may Distribute-] {+is+} an [-Object Code form-] {+intended third-party beneficiary of this License solely as to this section 6, with the right to enforce its terms.
Great! As I said in https://identi.ca/conversation/98623601#notice-99639053 it'd be nice to see this expanded to license, not only source. Not that I have any idea how to do so.
Symmetrical Licensing Condition for Upstream Contributions
If You distribute a work to Me specifically for inclusion in or modification+} of a Covered Work [-through a computer network, provided that-] {+(Your "Patch"), then, unless Your Patch explicitly states otherwise,+} You [-accompany-] {+license it to Me under this License, to+} the [-Object Code with clear directions indicating how-] {+extent of Your copyright in Your Patch. This condition does not negate+} the [-Corresponding Source may be obtained under-] {+other conditions of this License, if applicable to Your Patch.
Copyleft Sunset
Conditions 3 through 6 of+} this License {+cease to apply to You 15 years+} from [-a network location at no charge and in a reasonably equivalent manner.-] {+the date of My first distribution of My Work under this License.+}
Interesting that 2 is not sunset; a weak non-source-requiring copyleft is retained for duration. This seems reasonable.
[-Pass-Through.-] {+Pass-Through+}
When You [-Distribute-] {+distribute+} a Covered Work, the recipient automatically receives [-from Us-] a license to [-the Received-] {+My+} Work {+from Me,+} subject to the terms of this License.
[-Outbound (A)GPL Compatibility.
You may Distribute a Covered Work under one or more of the following licenses published by the Free Software Foundation: (i) GNU General Public License, version 2; (ii) GNU Affero General Public License, version 3; (iii) later versions of the foregoing licenses.
Termination.-] {+Termination+}
Your license grants under section 1 are automatically terminated if You
a) fail to comply with the conditions of this License, unless You cure such noncompliance within thirty days after becoming aware of it, or
b) initiate a patent infringement litigation claim (excluding declaratory judgment actions, counterclaims, and cross-claims) alleging that any part of [-the Received-] {+My+} Work directly or indirectly infringes any patent.
Termination [-of Your rights-] disqualifies You from receiving new licenses covering [-the Received-] {+My+} Work, but it does not terminate the rights of those who have received copies or rights from You subject to this License.
To the extent permission to make copies of a Covered Work is necessary merely for running it, such permission is not terminable.
[-12.-]
{+11.+} Later License [-Versions.-] {+Versions+}
The Copyleft-Next Project may release new versions of copyleft-next, designated by a distinguishing version number ("Later Versions"). Unless [-We-] {+I+} explicitly remove the option of [-Distributing-] {+distributing+} Covered Works under Later Versions, You may [-Distribute-] {+distribute+} Covered Works under any Later Version.
[-**************************************************************************
*
- 13.-]
{+** 12.+} No [-Warranty. *
*
The Received-] {+Warranty **
** My+} Work is provided "as-is", without warranty. You bear [-* *-] the risk {+** **+} of using it. To the extent permitted by applicable law, [-* *-] each [-Distributor-] {+** ** distributor of My Work+} excludes the implied warranties of title, [-* *-] {+** **+} merchantability, fitness for a particular purpose and [-* *-] {+** **+} non-infringement. [-*
*
*
- 14.-] {+**
** 13.+} Limitation of [-Liability. *
*
*-] {+Liability **
**+} To the extent permitted by applicable law, in no event will any [-*
Distributor-] {+**
** distributor of My Work+} be liable to You for any damages {+** **+} whatsoever, whether [-* *-] direct, indirect, special, incidental, or {+** **+} consequential damages, [-* *-] whether arising under contract, tort {+** **+} (including negligence), or [-* *-] otherwise, even where the [-Distributor-] {+distributor ** **+} knew or should have known [-* *-] about the possibility of such damages. [-*
*
Severability.-] {+**
Severability+}
The invalidity or unenforceability of any provision of this License does not affect the validity or enforceability of the remainder of this License. Such provision is to be reformed to the minimum extent necessary to make it valid and enforceable.
[-16. Definitions.-]
{+15. Definitions
"Apache License" means the Apache License, version 2.0, as published by the Apache Software Foundation.+} "Copyleft-Next Project" means the project that maintains the source code repository at <https://gitorious.org/copyleft-next/> as of the release date of this License. "Corresponding Source" of a Covered Work in Object Code form means (i) the Source Code form of the Covered Work; (ii) all scripts, instructions and similar information that are reasonably necessary for a skilled developer to generate the Covered Work from the Source Code provided under (i); and (iii) a list clearly identifying all Separate Works (other than those provided in compliance with (ii)) that were specifically used in building and installing the Covered Work (for example, a specified proprietary compiler including its version number). Corresponding Source must be machine-readable. "Covered Work" means [-the Received-] {+My+} Work or a Derived Work. "Derived Work" means a work of authorship that copies from, modifies, adapts, is based on, [-contains, transforms or-] {+is a derivative work of, transforms,+} translates {+or contains+} all or part of [-the Received-] {+My+} Work. Derived Works do not include Mere Aggregation or [-the mere making of-] a [-verbatim copy-] {+mere reproduction+} of [-the Received Work. "Distribute" means to distribute, transfer or make a copy available to someone else. "Distributor" means Us and anyone else who Distributes a Covered-] {+My+} Work. "Licensed Patents" means all patent claims licensable by [-Us,-] {+Me,+} now or in the future, that are necessarily infringed by making, using, or selling [-the Received-] {+My+} Work, and excludes claims that would be infringed only as a consequence of further modification of [-the Received-] {+My+} Work. "Mere Aggregation" means an aggregation of a Covered Work with a Separate Work. "Object Code" means any form of a work that is not Source Code. [-"Received-] {+"My+} Work" means the particular work of authorship [-We-] {+I+} license to You under this License. "Separate Work" means a work that is separate from and independent of a particular Covered Work and is not by its nature an extension or enhancement of the Covered Work, and/or a runtime library, standard library or similar component that is used to generate an Object Code form of a Covered Work. "Source Code" means the preferred form of a work for making modifications to it. [-"We"/"Us"/"Our"-] {+"I"/"Me"/"My"+} refers to the individual or legal entity that places [-the Received-] {+My+} Work under this License. "You"/"Your" refers to the individual or legal entity exercising rights in [-the Received-] {+My+} Work under this License. [-For-] {+A+} legal [-entities, "You"-] {+entity+} includes [-any-] {+each+} entity that controls, is controlled by, or is under common control with [-You.-] {+such legal entity.+} "Control" means (a) the power to direct the actions of such {+legal+} entity, whether by contract or otherwise, or (b) ownership of more than fifty percent of the outstanding shares or beneficial ownership of such {+legal+} entity.
Releases/copyleft-next-0.1.1: 1402 words 1029 73% common 52 4% deleted 321 23% changed Releases/copyleft-next-0.2.0: 1460 words 1029 70% common 76 5% inserted 355 24% changed
This is a neat release, worth 58 word gain, but maybe some can be lost. :)
Mike
On Wed, Feb 20, 2013 at 03:30:16PM -0800, Mike Linksvayer wrote:
copyleft-next [-0.1.1-] {+0.2.0+} ("this License") Release date: [-2013-02-08-] {+2013-02-19+}
- License [-Grants.-] {+Grants+}
Not a change, but does the word "License" add anything here?
Not really. Maybe marginal clarity? I'm always on the lookout for deleting words.
This License does not {+grant any rights in My name, trademarks, service marks, or logos.
Not a substantial change, but I wonder why the substance is needed. The grant is explicitly one of copyright. Lots of popular FLOSS licenses don't mention trademark.
That is true. As I think I noted on identica, I was influenced here by past discussions (not about this license, but FLOSS generally) with Pam Chestek. If she sees this, maybe she'd be willing to provide a better justification than I can (for why, say, the GPL might be better off with this kind of clause as a built-in provision - GPLv3 explicitly authorizes such a clause as an 'additional requirement'), though I note that I'm solely to blame for putting this provision in. It was actually one of the first things I added when working from the GPLv3 text, as I recall.
This License does not+} exclude or limit any rights You have under applicable [-copyright-] law.
This seems like either superfluous (better for a FAQ), or bad policy. Are the contours of contemporary copyright exceptions really the right ones for software freedom? If one might be forced to comply with terms (ie releasing under copyleft-next and revealing source) even if they might be able to get away with it due to some copyright exception, might it not be a bad idea to explicitly eliminate the possibility?
Although I liked the generalization I'm now thinking of deleting it for 0.2.1 (more because it's probably mostly superfluous and seems ultimately to be the product of an early 21st century Zeitgeist).
I think I'll have to weigh what you've just said against what Pam said a few days ago in response to something Luis said.
{+You may additionally license the Derived Work under any version of the GNU General Public License published by the Free Software Foundation ("GPL"), so that the recipient may further distribute the Derived Work under either this License or the GPL.
I agree with comment elsewhere that I can't find now that v2+ would be good to specify.
Yes, that seems to make good sense.
- RF
On Wed, Feb 20, 2013 at 11:56 PM, Richard Fontana fontana@sharpeleven.orgwrote:
On Wed, Feb 20, 2013 at 03:30:16PM -0800, Mike Linksvayer wrote:
This License does not {+grant any rights in My name, trademarks,
service
marks, or logos.
Not a substantial change, but I wonder why the substance is needed. The grant is explicitly one of copyright. Lots of popular FLOSS licenses don't mention trademark.
That is true. As I think I noted on identica, I was influenced here by past discussions (not about this license, but FLOSS generally) with Pam Chestek. If she sees this, maybe she'd be willing to provide a better justification than I can (for why, say, the GPL might be better off with this kind of clause as a built-in provision - GPLv3 explicitly authorizes such a clause as an 'additional requirement'), though I note that I'm solely to blame for putting this provision in. It was actually one of the first things I added when working from the GPLv3 text, as I recall.
I would prefer to leave it. While I have made what I believe is a well-supported argument that open source licenses are not trademark licenses, I don't think it's universally accepted or glaringly obvious, so there is room for a court to decide otherwise. (The "Enigma" decision in Germany is one example of a case where there may have been a somewhat different outcome on trademark infringement because the product was under an open source license.) Most importantly, there are still many users who have not grasped the concept that permission to use the name and the code don't necessarily run together, so I think there is an important audience for an express statement in the license.
Pam
On Tue, Feb 19, 2013 at 10:16:24PM -0500, Richard Fontana wrote:
Good news, everyone! copyleft-next 0.2.0 has been released!
https://gitorious.org/copyleft-next/copyleft-next/blobs/raw/master/Releases/...
A summary of the principal changes relative to 0.1.1 will follow in due course.
Here is the promised summary.
* The term 'We' (the licensor) was changed to 'I'. The plurality of 'We' seemed potentially more confusing.
* 'Received Work' is now 'My Work'. 'Received' was a bit confusing since the licensed work associated with any given instance of copyleft-next coming from a particular licensor might not be the work 'You' receive downstream. (I also considered 'Provided Work'.)
* The copyright license grant in section 1 is more closely tied to (US) statutory language. This implements a pre-0.1.1 suggestion made by Pam Chestek.
* 'Distribute' is no longer a defined term.
* The child-of-fair-use clause was broadened by striking out the word 'copyright'. This has been discussed recently on this list and I am considering deleting the clause altogether.
* What has sometimes been called the 'proprietary relicensing poison pill' has been revised. The new title better conveys the purpose of the provision. The provision is hopefully easier to understand now, though I am already thinking of further improvements, in part in response to comment made here. One notable change is that the effort to negatively define 'proprietary' was previously copyleft-next, GPLv2+/AGPLv3+, or an OSI-approved license; in 0.2.0 it is just distribution in a manner that fail to satisfy the OSD. Another notable change is that instead of saying copyleft provisions no longer apply, the provision now says that 'I' additionally license My Work under the Apache License 2.0.
* The anti-badgeware clarification adds 'powered-by statements' to the list of things that are not preservable 'Legal Notices'.
* In 0.1.1 there was a section indicating that Covered Works can be licensed out under GPLv2+/AGPLv3+. This is deleted and instead the general copyleft section states that, in addition to the basic requirement to license Derived Works under copyleft-next, You may additionally license the Derived Work under any version of the GPL. (I've explained why I don't consider it necesary to deal with the AGPL.) The approach taken here is influenced by MPL 2.0.
* In 0.1.1 there were two sections covering the conditions for distributing object code (one dealing with object code in 'Products', the other with network-distributed Object Code). In 0.2.0 these are merged into one section, with some overall simplification.
* The aforementioned section adds a declaration that downstream recipients are intended third party beneficiaries of this provision, 'with the right to enforce its terms'.
* In particular response to suggestions from Engel Nyst, and reviving an old idea I'd once tried to implement, 0.2.0 adds a condition that states that upstream contribution to 'Me' for incorporation in a Covered Work are, absent indication to the contrary, deemed licensed under copyleft-next. That is, this is a built-in inbound=outbound contribution policy, modeled on (though I think better drafted than) Apache License 2.0 section 5.
* A 'Copyleft Sunset' provision was added that essentially says that 'My Work' is permissively-licensed after 15 years have passed.
* The MPL 2.0-style plain-text conscpicuousness solution for the disclaimer provisions (surrounding them with asterisks) has been replaced with a vertical wall of double asterisks on each side.
* The definition of 'Derived Work' was tweaked a bit.
* The 'legal entity' subdefinition in 'You' now also applies to 'Me'.
- RF
On Tue, Feb 19, 2013 at 10:16 PM, Richard Fontana fontana@sharpeleven.orgwrote:
Good news, everyone! copyleft-next 0.2.0 has been released!
https://gitorious.org/copyleft-next/copyleft-next/blobs/raw/master/Releases/...
I tried, oh I tried so hard, to figure out how to clone and push back changes, but I keep getting error messages about not having run git update-server-info on the server, or not properly identifying a remote repository. So I'm giving up for today.
So, anyway, my comments:
"This License does not exclude or limit any rights You have under applicable law." I agree that this is now fairly mystifying, begging the question "why would I think otherwise?" But it started out as a preservation of fair use rights and as the license is currently written I believe that you have abrogated, some might argue deliberately, uses that would otherwise be considered a lawful use.
So I digress to the definition of Derived Work. I agree that the defined term should be "Derived Work" to avoid any confusion between the defined term and the term of art "derivative work." However, I also believe that a Derived Work should maintain the balance of what copyright law protects and what it doesn't protect. Therefore, "Derived Works" should only describe what are derivative works, or at least what would otherwise be infringements, but the current definition goes well beyond that now.
My beefs are with the words "based on" and "transform." In the former case, this phrase is so vague it could intrude into the area of what one would consider the idea side of the idea-expression dichotomy. I could think "gee, GNU Mailman has nice features, I'm going to create another project with the same features" and it is arguably "based on" GNU Mailman even though it would not be either a derivative work or a copyright infringement.
The word "transforms" is an attack on fair use. That is, "transformative" is a term of art that is one of the hallmarks of a fair use; because a work is "transformative" it may be a fair use. To therefore claim that a work that "transforms" is a "Derived Work" strips away a defense that the modification is a fair use.
I realize that "based on" and "transform" are in the definition of derivative work in the U.S. Copyright Act, but the terms as used here are not tied to the definition of "Derived Work" and so I read them here much more expansively. At some point in the past the definition of "Derived Work" included "such that copyright permission is required," which I think is why I was ok with it in the past, and I'm not sure why it came out. Alternatively, you could tie the definition of "Derived Work" expressly to that of a derivative work, e.g., as "a work of authorship that is a derivative work because it copies from, modifies, adapts, is based on, transforms, translates or contains all or part of My Work." But I think I prefer just preserving "such that copyright permission is required."
If you define "Derived Work" so that it is only covers works that would be a copyright infringement absent the license, then you should remove the "This License does not exclude" paragraph. I say that, but I'm not sure what would happen if you kept this paragraph when there is an over-expansive definition of "Derived Work"; I think the intent is ambiguous. So I guess that means take it out either way, but I think you need to change the definition of "Derived Work" to be sure it will not be interpreted as including uses that would otherwise be lawful. But if you meant to capture lawful uses in the definition of "Derived Work," that's a whole different discussion --
Para. 5: "When distributing a Covered Work, You may not impose further restrictions on the exercise of [rights in] _the grants given for_ the Covered Work [granted under this License]." Just tightening up the language a little. It was the word "rights" that bothered me, I don't think the licensee has "rights" but rather has permission to do what otherwise he or she could not do.
Para. 7: "to the extent of Your copyright in the Patch." I think you can eliminate this clause as redundant; that's all that the person giving the patch can grant anyway, whether you say it or not.
Para. 7: "This condition does not negate the other conditions of this License." I didn't know what that was supposed to accomplish.
Warranty and Limitation of Liability: You've tried to carry these down to distributors, but what if the distributors don't want the advantage of the clauses? What if, as my business model, for a fee I am offering a warranty and a higher limitation of liability that you have offered? Maybe add a "unless waived" provision?
Pam
On Sat, Feb 23, 2013 at 04:40:03PM -0500, Pamela Chestek wrote:
Warranty and Limitation of Liability: You've tried to carry these down to distributors, but what if the distributors don't want the advantage of the clauses? What if, as my business model, for a fee I am offering a warranty and a higher limitation of liability that you have offered? Maybe add a "unless waived" provision?
The GPL (v2 and v3, at least) has language to that effect, both in the disclaimers themselves and in the basic distribution provision. I took the latter language out early on as -- I thought -- stating the obvious. I'd kind of ignored the fact that the disclaimers say "EXCEPT WHEN OTHERWISE STATED IN WRITING" because I mostly scrapped the GPL versions in favor of models from other licenses.
The reason I carried them down to distributors is the assumption that in the usual case the mere redistributor should benefit from them (or shouldn't be expected to make the effort of applying its own disclaimers, though that's likely to happen for commercial redistributors anyway). Do you believe the license prevents a downstream licensee (mere redistributor or otherwise) from departing from the effect of the clauses in a way that would be to the detriment of such downstream licensee?
I assumed it was obvious that you can offer a warranty in the same way that it's obvious (or so I believe) you can offer support or other forms of service.
- RF
On Sat, Feb 23, 2013 at 8:41 PM, Richard Fontana fontana@sharpeleven.orgwrote:
On Sat, Feb 23, 2013 at 04:40:03PM -0500, Pamela Chestek wrote:
Warranty and Limitation of Liability: You've tried to carry these down to distributors, but what if the distributors don't want the advantage of
the
clauses? What if, as my business model, for a fee I am offering a
warranty and
a higher limitation of liability that you have offered? Maybe add a
"unless
waived" provision?
The GPL (v2 and v3, at least) has language to that effect, both in the disclaimers themselves and in the basic distribution provision. I took the latter language out early on as -- I thought -- stating the obvious. I'd kind of ignored the fact that the disclaimers say "EXCEPT WHEN OTHERWISE STATED IN WRITING" because I mostly scrapped the GPL versions in favor of models from other licenses.
The reason I carried them down to distributors is the assumption that in the usual case the mere redistributor should benefit from them (or shouldn't be expected to make the effort of applying its own disclaimers, though that's likely to happen for commercial redistributors anyway). Do you believe the license prevents a downstream licensee (mere redistributor or otherwise) from departing from the effect of the clauses in a way that would be to the detriment of such downstream licensee?
I assumed it was obvious that you can offer a warranty in the same way that it's obvious (or so I believe) you can offer support or other forms of service.
Hmmm, I suppose not. It would require some sophistication on the part of
the entity offering the warranty, though, to expressly state that it was intentionally abrogating the license in this way -- and I doubt that an unsophisticated entity would be offering this service, so no harm. But assuming it was an unsophisticated entity who offered the warranty, if the license isn't specifically referenced you may end up with dueling agreements and therefore interpretation problems.
But I think what's more problematic is whether the attempt to offer the warranty would be considered imposing an additional restriction--I hope not, but nevertheless you are introducing a situation where you are forcing people to say "this part of the copyleft-next license doesn't apply here." I think it's probably better as a policy matter to avoid those situations, particularly where it's easy enough to just say "except where otherwise stated in writing."
Pam
On Sat, Feb 23, 2013 at 04:40:03PM -0500, Pamela Chestek wrote:
Para. 7: "to the extent of Your copyright in the Patch." I think you can eliminate this clause as redundant; that's all that the person giving the patch can grant anyway, whether you say it or not.
Right (though this could possibly be revised in the way suggested by Engel Nyst to take account of contributions containing third-party code).
- RF
On Sat, Feb 23, 2013 at 04:40:03PM -0500, Pamela Chestek wrote:
Para. 5: "When distributing a Covered Work, You may not impose further restrictions on the exercise of [rights in] _the grants given for_ the Covered Work [granted under this License]." Just tightening up the language a little. It was the word "rights" that bothered me, I don't think the licensee has "rights" but rather has permission to do what otherwise he or she could not do
.
Any 'rights' language in copyleft-next (there are actually several uses of it) is basically a holdover from GPLv2/GPLv3. I assume your botheredness would extend to those other uses too -- I admit that I've been bothered by the uses of "rights" myself and have toyed with replacing them with "permissions" in all cases.
Then again, I believe I've seen "rights" used similarly in certain 'plain-English' proprietary software consumer-oriented licenses; there may be a view that it's a more natural way of expressing something that technically isn't really a "right".
The use of "rights" in the GPL also clearly reflects a kind of natural law theory of software freedom. One sees this particularly in the various GPL Preambles which express the view that proprietary software licenses take away freedom that software users would otherwise have. This view is understandable when you consider the legal and cultural origins of the GPL.
- RF
On Sat, Feb 23, 2013 at 9:00 PM, Richard Fontana fontana@sharpeleven.orgwrote:
On Sat, Feb 23, 2013 at 04:40:03PM -0500, Pamela Chestek wrote:
Para. 5: "When distributing a Covered Work, You may not impose further restrictions on the exercise of [rights in] _the grants given for_ the
Covered
Work [granted under this License]." Just tightening up the language a
little.
It was the word "rights" that bothered me, I don't think the licensee has "rights" but rather has permission to do what otherwise he or she could
not do .
Any 'rights' language in copyleft-next (there are actually several uses of it) is basically a holdover from GPLv2/GPLv3. I assume your botheredness would extend to those other uses too -- I admit that I've been bothered by the uses of "rights" myself and have toyed with replacing them with "permissions" in all cases.
Then again, I believe I've seen "rights" used similarly in certain 'plain-English' proprietary software consumer-oriented licenses; there may be a view that it's a more natural way of expressing something that technically isn't really a "right".
The use of "rights" in the GPL also clearly reflects a kind of natural law theory of software freedom. One sees this particularly in the various GPL Preambles which express the view that proprietary software licenses take away freedom that software users would otherwise have. This view is understandable when you consider the legal and cultural origins of the GPL.
Yes, all of those reasons make sense. I don't have strong feelings one way or the other, but mentioned it out of a desire to attain rigor in language. But sometimes rigor only introduces confusion, which might be the case here. I don't think "rights" will be misunderstood or misinterpreted.
Pam
On Sat, Feb 23, 2013 at 04:40:03PM -0500, Pamela Chestek wrote:
So I digress to the definition of Derived Work. I agree that the defined term should be "Derived Work" to avoid any confusion between the defined term and the term of art "derivative work." However, I also believe that a Derived Work should maintain the balance of what copyright law protects and what it doesn't protect. Therefore, "Derived Works" should only describe what are derivative works, or at least what would otherwise be infringements, but the current definition goes well beyond that now.
It intentionally (possibly) goes beyond what are derivative works under U.S. copyright law (correcting the same confusing element of GPLv2 that GPLv3 attempted to correct). However, it is not intended to beyond things that would be copyright infringement.
My beefs are with the words "based on" and "transform." In the former case, this phrase is so vague it could intrude into the area of what one would consider the idea side of the idea-expression dichotomy. I could think "gee, GNU Mailman has nice features, I'm going to create another project with the same features" and it is arguably "based on" GNU Mailman even though it would not be either a derivative work or a copyright infringement.
The word "transforms" is an attack on fair use. That is, "transformative" is a term of art that is one of the hallmarks of a fair use; because a work is "transformative" it may be a fair use. To therefore claim that a work that "transforms" is a "Derived Work" strips away a defense that the modification is a fair use.
I realize that "based on" and "transform" are in the definition of derivative work in the U.S. Copyright Act,
Yes, just to be clear, that's where I got them from. :)
but the terms as used here are not tied to the definition of "Derived Work" and so I read them here much more expansively. At some point in the past the definition of "Derived Work" included "such that copyright permission is required," which I think is why I was ok with it in the past, and I'm not sure why it came out.
Oops, I thought you had suggested that I take the "copyright permission" phrase out. I must have misunderstood, so I'll plan on restoring it in 0.2.1.
Perhaps the elaborate definition, in its current form, even with the restoration of the 'copyright permission' phrase, is not so helpful. I was imitating an approach that had been taken in some other licenses.
But I think I prefer just preserving "such that copyright permission is required."
[...]
If you define "Derived Work" so that it is only covers works that would be a copyright infringement absent the license, then you should remove the "This License does not exclude" paragraph.
Okay.
- RF
On Mon, Feb 25, 2013 at 2:15 PM, Richard Fontana fontana@sharpeleven.orgwrote:
Oops, I thought you had suggested that I take the "copyright permission" phrase out.
It is entirely possible. I reserve my right to notice things a second time that I missed the first, and to disagree with my own changes. :)
Pam
copyleft-next@lists.fedorahosted.org