Good news, everyone! copyleft-next 0.3.0 has been released! https://gitorious.org/copyleft-next/copyleft-next/blobs/raw/master/Releases/...
A summary of changes relative to the previous released verson shall be provided in due course.
- RF
On 05/16/2013 08:18 PM, Richard Fontana wrote:
A summary of changes relative to the previous released verson shall be provided in due course.
FLOSS best practices generally suggest updating the CHANGELOG as you go -or- collecting highlights from commits since the last release in the CHANGELOG [0]. In this way such a release announcement comes with the answer to the question: "What changed in this release?"
Respectfully,
--Tom
[0] http://producingoss.com/en/testing-and-releasing.html#release-announcement
On Fri, May 17, 2013 at 07:35:33AM -0500, Tom Marble wrote:
On 05/16/2013 08:18 PM, Richard Fontana wrote:
A summary of changes relative to the previous released verson shall be provided in due course.
FLOSS best practices generally suggest updating the CHANGELOG as you go -or- collecting highlights from commits since the last release in the CHANGELOG [0]. In this way such a release announcement comes with the answer to the question: "What changed in this release?"
I believe I started out with, or at least intending to maintain, a CHANGELOG, and I have the vaguest memory of someone (Dave Neary?) suggesting I use one. But I have been under the impression that CHANGELOGs are rarely used by non-antediluvian FLOSS projects.
- RF
On Fri, May 17, 2013 at 07:35:33AM -0500, Tom Marble wrote:
On 05/16/2013 08:18 PM, Richard Fontana wrote:
A summary of changes relative to the previous released verson shall be provided in due course.
FLOSS best practices generally suggest updating the CHANGELOG as you go -or- collecting highlights from commits since the last release in the CHANGELOG [0]. In this way such a release announcement comes with the answer to the question: "What changed in this release?"
I believe I started out with, or at least intending to maintain, a CHANGELOG, and I have the vaguest memory of someone (Dave Neary?) suggesting I use one. But I have been under the impression that CHANGELOGs are rarely used by non-antediluvian FLOSS projects.
Depends if you have a strict definition of "CHANGELOG". Most popular projects actually publish a list of changes on release so that users know what to expect. Whether it's in the traditional form of a CHANGELOG, or something fancier and/or more readable, doesn't really matter.
Regards
Antoine.
On Fri, May 17, 2013 at 6:27 AM, Richard Fontana fontana@sharpeleven.org wrote:
On Fri, May 17, 2013 at 07:35:33AM -0500, Tom Marble wrote:
On 05/16/2013 08:18 PM, Richard Fontana wrote:
A summary of changes relative to the previous released verson shall be provided in due course.
FLOSS best practices generally suggest updating the CHANGELOG as you go -or- collecting highlights from commits since the last release in the CHANGELOG [0]. In this way such a release announcement comes with the answer to the question: "What changed in this release?"
I believe I started out with, or at least intending to maintain, a CHANGELOG, and I have the vaguest memory of someone (Dave Neary?) suggesting I use one. But I have been under the impression that CHANGELOGs are rarely used by non-antediluvian FLOSS projects.
ChangeLogs are for old foggies. Its year 2013, git is being used and you should be able to git log v0.2.1..v0.3.0.
Luis
On Fri, May 17, 2013 at 9:42 AM, Luis R. Rodriguez mcgrof@frijolero.org wrote:
ChangeLogs are for old foggies. Its year 2013, git is being used and you should be able to git log v0.2.1..v0.3.0.
Changelogs/release notes/whatever are for the public. The git log is 188 lines. A good changelog should be substantially shorter than that.
-- Ben Cotton
On Fri, May 17, 2013 at 06:42:28AM -0700, Luis R. Rodriguez wrote:
ChangeLogs are for old foggies. Its year 2013, git is being used and you should be able to git log v0.2.1..v0.3.0.
I think the idea is to give users a quick overview of the high-level changes (the stuff that users are likely to care about, filtering out the stuff that only developers are likely to care about). For example, I wouldn't put 840419b (Fix line lengths, 2013-05-16) in my changelog ;).
Git does this sort of thing with release notes [1], but for some projects I just summarize changes in the commit message [2]. Some sort of summary is useful, if only because posting it to the mailing list helps keep people interested ;).
Cheers, Trevor
[1]: http://git.kernel.org/cgit/git/git.git/tree/Documentation/RelNotes [2]: https://github.com/wking/quizzer/commit/63706636f951ae27d1e431cc7e90833c02b7...
On Fri, May 17, 2013 at 6:50 AM, W. Trevor King wking@tremily.us wrote:
On Fri, May 17, 2013 at 06:42:28AM -0700, Luis R. Rodriguez wrote:
ChangeLogs are for old foggies. Its year 2013, git is being used and you should be able to git log v0.2.1..v0.3.0.
I think the idea is to give users a quick overview of the high-level changes (the stuff that users are likely to care about, filtering out the stuff that only developers are likely to care about). For example, I wouldn't put 840419b (Fix line lengths, 2013-05-16) in my changelog ;).
Git does this sort of thing with release notes [1], but for some projects I just summarize changes in the commit message [2]. Some sort of summary is useful, if only because posting it to the mailing list helps keep people interested ;).
Agreed on summary, but that != ChangeLog.
Luis
On Fri, May 17, 2013 at 06:52:32AM -0700, Luis R. Rodriguez wrote:
Agreed on summary, but that != ChangeLog.
Agreed. I think Ben, Julien, and I were thrown off by the occurrence of “highlights” in:
On Fri, May 17, 2013 at 07:35:33AM -0500, Tom Marble wrote:
FLOSS best practices generally suggest updating the CHANGELOG as you go -or- collecting highlights from commits since the last release in the CHANGELOG [0]. In this way such a release announcement comes with the answer to the question: "What changed in this release?"
;) Trevor
Le 17 mai - 06:42, Luis R. Rodriguez a écrit :
I believe I started out with, or at least intending to maintain, a CHANGELOG, and I have the vaguest memory of someone (Dave Neary?) suggesting I use one. But I have been under the impression that CHANGELOGs are rarely used by non-antediluvian FLOSS projects.
ChangeLogs are for old foggies. Its year 2013, git is being used and you should be able to git log v0.2.1..v0.3.0.
Luis
I disagree, Changelogs are quite useful to highlight important changes, way better than having to read all commits.
julien
PS : and i'm not an old foggy :)
On 17-05-13 08:27, Richard Fontana wrote:
On Fri, May 17, 2013 at 07:35:33AM -0500, Tom Marble wrote:
On 05/16/2013 08:18 PM, Richard Fontana wrote:
A summary of changes relative to the previous released verson shall be provided in due course.
FLOSS best practices generally suggest updating the CHANGELOG as you go -or- collecting highlights from commits since the last release in the CHANGELOG [0]. In this way such a release announcement comes with the answer to the question: "What changed in this release?"
I believe I started out with, or at least intending to maintain, a CHANGELOG, and I have the vaguest memory of someone (Dave Neary?) suggesting I use one. But I have been under the impression that CHANGELOGs are rarely used by non-antediluvian FLOSS projects.
I agree an actual ChangeLog file seems archaic. But it does seem useful to have release notes ready at the moment of release.
For us (musicbrainz) we do a blog post on for each release (typically once every two weeks) which lists the user-facing changes and their associated issue numbers [1]. Rarely anything gets changed without an issue in the issue tracker, so release notes can semi-automatically be generated from which issues were associated with the release and have been closed (as fixed).
Obviously if you would want to do that for copyleft-next you'd first need an issue tracker ;)
-- warp / kuno.
Hello,
Good news, everyone! copyleft-next 0.3.0 has been released! https://gitorious.org/copyleft-next/copyleft-next/blobs/raw/master/Releases/...
I have a couple of questions about it:
If I offer to license, for a fee, a Covered Work under terms other than a license that is OSI-Approved or FSF-Free as of the release date of this License or a numbered version of copyleft-next released by the Copyleft-Next Project, then the license I grant You under section 1 is no longer subject to the conditions in sections 2 through 5.
Is it desirable? What if, in a collectively owned FLOSS project, a single contributor decides to re-use one of their contributions for a closed source project? Does it impact the collectively owned FLOSS project as a whole?
The following are not Derived Works: (i) Mere Aggregation; (ii) a mere reproduction of My Work; and (iii) if My Work fails to explicitly state an expectation otherwise, a work that merely makes reference to My Work.
Why the conditional in (iii)? Do we want to allow the licensor to say "works mentioning this Covered Work are considered Derived Works"? Is there an use case I'm missing?
Regards
Antoine.
On Fri, May 17, 2013 at 03:31:24PM +0200, Antoine Pitrou wrote:
I have a couple of questions about it:
If I offer to license, for a fee, a Covered Work under terms other than a license that is OSI-Approved or FSF-Free as of the release date of this License or a numbered version of copyleft-next released by the Copyleft-Next Project, then the license I grant You under section 1 is no longer subject to the conditions in sections 2 through 5.
Is it desirable?
I have assumed so. There is a good argument that (at this advanced stage of FLOSS history) it merely serves to make a symbolic or political statement and as such is just taking up space, but I don't fully agree with that argument.
What if, in a collectively owned FLOSS project, a single contributor decides to re-use one of their contributions for a closed source project? Does it impact the collectively owned FLOSS project as a whole?
That's an interesting question. I believe I initially misunderstood it. I currently believe when you say 'collectively owned' you do not mean something like the US copyright law concept of joint ownership but rather 'typical FLOSS project with diversity of copyright ownership and absence of copyright ownership or outbound licensing power aggregation'.
So I think what you are asking about is the case where you have a normal FLOSS project, with diversity of copyright ownership, and a contributor contributes a patch, say, and the patch has to be licensed under copyleft-next (this may be so by operation of section 6, the 'symmetrical licensing' provision). So then the contributor separately uses the same copyrightable patch in some closed source project.
Let me first note that the provision in question is obviously directed at a more narrow sort of conduct than the language suggests; it is meant to discourage copyright-aggregating licensors from using copyleft-next as the FLOSS licensing instrument in a revenue-generating dual-licensing or open core scheme. The reason the language is broader is that to narrow it would (I think) make the provision lengthier and more inelegant.
I believe you have discovered what I think is at most a harmless problem that results from that generality of language. The worst that can happen in your hypothetical is that the project the contributor contributed to gets to use the patch under permissive-next, so to speak, instead of copyleft-next. This makes section 6 superfluous in that case. But it doesn't somehow cause an entire version of the work released by the project and incorporating the contributor's patch to be under permissive-next. Moreover, I believe that the bigger the contribution, the more just it would be for this 'error' to occur, so in other words the error remains harmless as the contribution gets more significant. Though maybe I'm wrong about that.
Let us suppose that this version reflects 100 contributions from 100 copyright holders, one of which is this person's patch. Then the recipient of this version is getting 99 copyleft-next licenses, each of which applies only to such contributor's copyright interest, and one permissive-next license covering this person's patch.
But if I have misunderstood the issue, or have correctly understood it but am overlooking something important, please let me know.
Thanks, - RF
On Fri, May 17, 2013 at 03:31:24PM +0200, Antoine Pitrou wrote:
The following are not Derived Works: (i) Mere Aggregation; (ii) a mere reproduction of My Work; and (iii) if My Work fails to explicitly state an expectation otherwise, a work that merely makes reference to My Work.
Why the conditional in (iii)? Do we want to allow the licensor to say "works mentioning this Covered Work are considered Derived Works"? Is there an use case I'm missing?
This is a significant and suboptimally drafted change. Ideas for how to draft it better (without massively increasing the size of the text) are welcome.
A number of considerations motivated this change, but an illustrative one arose out of something I dealt with recently in $DAYJOB, an upstream OpenStack issue noted here: https://bugs.launchpad.net/cinder/+bug/1157091
Note in particular the statement "it's a bit odd to have an AGPL dependency that really means cinder-rtstool is AGPL (even though it says Apache2 in the header)". While this was one of those bad facts/bad law situations, I was personally struck by how *wrong* this conclusion felt to me (without regard to whether it was legally correct [though I do not think it was] or not). And note the cosmetic resolution of the bug.
The point of this change in copyleft-next is that, if, say, rtslib had been under copyleft-next (and had escaped the nullification of proprietary/copyleft dual licensing provision somehow [1]), then some downstream noncopyleft (or proprietary) endeavor should not need to worry about the mere use of an external library as in itself having a copyleft effect on the immediate work in question -- unless the licensor of the copyleft-next library says something explicit to make clear that this is intended (in which case it still is not a foregone conclusion that the dependency relationship gives rise to some copyleft effect).
- RF
[1] To be more precise: The rtslib referred to here is actually rtslib-fb, which is Andy Grover's fork of Rising Tide Systems' rtslib. In a universe where RTS had used copyleft-next for rtslib, rtslib-fb wouldn't have triggered the nullification provision, but presumably rtslib proper would have.
On 05/17/2013 09:24 PM, Richard Fontana wrote:
On Fri, May 17, 2013 at 03:31:24PM +0200, Antoine Pitrou wrote:
The following are not Derived Works: (i) Mere Aggregation; (ii) a mere reproduction of My Work; and (iii) if My Work fails to explicitly state an expectation otherwise, a work that merely makes reference to My Work.
Why the conditional in (iii)? Do we want to allow the licensor to say "works mentioning this Covered Work are considered Derived Works"? Is there an use case I'm missing?
This is a significant and suboptimally drafted change. Ideas for how to draft it better (without massively increasing the size of the text) are welcome.
"merely makes reference to" strikes me as pretty vague, but of course there may be a obviously precise meaning that I'm oblivious to.
But is it not disturbing that a significant and suboptimally drafted change is in a copyleft-next released version, as opposed to first being discussed publicly?
Mike
On Fri, May 17, 2013 at 09:36:43PM -0700, Mike Linksvayer wrote:
On 05/17/2013 09:24 PM, Richard Fontana wrote:
This is a significant and suboptimally drafted change. Ideas for how to draft it better (without massively increasing the size of the text) are welcome.
"merely makes reference to" strikes me as pretty vague, but of course there may be a obviously precise meaning that I'm oblivious to.
But is it not disturbing that a significant and suboptimally drafted change is in a copyleft-next released version, as opposed to first being discussed publicly?
It's a fair cop, guv. It does relate to the more abstract things I was saying in some threads from last month.
I hope the issue I am trying to address is now clear from the referenced cinder-rtstool example, which as noted had quite an effect on me.
What we have, in a Python context, is a file, with an Apache License 2.0 notice, that says 'import rtslib', and the file uses functions from rtslib (AGPLv3-licensed). The project that was distributing cinder-rtstool was not also distributing rtslib. I express no view (here) on the (A)GPL analysis of this situation, copyleft-next being a different license. I think it is interesting, however, that some believed that it was a foregone conclusion that cinder-rtstool was "really AGPL", in a context where this was understood to be perceived as a *bad* thing. The effect is the continued, yet inconsistent, marginalization of strong-copyleft-licensed code. That marginalization, and some of its roots, are motivations for the copyleft-next project itself.
While I did not say this even as recently as FOSDEM 2013, because it wasn't really clear to me then, I think that strong copyleft as a legal theory needs to be weakened in order to escape this threat of marginalization.
I have come up with one approach. If you are writing a Python library foo and you put it under copyleft-next, and you want me to use your library, you ought to have the burden of making clear that the moment I merely distribute a file that says 'import foo' my file is ipso facto "really copyleft-next". If you did not bother to do this, I ought to be free to rely on an assumption you intended something 'weaker'. I believe that approximates the real rule that the various Linux distros are operating under.(I did not respond to warp's comment about Debian in an earlier thread. I will just say that I believe careful analysis of what Debian does will not reveal consistency.)
- RF
Hello,
Le samedi 18 mai 2013 à 23:21 -0400, Richard Fontana a écrit :
I hope the issue I am trying to address is now clear from the referenced cinder-rtstool example, which as noted had quite an effect on me.
What we have, in a Python context, is a file, with an Apache License 2.0 notice, that says 'import rtslib', and the file uses functions from rtslib (AGPLv3-licensed). The project that was distributing cinder-rtstool was not also distributing rtslib. I express no view (here) on the (A)GPL analysis of this situation, copyleft-next being a different license. I think it is interesting, however, that some believed that it was a foregone conclusion that cinder-rtstool was "really AGPL", in a context where this was understood to be perceived as a *bad* thing. The effect is the continued, yet inconsistent, marginalization of strong-copyleft-licensed code. That marginalization, and some of its roots, are motivations for the copyleft-next project itself.
As a data point, I'd like to mention that copyleft licenses are really unpopular in the Python world. As a Python developer myself, if I want a library of mine to get some use, I will choose a MIT-like license. (*)
I'm not sure exactly which triggered such unpopularity but there are certainly several reasons. One reason, slightly silly but which I think is quite widespread these days, is that being liberal is "cool" (I think you could call it the Github mindset).
But another reason is that there doesn't seem to be an appropriate copyleft license for Python libraries. This is exemplified in the following discussion where Twisted, a popular library, decided (long ago) that they would switch from LGPL to MIT-like: http://twistedmatrix.com/pipermail/twisted-python/2004-May/007944.html
(*) for an application of course I would use the GPL; but interestingly the Python ecosystem is composed of libraries much more than applications
While I did not say this even as recently as FOSDEM 2013, because it wasn't really clear to me then, I think that strong copyleft as a legal theory needs to be weakened in order to escape this threat of marginalization.
Definitely agreed. It doesn't help that the FSF chose to marginalize the LGPL.
I have come up with one approach. If you are writing a Python library foo and you put it under copyleft-next, and you want me to use your library, you ought to have the burden of making clear that the moment I merely distribute a file that says 'import foo' my file is ipso facto "really copyleft-next". If you did not bother to do this, I ought to be free to rely on an assumption you intended something 'weaker'.
Do note that "using a library" in the Python world can go very far, perhaps as far as monkeypatching the library in order to fix some undesired behaviour. The license (or its attached FAQ) has to be clear that such uses don't entail propagation of copyleft to the application as a whole.
Regards
Antoine.
On Sun, May 19, 2013 at 02:07:11PM +0200, Antoine Pitrou wrote:
But another reason is that there doesn't seem to be an appropriate copyleft license for Python libraries.
[...]
(*) for an application of course I would use the GPL; but interestingly the Python ecosystem is composed of libraries much more than applications
That occurs to me too.
Do note that "using a library" in the Python world can go very far, perhaps as far as monkeypatching the library in order to fix some undesired behaviour. The license (or its attached FAQ) has to be clear that such uses don't entail propagation of copyleft to the application as a whole.
That's useful to know.
thanks,
RF
Hello,
On 17-05-13 23:24, Richard Fontana wrote:
On Fri, May 17, 2013 at 03:31:24PM +0200, Antoine Pitrou wrote:
The following are not Derived Works: (i) Mere Aggregation; (ii) a mere reproduction of My Work; and (iii) if My Work fails to explicitly state an expectation otherwise, a work that merely makes reference to My Work.
Why the conditional in (iii)? Do we want to allow the licensor to say "works mentioning this Covered Work are considered Derived Works"? Is there an use case I'm missing?
This is a significant and suboptimally drafted change. Ideas for how to draft it better (without massively increasing the size of the text) are welcome.
A number of considerations motivated this change, but an illustrative one arose out of something I dealt with recently in $DAYJOB, an upstream OpenStack issue noted here: https://bugs.launchpad.net/cinder/+bug/1157091
Note in particular the statement "it's a bit odd to have an AGPL dependency that really means cinder-rtstool is AGPL (even though it says Apache2 in the header)". While this was one of those bad facts/bad law situations, I was personally struck by how *wrong* this conclusion felt to me (without regard to whether it was legally correct [though I do not think it was] or not). And note the cosmetic resolution of the bug.
The point of this change in copyleft-next is that, if, say, rtslib had been under copyleft-next (and had escaped the nullification of proprietary/copyleft dual licensing provision somehow [1]), then some downstream noncopyleft (or proprietary) endeavor should not need to worry about the mere use of an external library as in itself having a copyleft effect on the immediate work in question -- unless the licensor of the copyleft-next library says something explicit to make clear that this is intended (in which case it still is not a foregone conclusion that the dependency relationship gives rise to some copyleft effect).
Oh, this is an exciting change. Which seemingly makes the license very suitable for things written in python/perl/ruby/javascript/haskell/etc... and distributed as source code + machine readable dependency file.
Though I think that "a work that merely makes reference to My Work." should never be a derivative and the option to "explicitly state an expectation otherwise" can be removed from the license. But perhaps there are use-cases I am not aware of where such a statement would be desirable.
In a way the choice being made by the licensor is between strong copyleft (GPL-like) and weaker copyleft (almost LGPL-like), with the default being this modern implementation of the LGPL.
Still, even in it's current form it seems like a very interesting change. Now we just need an affero variant and the license will be perfect for web applications :)
-- kuno / warp.
On Mon, May 20, 2013 at 08:55:29PM -0500, Kuno Woudt wrote:
Though I think that "a work that merely makes reference to My Work." should never be a derivative and the option to "explicitly state an expectation otherwise" can be removed from the license. But perhaps there are use-cases I am not aware of where such a statement would be desirable.
It's possible that this could adequately be addressed in a FAQ.
- RF
On 05/18/2013 07:24 AM, Richard Fontana wrote:
The point of this change in copyleft-next is that, if, say, rtslib had been under copyleft-next (and had escaped the nullification of proprietary/copyleft dual licensing provision somehow [1]), then some downstream noncopyleft (or proprietary) endeavor should not need to worry about the mere use of an external library as in itself having a copyleft effect on the immediate work in question -- unless the licensor of the copyleft-next library says something explicit to make clear that this is intended (in which case it still is not a foregone conclusion that the dependency relationship gives rise to some copyleft effect).
Isn't it contradictory with section 3, first paragraph?
This condition may not be avoided through such means as separate Distribution of portions of the Derived Work.
For reference, the comment to this commit[1] is saying that the licensor should include a statement like "Any code that imports bar, and which otherwise meets the definition of 'Derived Work' of bar in copyleft-next, shall be considered a Derived Work of bar even if such code is not distributed with bar." It seems to me that the above phrase of section 3 is no longer making any effect, or perhaps it had a different intention than to avoid (ab)using separate packaging to bypass the license.
I understand that it's work in progress, just to note that it seems inconsistent at the moment, unless I'm misunderstanding it.
[1] https://gitorious.org/copyleft-next/copyleft-next/commit/c21519e0d71d3429e40...
On Thu, Jul 04, 2013 at 11:43:27PM +0300, Engel Nyst wrote:
On 05/18/2013 07:24 AM, Richard Fontana wrote:
The point of this change in copyleft-next is that, if, say, rtslib had been under copyleft-next (and had escaped the nullification of proprietary/copyleft dual licensing provision somehow [1]), then some downstream noncopyleft (or proprietary) endeavor should not need to worry about the mere use of an external library as in itself having a copyleft effect on the immediate work in question -- unless the licensor of the copyleft-next library says something explicit to make clear that this is intended (in which case it still is not a foregone conclusion that the dependency relationship gives rise to some copyleft effect).
Isn't it contradictory with section 3, first paragraph?
This condition may not be avoided through such means as separate Distribution of portions of the Derived Work.
I suppose it clarifies the meaning of that sentence in section 3. Merely distributing some Apache License 2.0 Python program that happens to say "import <name of copyleft-next-licensed library>" is not in itself "separate Distribution of portions of the Derived Work".
The section 3 language is adapted from similar language in GPLv3 section 5, which as I recall was tied up with the deletion of the language from GPLv2 section 2 antepenultimate paragraph.
For reference, the comment to this commit[1] is saying that the licensor should include a statement like "Any code that imports bar, and which otherwise meets the definition of 'Derived Work' of bar in copyleft-next, shall be considered a Derived Work of bar even if such code is not distributed with bar."
Yes, but this is intended to hint at the view that such code *by itself* would not, or should not, meet the definition of 'Derived Work'.
- RF
On Thu, May 16, 2013 at 09:18:50PM -0400, Richard Fontana wrote:
Good news, everyone! copyleft-next 0.3.0 has been released! https://gitorious.org/copyleft-next/copyleft-next/blobs/raw/master/Releases/...
A summary of changes relative to the previous released verson shall be provided in due course.
Principal changes from 0.2.1 to 0.3.0:
* Adopting a suggestion from Luis Villa, the consequence of the nullification provision being triggered is clarified to indicate that it's the conditions of the indicated sections that My Work is no longer subject to.
* The MPL 2.0-influenced GPL compatibility approach is extended to AGPLv3+ (through a redefinition of 'GPL').
* In an important change, all licenses that are both OSI-approved and classified by the FSF as 'free' (as of the release date) are deemed inbound-compatible with copyleft-next, provided that distribution of a Covered Work incorporating code from the non-copyleft-next license does not violate the latter license. I wonder whether this should go even further, but this certainly expands the set of licenses that are copyleft-next-compatible beyond those that are GPL-compatible. For example, and connecting this to a thread from several months ago, I would now assume that EPL code is copyleft-next-compatible, whereas EPL remains GPL-incompatible under orthodox doctrine.
* The section on distributing object code is made clearer in certain respects, though no substantive change is made.
* The wording of the 'copyleft sunset' provision is made clearer in certain respects, though no substantive change is made.
* The part of the termination provision that is intended to make clear that you can't avoid the effect of termination merely by getting a new licensed copy is made clearer in certain respects, though no substantive change is made.
* As discussed elsewhere in this thread, the definition of "Derived Work" now carves out "a work that merely makes reference to My Work" "if My Work fails to explicitly state an expectation otherwise".
- RF
On 19/05/13 05:02, Richard Fontana wrote:
- In an important change, all licenses that are both OSI-approved and classified by the FSF as 'free' (as of the release date) are deemed inbound-compatible with copyleft-next,
The FSF license list http://www.gnu.org/licenses/license-list.html does not guarantee completeness:
"We try to list the most commonly encountered free software license on this page, but cannot list them all"
The OSI list, on the other hand, is complete in the sense that it's a list of all the licenses which have successfully completed the OSI process.
Is that a problem in practice?
provided that distribution of a Covered Work incorporating code from the non-copyleft-next license does not violate the latter license. I wonder whether this should go even further, but this certainly expands the set of licenses that are copyleft-next-compatible beyond those that are GPL-compatible. For example, and connecting this to a thread from several months ago, I would now assume that EPL code is copyleft-next-compatible, whereas EPL remains GPL-incompatible under orthodox doctrine.
If you have _outbound_ GPL compatibility, which you do, doesn't this raise a bit of a problem?
I take some code under the EPL and put it in a copyleft-next project. Someone else takes my project and "converts" to GPL. However, they can't do that because of the EPL code originally included. So they need to be warned that they can't do that, even though the license says they can.
Is this a problem? I think it is...
Gerv
On Mon, May 20, 2013 at 03:38:41PM +0100, Gervase Markham wrote:
I take some code under the EPL and put it in a copyleft-next project. Someone else takes my project and "converts" to GPL. However, they can't do that because of the EPL code originally included. So they need to be warned that they can't do that, even though the license says they can.
This sort of thing makes me want to ask for commit message tags like:
Signed-off-by: Random J Developer random@developer.example.org License: copyleft-next 0.3.0[, possible additional licenses] Syntax: signed-off-by x.y.z
Then you could safely cherry-pick commits with compatible licenses, without having to worry about the context in the project you're cherry-picking from. It would also make it easy to audit the project:
$ git log | grep '^License:' | sort | uniq
I can dream ;).
Cheers, Trevor
On Mon, May 20, 2013 at 10:57:44AM -0400, W. Trevor King wrote:
This sort of thing makes me want to ask for commit message tags like:
Signed-off-by: Random J Developer random@developer.example.org License: copyleft-next 0.3.0[, possible additional licenses] Syntax: signed-off-by x.y.z
Then you could safely cherry-pick commits with compatible licenses, without having to worry about the context in the project you're cherry-picking from. It would also make it easy to audit the project:
$ git log | grep '^License:' | sort | uniq
I can dream ;).
I think Bradley Kuhn (say, where is ...) once proposed something similar to this.
- RF
On Mon, May 20, 2013 at 8:31 PM, Richard Fontana fontana@sharpeleven.org wrote:
On Mon, May 20, 2013 at 10:57:44AM -0400, W. Trevor King wrote:
This sort of thing makes me want to ask for commit message tags like:
Signed-off-by: Random J Developer random@developer.example.org License: copyleft-next 0.3.0[, possible additional licenses] Syntax: signed-off-by x.y.z
Then you could safely cherry-pick commits with compatible licenses, without having to worry about the context in the project you're cherry-picking from. It would also make it easy to audit the project:
$ git log | grep '^License:' | sort | uniq
I can dream ;).
I think Bradley Kuhn (say, where is ...) once proposed something similar to this.
To be clear for historical record -- given a review by SFLC on our effort to help share code for ath5k with the OpenBSD community and a possible concern over people not knowing exactly what the Signed-off-by tag meant, defined under the Developer Certificate of Origin (DCO) in the Linux kernel, I countered with a suggestion to use the Change-licensed-under tag for permissive license content on the the Linux kernel [0]. If you git log the kernel you will find it. In practice it never caught on mainly because people using the Signed-off-by tag already knew that the DCO provided language that indicated the files you were making contributions to were being made under the file's existing license. In practice then the Changes-licensed-under tag never caught on and it proved to be more scalable to instead ensure every contributor knew WTF Signed-off-by tag meant. This proved to be fun: senior engineers sent us to hell, ensuring they knew WTF it meant. New developers knew what it meant too and frankly its at this point silly to fathom Kernel developers who don't know WTF it means.
Of course though as may be clear from other threads on copyleft-next the DCO is useful for other projects too and hence the effort to make it a standalone project and folding its language evolution through copyleft-next mailing list [1].
So if your project uses the DCO its implied your changes are respecting the original license. Having content in a file licensed under different licenses seems wicked complex and likely problematic.
[0] http://kerneltrap.org/Linux/Wireless_Project_Suggests_Changes-licensed-under... [1] https://lists.fedorahosted.org/pipermail/copyleft-next/2013-May/000666.html
Luis
On Mon, May 20, 2013 at 03:38:41PM +0100, Gervase Markham wrote:
On 19/05/13 05:02, Richard Fontana wrote:
- In an important change, all licenses that are both OSI-approved and classified by the FSF as 'free' (as of the release date) are deemed inbound-compatible with copyleft-next,
The FSF license list http://www.gnu.org/licenses/license-list.html does not guarantee completeness:
"We try to list the most commonly encountered free software license on this page, but cannot list them all"
Right.
The OSI list, on the other hand, is complete in the sense that it's a list of all the licenses which have successfully completed the OSI process.
Right, or apparently, anyway.
Is that a problem in practice?
Probably not *too* much of a problem, and I think a nice political solution. The inspiration here is the 'Rule of Two' that the Software Freedom Conservancy is said to use in judging the membership fitness for potential member projects.
The unevenness of the FSF list causes the intersection list to look strange, but I don't think that is likely to be a problem in practice. There's some imprecision (is the OSI MIT license the same as the FSF X11 or Expat license?) which is at least annoying, but then most people assume that the thing that most people call the MIT license today is an FSF-free license and an OSI-approved license. (MIT is a bad example because it ought to be compatible with copyleft-next *anyway*, although now I wonder if this change now unintentionally places that idea in doubt but for Rule-of-Two.)
The best alternative would be to have a small list of acceptable licenses, an expansion of the former approach taken with the Apache License 2.0. Given the tendency in modern code towards use of standard licenses this might be an okay approach (somewhat reminiscent of the MySQL "FLOSS license exception").
provided that distribution of a Covered Work incorporating code from the non-copyleft-next license does not violate the latter license. I wonder whether this should go even further, but this certainly expands the set of licenses that are copyleft-next-compatible beyond those that are GPL-compatible. For example, and connecting this to a thread from several months ago, I would now assume that EPL code is copyleft-next-compatible, whereas EPL remains GPL-incompatible under orthodox doctrine.
If you have _outbound_ GPL compatibility, which you do, doesn't this raise a bit of a problem?
I take some code under the EPL and put it in a copyleft-next project. Someone else takes my project and "converts" to GPL. However, they can't do that because of the EPL code originally included. So they need to be warned that they can't do that, even though the license says they can.
Is this a problem? I think it is...
Hmm, let's see...
Say you have a Derived Work D that includes code from My Work M and EPL-licensed work E. So, crudely, D = M + E.
Section 3 says that the entirety of D 'as a whole' must be licensed under copyleft-next.
Section 4 para. 2 (it occurs to me that 'Covered Work' in para. 2 should perhaps be 'Derived Work') is what said that I could 'Distribute' D = M + E without falling afoul of section 4 para 1, provided that this would be in compliance with, here, the EPL. Note I'm taking it as a given that D (partially copyleft-next and partially EPL) would be compliant with EPL.
I am permitted by copyleft-next to additionally license D (the entire D, as a whole) under the GPL.
Now -- leaving aside what that even means in this example, which is probably an important question -- if I additionally license D under the GPL, I believe the orthodox view would be that in some sense I am licensing E under GPL. However, I'm more precisely dual-licensing E under "copyleft-next or GPL". I can't do this because EPL doesn't allow it. So while I had permission to form D{copyleft-next, EPL} = M + E, I didn't have permission to form D{copyleft-next|GPL} = M + E.
So I think in this situation what we have is an ineffective attempt to use the outbound GPL licensing mechanism. There's still no problem, because the end result is that D is partially copyleft-next and partially EPL, no incompatibility (we assume on the EPL side as well as the copyleft-next side).
However, it shouldn't have taken this much text to explain why this is so. So maybe there's something that can be made clearer. I have a feeling that there's something in sections 3 and 4 that can be compressed into one section (much like the outbound GPL compatibility was formerly in a separate section). I don't think there's a fundamental problem, unless I am overlooking something important in your example. (Your example included an additional distribution step, but I wasn't sure if that was relevant.)
Can't something similar happen with MPL 2.0? Say I have a 'Larger Work' consisting of an MPL 2.0 part and an EPL part.
- RF
On Mon, May 20, 2013 at 8:27 PM, Richard Fontana fontana@sharpeleven.org wrote:
The best alternative would be to have a small list of acceptable licenses, an expansion of the former approach taken with the Apache License 2.0. Given the tendency in modern code towards use of standard licenses this might be an okay approach (somewhat reminiscent of the MySQL "FLOSS license exception").
This leaves you updating the license semi-regularly, unless you do "or later version" in that list as well. Not ideal.
Luis
On 21/05/13 04:27, Richard Fontana wrote:
Probably not *too* much of a problem, and I think a nice political solution. The inspiration here is the 'Rule of Two' that the Software Freedom Conservancy is said to use in judging the membership fitness for potential member projects.
This Rule of Two? http://starwars.wikia.com/wiki/Rule_of_Two
If not, which? :-)
The best alternative would be to have a small list of acceptable licenses, an expansion of the former approach taken with the Apache License 2.0. Given the tendency in modern code towards use of standard licenses this might be an okay approach (somewhat reminiscent of the MySQL "FLOSS license exception").
I am (cautiously, bearing in mind Luis' point) in favour of this, as a mechanism to promote best-practice modern licenses.
So I think in this situation what we have is an ineffective attempt to use the outbound GPL licensing mechanism. There's still no problem, because the end result is that D is partially copyleft-next and partially EPL, no incompatibility (we assume on the EPL side as well as the copyleft-next side).
However, it shouldn't have taken this much text to explain why this is so. So maybe there's something that can be made clearer. I have a feeling that there's something in sections 3 and 4 that can be compressed into one section (much like the outbound GPL compatibility was formerly in a separate section). I don't think there's a fundamental problem, unless I am overlooking something important in your example. (Your example included an additional distribution step, but I wasn't sure if that was relevant.)
Well, if I say to you "here's D (M + E) under GPL", I may be wrong about the applicable license, but I haven't necessarily violated the rights of the copyright holder of E, because there do exist legal ways for me to distribute M + E to you. However, if the only rights I've explicitly given you to M are GPL rights, and you further distribute D (M + E) to others, you can only do so under the GPL, and so you will be violating the license of E. And you probably won't know you've done it, either - you are just passing on what I gave you under the license I told you it was under!
Can't something similar happen with MPL 2.0? Say I have a 'Larger Work' consisting of an MPL 2.0 part and an EPL part.
Yes - the concrete example is that if you include Apache-licensed code into your MPL 2 work, you can't then incorporate the result into a GPL 2 larger work (if you follow the FSF line on Apache/GPL 2 incompatibility). This isn't ideal, but then nothing about that alleged incompatibility is :-|
Additional question: non-copyleft licenses don't require the provision of source. If I send you a distribution which is mostly copyleft-next but contains a BSDed library, and send you only the binaries of the BSDed part, and say "here's the binary; it's under the BSD licence", that would be "Distribut[ing] a Covered Work incorporating material governed by a license that is both OSI-Approved and FSF-Free as of the release date of this License, provided that Your Distribution complies with such other license", but you still wouldn't have the source...
Gerv
On Tue, May 21, 2013 at 10:43:27AM +0100, Gervase Markham wrote:
On 21/05/13 04:27, Richard Fontana wrote:
Probably not *too* much of a problem, and I think a nice political solution. The inspiration here is the 'Rule of Two' that the Software Freedom Conservancy is said to use in judging the membership fitness for potential member projects.
This Rule of Two? http://starwars.wikia.com/wiki/Rule_of_Two
Ah, I'm somewhat pleased to discover there's a Star Wars reference. I can't understand why Bradley and Karen didn't allude to it in the FaiF podcast that presented my LinuxCon NA 2012 talk (where I talked about the 'Rule of Three' and how it became the 'Rule of Two' -- I thought I was coining those phrases).
The best alternative would be to have a small list of acceptable licenses, an expansion of the former approach taken with the Apache License 2.0. Given the tendency in modern code towards use of standard licenses this might be an okay approach (somewhat reminiscent of the MySQL "FLOSS license exception").
I am (cautiously, bearing in mind Luis' point) in favour of this, as a mechanism to promote best-practice modern licenses.
I am not too concerned about Luis's point only because license upgrades seem to be so infrequent (something I've suggested may be a problem, but I don't think it is likely to change).
Additional question: non-copyleft licenses don't require the provision of source. If I send you a distribution which is mostly copyleft-next but contains a BSDed library, and send you only the binaries of the BSDed part, and say "here's the binary; it's under the BSD licence", that would be "Distribut[ing] a Covered Work incorporating material governed by a license that is both OSI-Approved and FSF-Free as of the release date of this License, provided that Your Distribution complies with such other license", but you still wouldn't have the source...
Oh, *that* (unlike your previous issue) was something I thought about.
At least the way I am currently looking at it: I have to provide the source for the BSD library, because I still have to satisfy the separate conditions for object code distribution, which apply to the Derived Work (which we're assuming somehow encompasses the BSD library). But I also wondered whether failing to make clear that this was so might be suboptimal, and that may indeed be so. (Possibly the solution I am thinking of for improving the issue previously raised, which is to move section 4 para. 2 into section 3, could also address this.)
- RF
On 05/22/2013 06:13 AM, Richard Fontana wrote:
On Tue, May 21, 2013 at 10:43:27AM +0100, Gervase Markham wrote:
Additional question: non-copyleft licenses don't require the provision of source. If I send you a distribution which is mostly copyleft-next but contains a BSDed library, and send you only the binaries of the BSDed part, and say "here's the binary; it's under the BSD licence", that would be "Distribut[ing] a Covered Work incorporating material governed by a license that is both OSI-Approved and FSF-Free as of the release date of this License, provided that Your Distribution complies with such other license", but you still wouldn't have the source...
Oh, *that* (unlike your previous issue) was something I thought about.
At least the way I am currently looking at it: I have to provide the source for the BSD library, because I still have to satisfy the separate conditions for object code distribution, which apply to the Derived Work (which we're assuming somehow encompasses the BSD library). But I also wondered whether failing to make clear that this was so might be suboptimal, and that may indeed be so.
Is this case any different than AL2.0? I think incorporating AL2.0 components was possible in copyleft-next from very early times, under this section. I wonder if there is a difference that I might miss.
On Sat, Jul 06, 2013 at 02:46:05AM +0300, Engel Nyst wrote:
On 05/22/2013 06:13 AM, Richard Fontana wrote:
On Tue, May 21, 2013 at 10:43:27AM +0100, Gervase Markham wrote:
Additional question: non-copyleft licenses don't require the provision of source. If I send you a distribution which is mostly copyleft-next but contains a BSDed library, and send you only the binaries of the BSDed part, and say "here's the binary; it's under the BSD licence", that would be "Distribut[ing] a Covered Work incorporating material governed by a license that is both OSI-Approved and FSF-Free as of the release date of this License, provided that Your Distribution complies with such other license", but you still wouldn't have the source...
Oh, *that* (unlike your previous issue) was something I thought about.
At least the way I am currently looking at it: I have to provide the source for the BSD library, because I still have to satisfy the separate conditions for object code distribution, which apply to the Derived Work (which we're assuming somehow encompasses the BSD library). But I also wondered whether failing to make clear that this was so might be suboptimal, and that may indeed be so.
Is this case any different than AL2.0?
No, the analysis is the same.
I think incorporating AL2.0 components was possible in copyleft-next from very early times, under this section.
Right. That clarification was only thought necessary because in the GPL universe there's at least one legitimate reason for thinking that the Apache License 2.0 is incompatible with GPLv2, and copyleft-next was thought to incorporate the doctrine of GPL incompatibility.
- RF
copyleft-next@lists.fedorahosted.org
-
Antoine Pitrou -
Ben Cotton -
Engel Nyst -
Gervase Markham -
Julien Rabier -
Kuno Woudt -
Luis R. Rodriguez -
Luis R. Rodriguez -
Luis Villa -
Mike Linksvayer -
Richard Fontana -
Tom Marble -
W. Trevor King