Hi everybody!
After a considerable and unfortunate hiatus I have resumed development of copyleft-next and feel it is close to appropriate for release of v.0.4.0. Especially given the dormancy I thought I would point any remaining and interested readers of this list to the latest draft: https://gitorious.org/copyleft-next/copyleft-next/raw/3baab310f662811ba48d8a...
The most notable changes are the following:
Section 2b:
(Non-GPL) license compatibility is now dealt with through reference to a brief illustrative appendix list of licenses (which include MPL 2.0, EPL 1.0, and LGPLv3 as well as some non-copyleft licenses).
The issue of compliance with export control regulations is dealt with, something which I have come to view as sorely lacking in the GPL.
Section 3:
This is a new section containing an attempt at an Affero-style condition. Don't laugh at this attempt without trying it yourself first (though I should disclose that my attempt took place within the space of an hour at most this evening). The inclusion of this condition is notable given that at an earlier stage I specifically had decided not to have an Affero-like condition in the main body of the license. The original licensor can opt out. There is a special 'Corresponding Source' definition here that is not identical to the one for distribution of Object Code.
Section 4: The old 'poison pill' provision now includes a definition of 'Proprietary License'.
I have eliminated the effort to include an Apache License 2.0 section 5-style mechanism for formalizing the 'inbound=outbound' rule.
- RF
On 24/02/14 06:23, Richard Fontana wrote:
After a considerable and unfortunate hiatus I have resumed development of copyleft-next and feel it is close to appropriate for release of v.0.4.0.
Nits:
Section 4) has two part iv)s.
Section 9 is missing a space - "isprovided".
More substantive:
You need to rearrange 2 b); at the moment it's unclear what licenses are OK because the definition is split into two bits. So:
Distribution of Covered Code incorporating material governed by a license listed in Appendix A (or an equivalently or comparably permissive free software/open source license) does not impose further restrictions. You have permission to ignore subsection 2c (only) solely to the extent necessary to comply with such other license.
But I do think the bit in brackets is not specific enough and will cause problems.
Gerv
On Mon, Feb 24, 2014 at 6:18 AM, Gervase Markham gerv@mozilla.org wrote:
You need to rearrange 2 b); at the moment it's unclear what licenses are OK because the definition is split into two bits. So:
Distribution of Covered Code incorporating material governed by a license listed in Appendix A (or an equivalently or comparably permissive free software/open source license) does not impose further restrictions. You have permission to ignore subsection 2c (only) solely to the extent necessary to comply with such other license.
But I do think the bit in brackets is not specific enough and will cause problems.
What is the rationale for changing the approach to define free/open licenses?
There are two approaches (that yield precise enough results), as I believe has been mentioned on this list: an enumerated, closed list, and an appeal to authority entities.
In 0.3.0, copyleft-next was using the second. Now it's none of the two: it's an open-ended list (illustrative and non exhaustive), with free wording ("or an equivalently or comparably permissive free software/open license"). If I understand Gerv's concern correctly, I subscribe: this approach is not precise, and introduces a loophole - unless I'm missing something.
Please discuss it before the next version release.
On Sun, 24 Aug 2014 07:09:27 -0400 Engel Nyst engel.nyst@gmail.com wrote:
On Mon, Feb 24, 2014 at 6:18 AM, Gervase Markham gerv@mozilla.org wrote:
You need to rearrange 2 b); at the moment it's unclear what licenses are OK because the definition is split into two bits. So:
Distribution of Covered Code incorporating material governed by a license listed in Appendix A (or an equivalently or comparably permissive free software/open source license) does not impose further restrictions. You have permission to ignore subsection 2c (only) solely to the extent necessary to comply with such other license.
But I do think the bit in brackets is not specific enough and will cause problems.
What is the rationale for changing the approach to define free/open licenses?
There are two approaches (that yield precise enough results), as I believe has been mentioned on this list: an enumerated, closed list, and an appeal to authority entities.
In 0.3.0, copyleft-next was using the second. Now it's none of the two: it's an open-ended list (illustrative and non exhaustive), with free wording ("or an equivalently or comparably permissive free software/open license"). If I understand Gerv's concern correctly, I subscribe: this approach is not precise, and introduces a loophole - unless I'm missing something.
I see the point, but doesn't a similar issue exist under the GPL, with few real problems in practice? The only difference being that the FSF is playing two roles (that of license-drafter-in-the-past and [aspirationally] present-day-authority [on what is or isn't a GPL-compatible license, with the FSF never having purported to provide an exhaustive list]).
Or is this actually a problem with the GPL that a new copyleft license should fix?
Richard
On Sun, Aug 24, 2014 at 1:03 PM, Richard Fontana fontana@sharpeleven.org wrote:
I see the point, but doesn't a similar issue exist under the GPL, with few real problems in practice?
It seems to me that if this is recognized as an "issue," then it deserves some thought. It appears that this not a theoretical issue, but that "real problems" exist.
I have no suggestion at present to resolve the issue, but I do think it is worth further consideration. Please excuse my ignorance, but there is no deadline for the 0.4.0 release, is there? To ask another way, is there any reason why this issue doesn't deserve more thought, or at least more explication?
On Mon, Aug 25, 2014 at 10:35:57AM -0400, Douglas A. Whitfield wrote:
On Sun, Aug 24, 2014 at 1:03 PM, Richard Fontana fontana@sharpeleven.org wrote:
I see the point, but doesn't a similar issue exist under the GPL, with few real problems in practice?
It seems to me that if this is recognized as an "issue," then it deserves some thought. It appears that this not a theoretical issue, but that "real problems" exist.
I have no suggestion at present to resolve the issue, but I do think it is worth further consideration. Please excuse my ignorance, but there is no deadline for the 0.4.0 release, is there?
No deadlines. (The hope is to reach the 3.0.0 release within about 17 years, but preferably sooner. :)
To ask another way, is there any reason why this issue doesn't deserve more thought, or at least more explication?
No - it certainly deserves further thought or discussion.
Thanks, Richard
On 08/24/2014 01:03 PM, Richard Fontana wrote:
I see the point, but doesn't a similar issue exist under the GPL, with few real problems in practice? The only difference being that the FSF is playing two roles (that of license-drafter-in-the-past and [aspirationally] present-day-authority [on what is or isn't a GPL-compatible license, with the FSF never having purported to provide an exhaustive list]).
It's not the only difference at this time. In 0.3.0, copyleft-next has modified the traditional no further requirements provision to accept that a set of licenses don't pose further requirements. In the pre-0.4.0 draft, it has also modified the condition to be under this license, to be interpreted loosely as necessary to accommodate these licenses.
By doing both adjustments, the freedoms granted for the overall distribution depend now on these licenses giving these freedoms themselves. That is ok, but with the change in the definition of open/free licenses, there's no longer any check that they're giving them.
You have introduced in the text that CCS remains in full force. Right, but CCS is not the only thing that an overarching copyleft guarantees for the incorporated code.
How about, I don't know, redistribution? I don't see what enforces that all the contained material is free to distribute. How about just about any of the criteria that a free license must pass? If I'm missing something, please point it out.
For example, I include a component with some proprietary license (non-commercial), make it interact with the copyleft-next-ed code, and distribute the result together under copyleft-next-except-where-nc. It seems this derived work passes all criteria in the draft... Why can't I do that with GPL? No further restrictions and license under this license. Why can't I do that with 0.3.0? No further restrictions except if FSF/OSI vetted.
Or is this actually a problem with the GPL that a new copyleft license should fix?
I think copyleft-next has solved the problem of license incompatibility, in the measure it was assumed to be in the nature of copyleft[1], in 0.3.0 already. The major change is possibly to no further restrictions clause because after the change, the text implies or suggests that the whole work being under this license should be read loosely, loose enough that copylefts make the bar. The subsequent change to the license for the whole work (2c) is consistent with this loose interpretation.
OTOH, the practice we see around GPL obviously doesn't show only issues due to incompatibilities. There is also a lot of practice around it, that interprets freedom-respecting software as acceptable; indeed, but this practice was built due to the regulatory role of license conditions. GPL can't be used with non-free software [and some free], so yes, we'll see it with a (certain) number of free software licenses.
If we remove too much of what "license under this license"-and-friends were doing, without enough conditions in their place, we end up with no such regulatory role... that is, no copyleft to the extent of copyright.
[1] https://lists.fedorahosted.org/pipermail/copyleft-next/2012-August/000114.ht...
On 02/24/2014 12:23 AM, Richard Fontana wrote:
After a considerable and unfortunate hiatus I have resumed development of copyleft-next and feel it is close to appropriate for release of v.0.4.0.
In addition to Gerv's Nits...
Could you explain the rationale for changing from referring to "My Work" to "My Code"? Is this an explicit attempt to the narrow the scope to software (vs. other artifacts like artwork, documentation, etc.)?
Section 2b: (Non-GPL) license compatibility is now dealt with...
"You have permission to ignore subsection 2c solely to the extent necessary to comply with such other license"
Does this solve the gridlock from typical license text language which says, effectively, "you may combine other code as long as the combined work is licensed under THIS license"?
For example if an EPL-1.0 work is combined with a copyleft-next work can the result be combined such that the EPL-1.0 governs only the first part and copyleft-next the latter part -- unless such a separation is infeasible. If the code is mixed would the fused work need to be licensed solely under EPL-1.0 or would some or all of the copyleft-next restrictions also apply?
Is elaborating a list of Code build dependencies be included in the intent of 2.d.iii?
+ Each recipient of Covered Code from You is an intended third-party + beneficiary of this License solely as to this subsection 2d, with the + right to enforce its terms.
Is there any way this idea could expand to give users "standing" in the copyright license? Does the above language accomplish this goal?
Section 3: This is a new section containing an attempt at an Affero-style condition.
Does this mean that previously signaled intent to create "copyleft-next-ns" has been folded into the current draft of copyleft-next?
Is there a "verbatim" loophole? If My Code is simply hosted on a network as is without any changes does §3 no longer apply?
The use of "NSS" is unfortunate as it clashes with https://en.wikipedia.org/wiki/Network_Security_Services
How does this provision of copyleft-next differ from this FSF interpretation of the AGPLv3? http://www.gnu.org/licenses/why-affero-gpl.html "If some program on this server is released under the GNU Affero GPL, the server is required to offer the users the corresponding source of that program. That is good, but having this source code does not give them control over the computing done on that server. It also does not tell them what other software may be running on that server, examining or changing their data in other ways."
CC0-1.0 https://creativecommons.org/publicdomain/zero/1.0/legalcode
Is there an advantage in referring the plain text version of this license? https://creativecommons.org/publicdomain/zero/1.0/legalcode.txt
Does OSI offer plain text versions of approved licenses?
http://www.apache.org/licenses/LICENSE-2.0.txt
MPL-2.0 http://www.mozilla.org/MPL/2.0/
http://www.mozilla.org/MPL/2.0/index.txt
Apparently the simplest the Eclipse Foundation can imagine is "plain HTML": http://eclipse.org/org/documents/epl-v10.php
https://www.gnu.org/licenses/lgpl.txt
Thanks for the awesome work on copyleft-next!
--Tom
On Thu, 27 Feb 2014 22:42:11 -0600 Tom Marble tmarble@info9.net wrote:
Section 3: This is a new section containing an attempt at an Affero-style condition.
Does this mean that previously signaled intent to create "copyleft-next-ns" has been folded into the current draft of copyleft-next?
Yes. I'm currently convinced that a new copyleft license is largely pointless without an 'Affero provision' by default. However this makes the drafting effort much more difficult. I actually think my 1-2 hour attempt, while quite suboptimal, is better than AGPLv3 or any predecessor licenses that tried to tackle this issue (typically by expanding the definition of 'distribution', an unworkable approach if you ask me).
Is there a "verbatim" loophole? If My Code is simply hosted on a network as is without any changes does §3 no longer apply?
If there are no changes relative to "My" Code, then section 3 does not apply. One thing that this provision tries to clarify is an interpretive disagreement I had with bkuhn over AGPLv3 at OSCON 2013. This is that a mere distributor of an AGPLv3 work which the distributor has modified (I suppose it would have to be modified to become an AGPLv3-interesting work) must contain something in it that is expected to cause automatic compliance with the AGPLv3 requirement for the recipient who hosts a 'verbatim' version.
I was reading AGPLv3 more narrowly than bkuhn was, and I'm still not totally convinced he's right as far as AGPLv3 interpretation is concerned. But I think he's probably right as a policy matter.
So 'verbatim' code is supposed to already be in compliance. In any case where it isn't, it either isn't 'Your' fault or else 'I' didn't really care about 'You' complying with this provision.
The use of "NSS" is unfortunate as it clashes with https://en.wikipedia.org/wiki/Network_Security_Services
Yeah, I had the same thought. I'll change it or maybe unify the currently dual definitions of Corresponding Source.
How does this provision of copyleft-next differ from this FSF interpretation of the AGPLv3? http://www.gnu.org/licenses/why-affero-gpl.html "If some program on this server is released under the GNU Affero GPL, the server is required to offer the users the corresponding source of that program. That is good, but having this source code does not give them control over the computing done on that server. It also does not tell them what other software may be running on that server, examining or changing their data in other ways."
My twin definitions of Corresponding Source are intentionally somewhat broader than the definition in GPLv3/AGPLv3, notably in adopting a couple of suggestions that originated with bkuhn, who probably won't read this message for another few years.
CC0-1.0 https://creativecommons.org/publicdomain/zero/1.0/legalcode
Is there an advantage in referring the plain text version of this license? https://creativecommons.org/publicdomain/zero/1.0/legalcode.txt
Well, the main point of the references here is just to clarify (to a reasonably satisfactory degree) what is meant by a given license label. I don't think merely listing the common name of the license is enough. I've used the SPDX abbreviations here, a concession of sorts (since I personally dislike the SPDX abbreviations for aesthetic reasons).
Does OSI offer plain text versions of approved licenses?
Er, I don't think so, or at least if it does it's not obvious to me where they are. :)
- RF
On Thu, 27 Feb 2014 22:42:11 -0600 Tom Marble tmarble@info9.net wrote:
On 02/24/2014 12:23 AM, Richard Fontana wrote:
Could you explain the rationale for changing from referring to "My Work" to "My Code"? Is this an explicit attempt to the narrow the scope to software (vs. other artifacts like artwork, documentation, etc.)?
No substantive change is implied. You can use this license for non-software works, though as with the GPL it is oriented towards software. As for the rationale, it's really just annoyance with the term 'work'.
Section 2b: (Non-GPL) license compatibility is now dealt with...
"You have permission to ignore subsection 2c solely to the extent necessary to comply with such other license"
Does this solve the gridlock from typical license text language which says, effectively, "you may combine other code as long as the combined work is licensed under THIS license"?
Sort of. It's intended to get around the problem of arguably conflicting copyleft requirements, without taking a position on what they actually mean. The idea is no one can argue that copyleft-next is incompatible with MPL 2.0, EPL 1.0 or even LGPL (or vice-versa). The intent is that you still have to provide Corresponding Source, even for the part of the derivative work that is under the other copyleft license, if you distribute binaries.
For example if an EPL-1.0 work is combined with a copyleft-next work can the result be combined such that the EPL-1.0 governs only the first part and copyleft-next the latter part -- unless such a separation is infeasible.
I'm not sure it's clear how the EPL part can be licensed if we're talking about a binary. If it's LGPL let's assume that I have to put the LGPL part of the binary under LGPL (though that might not be a correct interpretation of any particular version of the LGPL). With EPL, I shouldn't be able to put the EPL part under a proprietary license. I think it ought to be okay to put it under EPL. It also ought to be okay to put it under copyleft-next (something I assume you couldn't do with LGPL, and certainly not GPL). There might be a problem here, or at least this needs some further work.
If the code is mixed would the fused work need to be licensed solely under EPL-1.0 or would some or all of the copyleft-next restrictions also apply?
This may depend on how you interpret EPL and also when you think 'fusing' has occurred (related questions). Again I think this can probably be made clearer though I don't want the result to be 'treat EPL like GPL' (one-way compatibility).
Is elaborating a list of Code build dependencies be included in the intent of 2.d.iii?
This originated in some discussions with bkuhn. See: https://www.softwarefreedom.org/resources/2008/compliance-guide.html#x1-1800... which I think reflects bkuhn's views in 2008. This is an expansion of the corresponding source code requirement as it exists in GPLv2 and GPLv3.
An argument might be made that this is not practical as currently worded (unless you interpret it narrowly enough to be practical, which is what I intended). It's easy enough to say "We used an internally-modified version of GCC based on version 4.8.2", which I don't think is an unreasonable or excessively burdensome thing to have to disclose, but I'm not sure where it stops. Too bad bkuhn no longer reads this list, as I'm sure he could help!
- RF
copyleft-next@lists.fedorahosted.org