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