On Thu, 27 Feb 2014 22:42:11 -0600
Tom Marble <tmarble(a)info9.net> wrote:
On 02/24/2014 12:23 AM, Richard Fontana wrote:
Could you explain the rationale for changing from referring to
Work" to "My Code"? Is this an explicit attempt to the narrow the
scope to software (vs. other artifacts like artwork, documentation,
No substantive change is implied. You can use this license for
non-software works, though as with the GPL it is oriented towards
software. As for the rationale, it's really just annoyance with the
> Section 2b:
> (Non-GPL) license compatibility is now dealt with...
"You have permission to ignore subsection 2c solely to the extent
necessary to comply with such other license"
Does this solve the gridlock from typical license text language which
says, effectively, "you may combine other code as long as the
combined work is licensed under THIS license"?
Sort of. It's intended to get around the problem of arguably
conflicting copyleft requirements, without taking a position on what
they actually mean. The idea is no one can argue that copyleft-next is
incompatible with MPL 2.0, EPL 1.0 or even LGPL (or vice-versa). The
intent is that you still have to provide Corresponding Source, even
for the part of the derivative work that is under the other copyleft
license, if you distribute binaries.
For example if an EPL-1.0 work is combined with a copyleft-next work
can the result be combined such that the EPL-1.0 governs only
the first part and copyleft-next the latter part -- unless such
a separation is infeasible.
I'm not sure it's clear how the EPL part can be licensed if we're
talking about a binary. If it's LGPL let's assume that I have to put
the LGPL part of the binary under LGPL (though that might not be a
correct interpretation of any particular version of the LGPL). With
EPL, I shouldn't be able to put the EPL part under a proprietary
license. I think it ought to be okay to put it under EPL. It also ought
to be okay to put it under copyleft-next (something I assume you
couldn't do with LGPL, and certainly not GPL). There might be a problem
here, or at least this needs some further work.
If the code is mixed would the fused
work need to be licensed solely under EPL-1.0 or would some or all
of the copyleft-next restrictions also apply?
This may depend on how you interpret EPL and also when you think
'fusing' has occurred (related questions). Again I think this can
probably be made clearer though I don't want the result to be 'treat
EPL like GPL' (one-way compatibility).
Is elaborating a list of Code build dependencies be
included in the intent of 2.d.iii?
This originated in some discussions with bkuhn. See:
which I think reflects bkuhn's views in 2008.
This is an expansion of the corresponding source code requirement as it
exists in GPLv2 and GPLv3.
An argument might be made that this is not practical as currently
worded (unless you interpret it narrowly enough to be practical, which
is what I intended). It's easy enough to say "We used an
internally-modified version of GCC based on version 4.8.2", which I
don't think is an unreasonable or excessively burdensome thing to have
to disclose, but I'm not sure where it stops. Too
bad bkuhn no longer reads this list, as I'm sure he could help!