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