All:
As Richard brought to my attention on identi.ca [0] there appears to be interest in making CLN (copyleft.next) compatible with EPL [1].
This is certainly an interesting goal and I'm wondering how the to comply with EPL in a CLN combined work?
Historically this seems to have been "impossible" with GPL. AFAICT the incompatibility rises from the EPL choice of venue [2] which makes EPL not GPL compatible. Interestingly there seem to be claims that GPL is not EPL compatible [3][4][5] yet they all seem to hinge reflexively on the former case. Thus if EPL is CLN compatible then is there any stronger assertion we can make to assure that CLN is EPL compatible (specifically that a combined work under CLN is possible)?
If such a solution is found it would give CLN another powerful advantage (along with deflating Proprietary Relicensing [6]) to combat the EPL reflexive assertions and (optionally via ws-supp) go further by copylefting network services (so-called "Web Services").
This would seem to be significant as it is not clear a developer today could deploy an EPL work (e.g. Clojure) combined with copyleft network services (e.g. under AGPLv3+) while complying with both licenses.
At the risk of adding a second issue to this mail I am concerned that the "at no charge" qualification in ws-supp creates a loophole for additional albeit gratis conditions. Especially in the land of network services we are becoming increasingly aware of draconian and even abusive "Terms of Service" in exchange for gratis offerings. CLN seems to want to make conveying Software Freedom unconditional.
Respectfully,
--Tom
[0] https://identi.ca/notice/95887462 [1] https://gitorious.org/copyleft-next/copyleft-next/blobs/master/license-draft... [2] https://www.gnu.org/licenses/license-list.html#EPL [3] http://www.eclipse.org/legal/eplfaq.php#GPLCOMPATIBLE [4] https://mmilinkov.wordpress.com/2010/04/06/epl-gpl-commentary/ [5] https://en.wikipedia.org/wiki/Eclipse_Public_License#Compatibility [6] https://gitorious.org/copyleft-next/copyleft-next/blobs/master/license-draft...
On Mon, Aug 6, 2012 at 5:07 PM, Tom Marble tmarble@info9.net wrote:
AFAICT the incompatibility rises from the EPL choice of venue [2] which makes EPL not GPL compatible.
Hi, Tom- There is a deeper problem, inherent to the nature of copyleft. EPL states:
"When the Program is made available in source code form:
a) it must be made available under this Agreement;"
That's the essence of the copyleft, and says "once the source is under this license, it must stay under this license." Other copylefts have the same kind of language, leading to a conflict - both licenses say "the _entire copylefted work_ must be under this license," so as soon as there is overlap between the two copylefted works (say, because you place one EPL file in a GPL application, or vice-versa), you have a problem.
MPL 2, Sec. 3.3, or copyleft.next Sec. 11, get around this to some extent, but only one-way. Short of an EPL 2.0 that has a similar clause I don't think you can have the sort of compatibility you seem to envision.
Luis
On 08/07/2012 01:34 AM, Luis Villa wrote:
On Mon, Aug 6, 2012 at 5:07 PM, Tom Marble tmarble@info9.net wrote:
AFAICT the incompatibility rises from the EPL choice of venue [2] which makes EPL not GPL compatible.
Hi, Tom- There is a deeper problem, inherent to the nature of copyleft. EPL states:
"When the Program is made available in source code form:
a) it must be made available under this Agreement;"
That's the essence of the copyleft, and says "once the source is under this license, it must stay under this license." Other copylefts have the same kind of language, leading to a conflict - both licenses say "the _entire copylefted work_ must be under this license," so as soon as there is overlap between the two copylefted works (say, because you place one EPL file in a GPL application, or vice-versa), you have a problem.
MPL 2, Sec. 3.3, or copyleft.next Sec. 11, get around this to some extent, but only one-way. Short of an EPL 2.0 that has a similar clause I don't think you can have the sort of compatibility you seem to envision.
Luis, what's your take (if any) on MPL/EPL compatibility?
- Richard
On Tue, Aug 7, 2012 at 9:22 AM, Richard Fontana fontana@sharpeleven.org wrote:
On 08/07/2012 01:34 AM, Luis Villa wrote:
On Mon, Aug 6, 2012 at 5:07 PM, Tom Marble tmarble@info9.net wrote:
AFAICT the incompatibility rises from the EPL choice of venue [2] which makes EPL not GPL compatible.
Hi, Tom- There is a deeper problem, inherent to the nature of copyleft. EPL states:
"When the Program is made available in source code form:
a) it must be made available under this Agreement;"
That's the essence of the copyleft, and says "once the source is under this license, it must stay under this license." Other copylefts have the same kind of language, leading to a conflict - both licenses say "the _entire copylefted work_ must be under this license," so as soon as there is overlap between the two copylefted works (say, because you place one EPL file in a GPL application, or vice-versa), you have a problem.
MPL 2, Sec. 3.3, or copyleft.next Sec. 11, get around this to some extent, but only one-way. Short of an EPL 2.0 that has a similar clause I don't think you can have the sort of compatibility you seem to envision.
Luis, what's your take (if any) on MPL/EPL compatibility?
Same problem (inclusion of individual MPL file in an EPL work is problematic.)
We likely could have added EPL to the list of MPL-compatible licenses, but did not sense much demand for MPL -> EPL one way compatibility. That may have been simply because the Mozilla and Eclipse communities don't overlap much.
I'd add that this is less difficult for MPL 2 because: 1) It's a relatively weak copyleft; and 2) to the extent we're strong (e.g., the patent clause, which I still need to discuss on this list), the requirement that you be combining with another work under the alternative license mitigates the risk somewhat of someone saying "ah, I'm using under this weaker patent clause, so I can sue you with impunity."
Luis
On 08/07/2012 12:39 PM, Luis Villa wrote:
On Tue, Aug 7, 2012 at 9:22 AM, Richard Fontana fontana@sharpeleven.org wrote:
Luis, what's your take (if any) on MPL/EPL compatibility?
Same problem (inclusion of individual MPL file in an EPL work is problematic.)
To me this just re-states the problem. What is an "EPL work", and when could an individual MPL file be included in it? I can tell you how I'd approach that situation myself. I'd assume, based on cultural hints coming from the Eclipse Foundation (and other prominent users of the EPL) and a textual hint in the EPL itself (bearing in mind its history), that it is nonproblematic to include an individual MPL file in -- or perhaps I should say juxtaposed with -- a set of files that are all otherwise licensed under the EPL. If someone on the EPL side complained, I'd take another look, but I've never encountered such a complaint (I am not sure I have dealt with MPL/EPL juxtaposition -- as you say the communities don't overlap much -- but I have dealt with LGPL/EPL juxtaposition which you might suppose would raise even more of an issue).
I'd add that this is less difficult for MPL 2 because:
- It's a relatively weak copyleft; and
- to the extent we're strong (e.g., the patent clause, which I still
need to discuss on this list), the requirement that you be combining with another work under the alternative license mitigates the risk somewhat of someone saying "ah, I'm using under this weaker patent clause, so I can sue you with impunity."
I haven't pushed this to gitorioius yet, but I have a draft EPL compatibility provision that says:
You may Distribute a Derived Work that includes files licensed under the Eclipse Public License 1.0 ("EPL"), provided that such Distribution complies with the requirements of the EPL. The requirement stated in [Distribution: General](b) of This License shall be narrowed in scope solely to the extent necessary to facilitate this permission.
A problem with this approach, which is the only one feasible I think, is it has that unfortunate "stet license cleverness" quality to it.
- RF
On Wed, Aug 8, 2012 at 10:16 AM, Richard Fontana fontana@sharpeleven.org wrote:
On 08/07/2012 12:39 PM, Luis Villa wrote:
On Tue, Aug 7, 2012 at 9:22 AM, Richard Fontana fontana@sharpeleven.org wrote:
Luis, what's your take (if any) on MPL/EPL compatibility?
Same problem (inclusion of individual MPL file in an EPL work is problematic.)
To me this just re-states the problem. What is an "EPL work",
I thought it was understood that that is a problem with EPL generally. It's nuts to draft a license that literally cannot be interpreted without hiring a copyright lawyer.
Assuming a weaker definition of "work" (such as you imply might be the case) then MPL is fine with that, as it is concerned only with the individual file(s) under MPL. But I admit I have not looked closely at the EPL community's interpretation of the term.
I'd add that this is less difficult for MPL 2 because:
- It's a relatively weak copyleft; and
- to the extent we're strong (e.g., the patent clause, which I still
need to discuss on this list), the requirement that you be combining with another work under the alternative license mitigates the risk somewhat of someone saying "ah, I'm using under this weaker patent clause, so I can sue you with impunity."
I haven't pushed this to gitorioius yet, but I have a draft EPL compatibility provision that says:
You may Distribute a Derived Work that includes files licensed under the Eclipse Public License 1.0 ("EPL"), provided that such Distribution complies with the requirements of the EPL. The requirement stated in [Distribution: General](b) of This License shall be narrowed in scope solely to the extent necessary to facilitate this permission.
A problem with this approach, which is the only one feasible I think, is it has that unfortunate "stet license cleverness" quality to it.
Yes, but that (and definition of "work") aside, it seems reasonable. Would certainly work for MPL, I would think (though can't review it carefully enough right at this moment to be certain).
Luis
On 08/08/2012 01:23 PM, Luis Villa wrote:
On Wed, Aug 8, 2012 at 10:16 AM, Richard Fontana fontana@sharpeleven.org wrote:
I haven't pushed this to [gitorious] yet, but I have a draft EPL compatibility provision that says:
You may Distribute a Derived Work that includes files licensed under the Eclipse Public License 1.0 ("EPL"), provided that such Distribution complies with the requirements of the EPL. The requirement stated in [Distribution: General](b) of This License shall be narrowed in scope solely to the extent necessary to facilitate this permission.
A problem with this approach, which is the only one feasible I think, is it has that unfortunate "stet license cleverness" quality to it.
Yes, but that (and definition of "work") aside, it seems reasonable. Would certainly work for MPL, I would think (though can't review it carefully enough right at this moment to be certain).
BTW the reason I didn't even think of an "MPL compatibility provision" is because MPL 2.0 and (current) copyleft-next both achieve GPLv2+/AGPLv3+ compatibility. But I wonder if there's some value in making an EPL provision (if it works out) be an "EPL or MPL" provision.
- RF
On Wed, Aug 8, 2012 at 10:41 AM, Richard Fontana fontana@sharpeleven.org wrote:
On 08/08/2012 01:23 PM, Luis Villa wrote:
On Wed, Aug 8, 2012 at 10:16 AM, Richard Fontana fontana@sharpeleven.org wrote:
I haven't pushed this to [gitorious] yet, but I have a draft EPL compatibility provision that says: You may Distribute a Derived Work that includes files licensed under the Eclipse Public License 1.0 ("EPL"), provided that such Distribution complies with the requirements of the EPL. The requirement stated in [Distribution: General](b) of This License shall be narrowed in scope solely to the extent necessary to facilitate this permission.
A problem with this approach, which is the only one feasible I think, is it has that unfortunate "stet license cleverness" quality to it.
Yes, but that (and definition of "work") aside, it seems reasonable. Would certainly work for MPL, I would think (though can't review it carefully enough right at this moment to be certain).
BTW the reason I didn't even think of an "MPL compatibility provision" is because MPL 2.0 and (current) copyleft-next both achieve GPLv2+/AGPLv3+ compatibility. But I wonder if there's some value in making an EPL provision (if it works out) be an "EPL or MPL" provision.
The provision sounds clever, but I'm not sure I understand its effects. Is it intended to *not* reduce copyleft-next's copyleft requirement for derived work to level of EPL (or MPL; and if those two, why not also LGPL?) but allow including files under those licenses, to the extent those licenses would allow it, but copyleft-next would not without this provision? In the case of the EPL that'd be a derived work which is not a derived work under US law, ie nobody can say with any certainty whether the provision permits anything additional in practice?
Mike
On 08/08/2012 02:03 PM, Mike Linksvayer wrote:
On Wed, Aug 8, 2012 at 10:41 AM, Richard Fontana fontana@sharpeleven.org wrote:
On 08/08/2012 01:23 PM, Luis Villa wrote:
On Wed, Aug 8, 2012 at 10:16 AM, Richard Fontana fontana@sharpeleven.org wrote:
I haven't pushed this to [gitorious] yet, but I have a draft EPL compatibility provision that says: You may Distribute a Derived Work that includes files licensed under the Eclipse Public License 1.0 ("EPL"), provided that such Distribution complies with the requirements of the EPL. The requirement stated in [Distribution: General](b) of This License shall be narrowed in scope solely to the extent necessary to facilitate this permission.
A problem with this approach, which is the only one feasible I think, is it has that unfortunate "stet license cleverness" quality to it.
Yes, but that (and definition of "work") aside, it seems reasonable. Would certainly work for MPL, I would think (though can't review it carefully enough right at this moment to be certain).
BTW the reason I didn't even think of an "MPL compatibility provision" is because MPL 2.0 and (current) copyleft-next both achieve GPLv2+/AGPLv3+ compatibility. But I wonder if there's some value in making an EPL provision (if it works out) be an "EPL or MPL" provision.
The provision sounds clever, but I'm not sure I understand its effects. Is it intended to *not* reduce copyleft-next's copyleft requirement for derived work to level of EPL (or MPL; and if those two, why not also LGPL?) but allow including files under those licenses, to the extent those licenses would allow it, but copyleft-next would not without this provision?
Er... yes, I think you have it right. Here it may be useful to think of my traditionalist use of "strong" when speaking of strong copyleft (I see that Luis Villa is also using it more broadly, much like Bradley has). I am diminishing strong copyleft only as much as necessary to permit CN/EPL combinations that would otherwise comprise one unit of CN copyleft scope, if you will.
It's somewhat like GPLv3/AGPLv3 cross-compatibility, but that involved provisions in both licenses.
My avoidance of LGPL is partly for the same reason I stated for my avoidance of MPL: these licenses (now) have GPLv2+/AGPL3+ compatibility, so it seems less important, whereas EPL remains GPL-incompatible.
In the case of the EPL that'd be a derived work which is not a derived work under US law, ie nobody can say with any certainty whether the provision permits anything additional in practice?
That is *probably* right. I may need to provide a more detailed answer to this question, though.
- RF
On Wed, Aug 8, 2012 at 3:10 PM, Richard Fontana fontana@sharpeleven.org wrote:
On 08/08/2012 02:03 PM, Mike Linksvayer wrote:
The provision sounds clever, but I'm not sure I understand its effects. Is it intended to *not* reduce copyleft-next's copyleft requirement for derived work to level of EPL (or MPL; and if those two, why not also LGPL?) but allow including files under those licenses, to the extent those licenses would allow it, but copyleft-next would not without this provision?
Er... yes, I think you have it right. Here it may be useful to think of my traditionalist use of "strong" when speaking of strong copyleft (I see that Luis Villa is also using it more broadly, much like Bradley has). I am diminishing strong copyleft only as much as necessary to permit CN/EPL combinations that would otherwise comprise one unit of CN copyleft scope, if you will.
I was also using "strong" traditionally (which I think of as greediness, meant neutrally a la a greedy regex match, but I know people make much of possible pejorative interpretations of terminology...some people like the hereditary metaphor, thus perhaps traditional "strong" means inverse relationship closeness triggering ~same license requirements) rather than the strength of other intended-as-pro-freedom conditions. (I've heard people refer to CC-BY-SA as a strong copyleft license, which it is in the traditional sense, but hardly at all in an expanded sense, as it doesn't even require modifiable form.) (Incidentally, there's a third kind of copyleft strength, which can't be discerned by reading license text--the universe of stuff licensed under the copyleft in question and perhaps compatible ones; a single atom universe can be incredibly greedy and demanding, but everyone will ignore it. I suspect this kind is more important than the other two, but under-appreciated, as bottom-up things usually are relative to command-and-control things.)
It's somewhat like GPLv3/AGPLv3 cross-compatibility, but that involved provisions in both licenses.
My avoidance of LGPL is partly for the same reason I stated for my avoidance of MPL: these licenses (now) have GPLv2+/AGPL3+ compatibility, so it seems less important, whereas EPL remains GPL-incompatible.
That could be a reason to address MPL and LGPL and avoid EPL: add flexibility within GPL-compatible universe, shun the rest. But...
In the case of the EPL that'd be a derived work which is not a derived work under US law, ie nobody can say with any certainty whether the provision permits anything additional in practice?
That is *probably* right. I may need to provide a more detailed answer to this question, though.
I'm surprised you're interested in adding linecount and incomprehensibility to achieve a low-certainty and small effect. Sort of like I said on identi.ca, I don't see the point unless somehow this would politically lead to an EPL 2.0 which would join the GPL-compatible universe.
Mike
On 08/08/2012 06:59 PM, Mike Linksvayer wrote:
I'm surprised you're interested in adding linecount and incomprehensibility to achieve a low-certainty and small effect. Sort of like I said on identi.ca, I don't see the point unless somehow this would politically lead to an EPL 2.0 which would join the GPL-compatible universe.
I'm convinced. Deleted!
- RF
On Wed, Aug 8, 2012 at 6:04 PM, Richard Fontana fontana@sharpeleven.org wrote:
On 08/08/2012 06:59 PM, Mike Linksvayer wrote:
I'm surprised you're interested in adding linecount and incomprehensibility to achieve a low-certainty and small effect. Sort of like I said on identi.ca, I don't see the point unless somehow this would politically lead to an EPL 2.0 which would join the GPL-compatible universe.
I'm convinced. Deleted!
Can I push back? If you're looking to have copyleft-next actually used (not 100% clear this is a goal :) then eliminating some of the rough edges through allowing simple inclusion of already-quite-open code in this manner is a good tactic, with zero downside to user freedom that I can see, and only a small cost to license complexity. That said, you could frame it differently; basically, define the criteria you'd like to see in an inbound license and allow its inclusion.
Luis
On 08/08/2012 09:15 PM, Luis Villa wrote:
On Wed, Aug 8, 2012 at 6:04 PM, Richard Fontana fontana@sharpeleven.org wrote:
On 08/08/2012 06:59 PM, Mike Linksvayer wrote:
I'm surprised you're interested in adding linecount and incomprehensibility to achieve a low-certainty and small effect. Sort of like I said on identi.ca, I don't see the point unless somehow this would politically lead to an EPL 2.0 which would join the GPL-compatible universe.
I'm convinced. Deleted!
Can I push back?
Yes. I am deleting the provision for now but it will be an issue in the Currently-Nonexistent Issue Tracker.
If you're looking to have copyleft-next actually used (not 100% clear this is a goal :)
It is certainly a goal.
then eliminating some of the rough edges through allowing simple inclusion of already-quite-open code in this manner is a good tactic, with zero downside to user freedom that I can see, and only a small cost to license complexity. That said, you could frame it differently; basically, define the criteria you'd like to see in an inbound license and allow its inclusion.
It's that last part that I'm not sure about. You may not have meant this but I took that to mean 'adopt a GPLv3-style approach', by which I mean try to define general categories of acceptable license provisions that might otherwise cause a license to be treated as GPL-incompatible.
I've already decided this is a bad approach (because under A/GPLv3 it has led to some unanticipated areas of uncertainty as well as occasional misuse, and otherwise it hasn't really been necessary), but I don't even know how one could begin to define a set of abstract categories that would add up to the Eclipse Public License 1.0. I think the only way to do it is to say "EPL code is compatible" (maybe the way I initially tried but more comprehensibly), or to use the magical relicensing trick. The magical relicensing trick seems unacceptable essentially because it becomes an escape hatch from a strong copyleft license (a design goal).
What I found at least temporarily convincing in Mike's comments was, first, his saying that what I wrote is incomprehensible (another design goal is maximal comprehensibility), and second, his hint that this may be bad policy.
- RF
On Wed, Aug 8, 2012 at 6:49 PM, Richard Fontana fontana@sharpeleven.org wrote:
What I found at least temporarily convincing in Mike's comments was, first, his saying that what I wrote is incomprehensible (another design goal is maximal comprehensibility), and second, his hint that this may be bad policy.
My comment "adding linecount and incomprehensibility" may have been too strong -- I meant "and reducing comprehensibility". Also, I didn't mean to hint that the provision is bad policy, but rather ineffective, with respect to the EPL -- based on my understanding which I guess is not totally wrong based on your response in https://lists.fedorahosted.org/pipermail/copyleft-next/2012-August/000127.ht... (but I'm happy for my guess to have been merely incomprehensible and totally wrong).
"eliminating some of the rough edges through allowing simple inclusion of already-quite-open code" as Luis put it is a desirable goal. The provision does seem effective to me if it addressed the MPL -- there are cases where unambiguously MPL code could be included in a copyleft-next project, if only copyleft-next allowed for it.
Maybe it'd be nice to allow inclusion of code under any copyleft license (that is actually a free software license of course) to the extent copyleft-next can allow it, in the way the draft had stated for EPL (not weakening copyleft-next's copyleft, except with respect to the files included under other copyleft). But it'd only make a difference for weak copylefts, or future strong copylefts that explicitly address copyleft-next or general class strong copylefts.
Mike
Mike Linksvayer wrote on 9 August:
there are cases where unambiguously MPL code could be included in a copyleft-next project, if only copyleft-next allowed for it.
Honestly, I'm not convinced that a truly strong copyleft can allow unilaterally inclusion of other copylefted code -- even weak -- without bilateral compatibility clauses. We have to consider that such provisions while seemly safe on the surface may actually be manipulated to undermine the stronger copyleft by enterprising defense attorneys.
Richard Fontana wrote on 2 September:
This proposal might make the most sense for licenses that are generally considered non-copyleft but GPL-incompatible (the proposed language seems modeled on things like the [I believe FSF-recommended] OpenSSL GPL linking exception). For copyleft licenses, it raises the same problem on a more general level that we dealt with when thinking about a clause that would achieve EPL compatibility.
Exactly. I think anyone who wants this kind of compatibility has to prove that it can't be used by the nefarious to circumenvent copyleft.
Note that the ways copyleft is subverted are subtle and complicated. Most people don't see that because they rarely get the rather horrible experience of regularly dealing with people who are trying. You may have to take my word for it that this happens, but if folks want to raise specific questions, I'm happy to talk about it in detail. There's enough of it and it's common enough that it's difficult to generalize.
On Thu, Oct 11, 2012 at 10:45 PM, Bradley M. Kuhn bkuhn@ebb.org wrote:
Mike Linksvayer wrote on 9 August:
there are cases where unambiguously MPL code could be included in a copyleft-next project, if only copyleft-next allowed for it.
Honestly, I'm not convinced that a truly strong copyleft can allow unilaterally inclusion of other copylefted code -- even weak -- without bilateral compatibility clauses.
I don't see why not, when the weaker copyleft's scope is unambiguously a subset of the stronger one's. MPL and copyleft-next seem such a case. One can comply with MPL's file-scoped copyleft by keeping MPL'd files under MPL. These could be incorporated in a copyleft-next project if copyleft-next permitted it. Maybe (wild speculation!) they can be even if not explicitly permitted, just as permissively licensed files can be.
We have to consider that such provisions while seemly safe on the surface may actually be manipulated to undermine the stronger copyleft by enterprising defense attorneys.
Ok, I now see "truly" as an important qualifier to "strong copyleft can allow...". Additionally, added complexity may not be worth it.
and
Richard Fontana wrote on 2 September:
This proposal might make the most sense for licenses that are generally considered non-copyleft but GPL-incompatible (the proposed language seems modeled on things like the [I believe FSF-recommended] OpenSSL GPL linking exception). For copyleft licenses, it raises the same problem on a more general level that we dealt with when thinking about a clause that would achieve EPL compatibility.
Exactly. I think anyone who wants this kind of compatibility has to prove that it can't be used by the nefarious to circumenvent copyleft.
Note that the ways copyleft is subverted are subtle and complicated. Most people don't see that because they rarely get the rather horrible experience of regularly dealing with people who are trying. You may have to take my word for it that this happens, but if folks want to raise specific questions, I'm happy to talk about it in detail. There's enough of it and it's common enough that it's difficult to generalize.
I'm curious about how one would exploit (as in undermine strong copyleft) permission to add MPL licensed files to a copyleft-next project, files remaining under MPL. I guess that one would start by contributing MPL files, and eventually rewrite copyleft-next portions, such that the whole project consists of nothing but MPL files. In some case I guess this could make avoid-strong-copyleft-through-reimplementation more feasible by providing a bridge to such. But I'm guessing you have one or more nefarious strategies in mind?
Mike
Sorry for bumping this discussion thread this late, but I discovered the Berkeley DB license* ("the BDB") and it made me think about what had been said here.
https://www.gnu.org/licenses/license-list.html#BerkeleyDB
Haven't looked at the BDB before, and I find it interesting. Taking into account only the numbered points, it might be the shortest example of a copyleft license in use in the field, even close to the shortest possible. It's close in form to a BSD-like license plus source requirement.
The FSF claims that the BDB is GPL compatible, I assume because it does not specify anything outside the bare minimum, in particular does not restrict any "further restrictions". Does it even propagate a guarantee of the four freedoms to modified versions of the software?
On 2012-10-12 13:45, Bradley M. Kuhn wrote:
Mike Linksvayer wrote on 9 August:
there are cases where unambiguously MPL code could be included in a copyleft-next project, if only copyleft-next allowed for it.
Honestly, I'm not convinced that a truly strong copyleft can allow unilaterally inclusion of other copylefted code -- even weak -- without bilateral compatibility clauses. We have to consider that such provisions while seemly safe on the surface may actually be manipulated to undermine the stronger copyleft by enterprising defense attorneys.
Is the BDB a counter-example to your thesis? Or is it not "truly strong"?
It seems to me that any license, that accepts whatever added conditions another license contains, will be forward-compatible with the more restrictive license. Either by enumerating certain allowed further restrictions, like the GPLv3 vs the AGPLv3, or by not explicitly forbidding any, like the BDB.
The point about using a weaker license to undermine a stronger one stands, whether if it means using a weaker, forward-compatible license to gradually rewrite the code base, or if it means some currently unknown license jujutsu.
On Thu, Nov 8, 2012 at 11:35 PM, "Claes Wallin (韋嘉誠)" copyleft-next@clacke.user.lysator.liu.se wrote:
Sorry for bumping this discussion thread this late, but I discovered the Berkeley DB license* ("the BDB") and it made me think about what had been said here.
https://www.gnu.org/licenses/license-list.html#BerkeleyDB
Haven't looked at the BDB before, and I find it interesting. Taking into account only the numbered points, it might be the shortest example of a copyleft license in use in the field, even close to the shortest possible. It's close in form to a BSD-like license plus source requirement.
BDB/Sleepycat is a pretty unusual license -- it doesn't have a use-the-same-license condition, but does have a source condition, and a really aggressive one at that ("complete source code for the DB software and any accompanying software that uses the DB software"). I'm not certain how this can be GPL compatible or OSD compliant, unless "uses" is interpreted in a way that just happens to be less than or equal in scope to the GPL's conception of derivative works -- see section 9 of http://opensource.org/osd-annotated
I'm sure these have been discussed extensively but I wish the FSF and OSI provided references on the relevant pages. :)
The FSF claims that the BDB is GPL compatible, I assume because it does not specify anything outside the bare minimum, in particular does not restrict any "further restrictions".
Presumably, though per above, I wonder about the justification.
Does it even propagate a guarantee of the four freedoms to modified versions of the software?
Not AFAICT.
On 2012-10-12 13:45, Bradley M. Kuhn wrote:
Mike Linksvayer wrote on 9 August:
there are cases where unambiguously MPL code could be included in a copyleft-next project, if only copyleft-next allowed for it.
Honestly, I'm not convinced that a truly strong copyleft can allow unilaterally inclusion of other copylefted code -- even weak -- without bilateral compatibility clauses. We have to consider that such provisions while seemly safe on the surface may actually be manipulated to undermine the stronger copyleft by enterprising defense attorneys.
Is the BDB a counter-example to your thesis? Or is it not "truly strong"?
I don't think it is a counter-example because it isn't "truly strong" in both (require same/similar license permissions, and require source) obvious dimensions, but the question is whether a "truly strong" copyleft license can usefully explicitly permit including works under a weaker copyleft license, in a way that does not trigger the weaker copyleft. If BDB/Sleepycat had any kind of licensing requirement for derivatives, the FSF's statement about it being GPL compatible would be more interesting for this discussion.
It seems to me that any license, that accepts whatever added conditions another license contains, will be forward-compatible with the more restrictive license. Either by enumerating certain allowed further restrictions, like the GPLv3 vs the AGPLv3, or by not explicitly forbidding any, like the BDB.
The point about using a weaker license to undermine a stronger one stands, whether if it means using a weaker, forward-compatible license to gradually rewrite the code base, or if it means some currently unknown license jujutsu.
Yeah, I'd like all jututsu theories be put on the table. The security of software freedom not optimally maintained through obscurity. ;-)
Mike
On 11/09/2012 05:27 PM, Mike Linksvayer wrote:
BDB/Sleepycat is a pretty unusual license -- it doesn't have a use-the-same-license condition, but does have a source condition, and a really aggressive one at that ("complete source code for the DB software and any accompanying software that uses the DB software"). I'm not certain how this can be GPL compatible or OSD compliant, unless "uses" is interpreted in a way that just happens to be less than or equal in scope to the GPL's conception of derivative works -- see section 9 of http://opensource.org/osd-annotated
I'm sure these have been discussed extensively but I wish the FSF and OSI provided references on the relevant pages. :)
I can't locate it at the moment, but there is or has been an informational webpage at oracle.com on the Sleepycat License that notes that it is GPL-compatible. I have interpreted that, plus the FSF's assessment, to mean that the Sleepycat License must be read in such a way that it is GPL-compatible; therefore the scope implied by "any accompanying software that uses" can be no broader than the scope implied by the GPL (whatever that might be).
The OSI decision would follow from the assumption of GPL compatibility, though I suspect that that is not why the OSI chose to certify the Sleepycat License as OSI-compliant. Perhaps there's some information in the license-discuss archives. If one assumes that the OSI made its decisions with the OSD in mind, "any accompanying software that uses" must somehow be harmonized with OSD #9 ("The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.") Of course the Sleepycat License is assumed to be DFSG-conformant as well.
The likely sociological reality is that the license was just grandfathered into the system.
- RF
On Sun, Nov 18, 2012 at 8:44 AM, Richard Fontana fontana@sharpeleven.org wrote:
The OSI decision would follow from the assumption of GPL compatibility, though I suspect that that is not why the OSI chose to certify the Sleepycat License as OSI-compliant. Perhaps there's some information in the license-discuss archives.
Not that it really matters, but all I could find was an approval announcement http://www.crynwr.com/cgi-bin/ezmlm-cgi/3/3191
On Sun, Nov 18, 2012 at 9:09 AM, Richard Fontana fontana@sharpeleven.org wrote:
It's worth noting that the Sleepycat License was designed with what bkuhn would call a 'proprietary relicensing' business model in mind (at least based on the historical material I recall seeing). I suppose if that's true it might seem to suggest that the Sleepycat License was meant to be read as having a *broader* copyleft-ish scope than GPLv2 (which would imply that the FSF seemingly erred in classifying it as GPL-compatible). (Why else would Michael Olson or whoever wrote the license not have just used GPLv2? Berkeley sentimentality?)
http://www.crynwr.com/cgi-bin/ezmlm-cgi/3/9845 says "For embedded use, the Sleepycat license might be a little bit stronger than the GPL (if the manufacturers plan to bundle any enhancements at all); it certainly has worked for Sleepycat to bring device makers (like Cisco) to the table."
Mike
On 11/09/2012 02:35 AM, "Claes Wallin (韋嘉誠)" wrote:
Sorry for bumping this discussion thread this late, but I discovered the Berkeley DB license* ("the BDB") and it made me think about what had been said here.
https://www.gnu.org/licenses/license-list.html#BerkeleyDB
Haven't looked at the BDB before, and I find it interesting. Taking into account only the numbered points, it might be the shortest example of a copyleft license in use in the field, even close to the shortest possible. It's close in form to a BSD-like license plus source requirement.
I'm not sure it's truly a (free software) copyleft license, though it's something similar. It says that the source code that you have to provide must be "freely redistributable under reasonable conditions". Does this mean that the conditions in the redistributor's license must allow royalty-free modification, say? I suppose I would argue yes, because of how I believe the term "freely redistributable" was understood in the 1990s.
The FSF claims that the BDB is GPL compatible, I assume because it does not specify anything outside the bare minimum, in particular does not restrict any "further restrictions".
The FSF (assuming the FSF analyzed the case carefully) must be assuming that the word "uses" in "any accompanying software that uses the DB software" would never lead to a result in which you'd have to provide more source code than you'd have to in a standard GPLv2 situation (as the FSF would interpret that). In other words, the FSF must be assuming there is an implied "mere aggregation" limitation on the source code requirement.
Does it even propagate a guarantee of the four freedoms to modified versions of the software?
I think this depends on how you read "freely redistributable under reasonable conditions".
It's worth noting that the Sleepycat License was designed with what bkuhn would call a 'proprietary relicensing' business model in mind (at least based on the historical material I recall seeing). I suppose if that's true it might seem to suggest that the Sleepycat License was meant to be read as having a *broader* copyleft-ish scope than GPLv2 (which would imply that the FSF seemingly erred in classifying it as GPL-compatible). (Why else would Michael Olson or whoever wrote the license not have just used GPLv2? Berkeley sentimentality?)
- RF
On 08/06/2012 08:07 PM, Tom Marble wrote:
AFAICT the incompatibility rises from the EPL choice of venue [2] which makes EPL not GPL compatible.
Choice of law, actually. But as Luis Villa explained there are other problems.
For the most part I would say I don't agree with the FSF on the notion that presence of a choice of law clause gives rise to GPL incompatibility. The FSF has never, to my knowledge, provided an explanation of why this is so *in general* (I understand how it might be so in a specific case, such as the "Unfreedonia" hypothetical Eben Moglen has mentioned). But usually where one is assessing GPL compatibility of another license that has a choice-of-law clause, there are one or more other clauses that separately give rise to concerns about GPL compatibility, as is true of the EPL and its ancestors.
Discussion Draft 2 of GPLv3 (June 2006) actually stated explicitly that "choice of law, forum and venue" clauses (among some other kinds of provisions or conditions) were to be treated as incompatible, but this was removed from GPLv3 Discussion Draft 3 (March 2007), with this explanation in the accompanying rationale document:
"The list in the final paragraph of 7b accurately presented our historical view regarding each such requirement. With at least some of the items in the list, however, there may be particular circumstances in which categorical exclusion will lead to an incorrect result. We think it is better, then, to leave this list out of the license text."
- RF
On 08/08/2012 01:10 PM, Richard Fontana wrote:
Choice of law, actually. But as Luis Villa explained there are other problems.
Thank you for that clarity on choice of venue (etc.). I think is interesting to read @webmink's take on this subject [0].
With your "draft EPL compatibility provision" in combination with this entry from the EPL FAQ [0] suggests that both licenses can be satisfied (i.e. interpreting "narrowing") by re-distributing any upstream EPL code under the EPL and any other additional code under CLN.
Is that an accurate interpretation?
Separately, does the "Proprietary Relicensing" provision of 6.b) reference "this clause" refer only to §6.b) -or- to the entirety of §6 (preventing any distribution)?
Regards,
--Tom
[0] https://blogs.oracle.com/webmink/entry/choice_of_venue [1] http://www.eclipse.org/legal/eplfaq.php#PROPPROD
On 08/08/2012 02:42 PM, Tom Marble wrote:
With your "draft EPL compatibility provision" in combination with this entry from the EPL FAQ [0] suggests that both licenses can be satisfied (i.e. interpreting "narrowing") by re-distributing any upstream EPL code under the EPL and any other additional code under CLN.
Is that an accurate interpretation?
That's kind of what I'm envisioning (if I interpreted your explanation of it correctly).
Separately, does the "Proprietary Relicensing" provision of 6.b) reference "this clause" refer only to §6.b) -or- to the entirety of §6 (preventing any distribution)?
It says "this clause b)" in the latest version in the gitorious repository. In case the idea isn't clear, it's quite simple: if you (or rather 'We' - in fact it has to be the 'original We' to be done legitimately) do what Bradley calls "proprietary relicensing", that's fine, but then copyleft-next turns into a non-copyleft license, thus permitting all licensees to do their own proprietary relicensing if they so wish.
I have a revised version I haven't pushed that I think makes this a bit clearer. As a separate paragraph:
The preceding condition shall not apply to Your Derived Work if We Proprietary-Relicense. "Proprietary-Relicense" means to commercially offer a work that would be a Covered Work had You prepared it, under a license that fails to satisfy version 1.111 of the Free Software Definition as published by the Free Software Foundation ("FSF").
- RF
copyleft-next@lists.fedorahosted.org
-
Bradley M. Kuhn -
Claes Wallin (韋嘉誠) -
Luis Villa -
Mike Linksvayer -
Richard Fontana -
Tom Marble