A few comments on the experimental branch.[1]
1) Section 4, copyleft conditions, 3rd paragraph, says that you could distribute "a Modification under this License even if it incorporates third-party material governed by a license that is both OSI-Approved and FSF-Free". It seems to amount to distribution of code under two licenses, in the sense of juxtaposing code under different licenses in the same file, which sounds very confusing. I suppose this reading is incorrect, or there is some reason for this?
2) I'd think the licensing condition on a patch (section 6) should be licensing by default under the free and open license of the file as applicable, like the DCO language, or I'm not sure how it'd work otherwise...
3) Trivial stylistic comment The definition of Modified Code doesn't sound as nice as the previous definition of Derived Work :-) (sorry!) I wonder if it is necessary to entirely replace the use of the verbs (i.e. adapt, transform) with addition and deletion operations? I think to me, it'd seem natural if some of these verbs would be expressly applied to source code in files.
4) Copyleft conditions To summarize (please correct me if this is wrong), as long as a file has copyrightable code under copyleft-next, the file is licensed under copyleft-next. Neighboring code, code using the copyleft-next-ed code, is free and open source. (within some limits)
One reason why I support this experiment, is that to me, there isn't a clear difference between the neighboring code in copyleft-next-experimental and the code incorporated as open licensed in copyleft-next-master (under section 4). I mean this in the sense that code incorporated as open licensed (under section 4 master) can lead to neighboring code easily during development, without necessarily realizing it. But any recipient should be able to trust it has the open license under which it's distributed. Accepting neighboring code as open licensed in the license, makes that clear.
5) A remark MPL copyleft is IMHO the closest match for the 'strongest layer'. I mean I think it's a very understandable definition of the first layer for the copyleft-next scope. And I think the reason is indeed as noted by Fontana in another thread: because MPL boundary is the same with almost all other licenses (MIT, BSD) boundary: the copyrightable code, the source of licensing conditions on the code.
An open source developer will know when there's MIT code in a file to respect its attribution conditions accordingly; or BSD code, or AL2.0 code. The criteria for MPL are no different. The file headers reflect copyright and any license under which there is copyrightable code in this file. (AFAIK, it's much more common to write headers with copyright and license information in files; even if this information is of course also per package.) I'd say it's routine in an open source project, and I'd say it's simple.
I'll add here some thoughts I've been having, not in an organized manner, I will only note them down, for the list. Richard Fontana reminded in a previous email thread on this experiment, of GPLv2 section 2, the 2nd and 3rd paragraphs. I remember reading these paragraphs years ago, and finding the concept *fair*.
I'm not sure GPL really does that, though. Or the way it does it, through relicensing every open license, or reject combination with it if it can't (calling it incompatible), is arguably not ideal. (which is not necessarily to say there is another objectively better way, but other ways with different trade-offs.)
When there's no copyrightable code in a file, it's work written entirely by someone else. Taken in itself. It applies to a package, a library, an application. It doesn't matter if individual developers may happen to be the same, because the *license* matters more in many ways. And the license on that file can be BSD. Or MIT, AL2.0, or MPL. It might be more obvious for web applications in some interpreted languages, with open repositories. (or for permissive projects). OTOH, when there's no copyrightable code in a file/package, the code _written entirely by someone else_ might interact with copylefted code, add behavior or change behavior, such that the result of their combination will be a work of authorship standing on its own too. Or, it might not; it can be very loosely related, a package with an implementation which has nothing to do with another, except there's a call to tie the two. (such as 'import' and use some method, as it's been noted lately on this list)
In copyleft-next-experimental, as long as work "written by you" is combined with "my" code to form a new work, then I will ask you explicitly only to offer users the same freedoms as any open licensed software does: your code can be BSD, MIT, MPL licensed. Only that it will be as software should be: free and open software. Not copyleft-next. Experimental branch copyleft-next-ed code accepts around it any free and open license as it is. It doesn't (re)license neighboring code to copyleft-next, and it doesn't disallow code/data sharing if they're not relicensable to it.
If I include a BSD file, in a copyleft-next-experimental project, it's unambiguously BSD. Whether it uses the copyleft-next code or not. If I take away a BSD file, from the copyleft-next-experimental project, it's BSD. It can be licensed proprietary separately (*its* downstream). But *not* as long as it's part of a work that incorporates the copyleft-next-ed code: the copyleft-next license guarantees that.
Copyleft-next-ed code is incompatible with *proprietary* licensed code. Not as much open licensed. It can't be incorporated in proprietary software.[2] This is an essential goal of strong copyleft, and it never changed. Its intention is to be incorporated in open source software.
The concept is "weaker" than practically relicensing any part of the derivative/collective work. It doesn't do that. But, its scope extends beyond "weak" copyleft. It enables an ecosystem of free and open source software around it.
To me, this license and its *clarity* would be very valuable, if it's possible. I should say I am biased, though, and I surely can miss otherwise very obvious issues. I think perhaps copyleft doesn't have to be a "license of all licenses, which converts everything to it, or rejects sharing". Copyleft is the guarantee of freedom. A guarantee to downstream users, in a way that enables free and open software to build upon it.
I wonder if the concept is contradictory in some way I don't entirely see? Or unenforceable. It unambiguously allows every open license to set its own conditions only, when the software, source or binary, is distributed *separately*. (as Fontana mentioned in the idea thread).
What would the worse scenario?
[1] https://gitorious.org/copyleft-next/copyleft-next/blobs/experimental/Drafts/... [2] cf GPLv2 and v3 last paragraph.
On Tue, Jul 09, 2013 at 02:14:47PM +0300, Engel Nyst wrote:
A few comments on the experimental branch.[1]
- Section 4, copyleft conditions, 3rd paragraph, says that you could
distribute "a Modification under this License even if it incorporates third-party material governed by a license that is both OSI-Approved and FSF-Free". It seems to amount to distribution of code under two licenses, in the sense of juxtaposing code under different licenses in the same file, which sounds very confusing. I suppose this reading is incorrect, or there is some reason for this?
This is meant to be comparable to the case of a source file licensed under the GPL but incorporating GPL-compatible elements. It's basically just taking one common license compatibility scenario and relaxing orthodox criteria for GPL compatibility.
Cf. http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html
- I'd think the licensing condition on a patch (section 6) should be
licensing by default under the free and open license of the file as applicable, like the DCO language, or I'm not sure how it'd work otherwise...
Ah, that's a good point.
- Trivial stylistic comment
The definition of Modified Code doesn't sound as nice as the previous definition of Derived Work :-) (sorry!)
Hmm, I don't know if that's a trivial comment, since I consider making the text sound nice an important substantive goal. :)
I wonder if it is necessary to entirely replace the use of the verbs (i.e. adapt, transform) with addition and deletion operations?
Oh, the use of 'addition' and 'deletion' is a nod to the MPL/EPL licenses. I'm not entirely satisfied with this. The language here is specifically influenced by MPL 2.0 as I recall.
The problem with 'adapt' and 'transform' is that those are different ways of saying 'derivative work' (essentially) and I'm trying to see if I can avoid reference to such legally charged language as much as possible. What I now like about the MPL family (though I was in denial about this for a long time, as I may have said) is that it starts out with a correct understanding of what FLOSS code is and how it gets changed (files of [usually] text (copyleft-next experimental is trying to express the additional observation that these files bear certain interfunctional relationships
What I like about the MPL family -- I don't know if I've already mentioned this -- is something I was in denial about for a long time. It starts out, implicitly, with a correct social observation about what FLOSS code is and how it is developed. It's a set of files that normally get modified through textual editing.
(I realize that going down such a path implies a rejection of copyleft-next as being strongly suitable (than other widely-used FLOSS licenses) for non-software works.)
I think to me, it'd seem natural if some of these verbs would be expressly applied to source code in files.
Maybe in a file-specific context they would be useful. I'll think about that.
- Copyleft conditions
To summarize (please correct me if this is wrong), as long as a file has copyrightable code under copyleft-next, the file is licensed under copyleft-next.
Yes, or 'the GPL'.
Neighboring code, code using the copyleft-next-ed code, is free and open source. (within some limits)
That's the rough idea.
One reason why I support this experiment, is that to me, there isn't a clear difference between the neighboring code in copyleft-next-experimental and the code incorporated as open licensed in copyleft-next-master (under section 4). I mean this in the sense that code incorporated as open licensed (under section 4 master) can lead to neighboring code easily during development, without necessarily realizing it.
Right, there isn't a clear difference.
- RF
On 07/09/2013 04:36 PM, Richard Fontana wrote:
On Tue, Jul 09, 2013 at 02:14:47PM +0300, Engel Nyst wrote:
A few comments on the experimental branch.[1]
- Section 4, copyleft conditions, 3rd paragraph, says that you could
distribute "a Modification under this License even if it incorporates third-party material governed by a license that is both OSI-Approved and FSF-Free". It seems to amount to distribution of code under two licenses, in the sense of juxtaposing code under different licenses in the same file, which sounds very confusing. I suppose this reading is incorrect, or there is some reason for this?
This is meant to be comparable to the case of a source file licensed under the GPL but incorporating GPL-compatible elements. It's basically just taking one common license compatibility scenario and relaxing orthodox criteria for GPL compatibility.
Cf. http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html
I don't see how it is directly applicable this way, unless I'm missing something. GPL (and MPL, and other licenses) can incorporate in files too, code distributed under licenses which have practically a perfect subset of conditions (of GPL, or of MPL). So it can do that. But in copyleft-next context, a file under MPL (a license that is both OSI-Approved and FSF-Free), cannot have a top license text added saying that it's copyleft-next. MPL doesn't allow that. Please correct me if this is wrong.
Code under MPL can interact with any code, and code under copyleft-next can interact with any open licensed code in a larger work with both; without licensing issues or uncertainties. But that doesn't allow me to break MPL requirements: copyrightable code under MPL needs to be in files distributed as MPL. Do I badly misunderstand something?
copyleft-next@lists.fedorahosted.org
-
Engel Nyst -
Richard Fontana