Anything that looks like *GPL will be avoided because of its virality.
How is EPL incompatible with GPL and what licenses are friendly to it? Apache License v2? (That's another one I was considering)
Anything that looks like *GPL will be avoided because of its virality.
How is EPL incompatible with GPL and what licenses are friendly to it? Apache License v2? (That's another one I was considering)
For programming languages that include a prelude or standard library on which most actual programs will rely on in whole or in part, it may be problematic (and, of course, its especially problematic for languages where substantial parts of the interpreter/compiler itself is part of that standard library, as is the case of any language which implements a general purpose eval.)
That way, if someone wants to create an online Lux REPL for people to try Lux, it won't be hard for them to do so.
But I understand if you prefer a more permissíve license. Lots of people go with MIT License, it's very short, permissive and compatible with the GPL. Apache v2 is also compatible.
See here about EPL being incompatible: https://www.fsf.org/blogs/licensing/using-the-gpl-for-eclips...
Last time I tried understanding the key subtleties of the EPL I came out empty handed, but it would seem it's more viral than the permissive licenses above, bit less so than the GPL.
* That's why the AGPL exists, so someone working on a Lux REPL would only have to show the code for his online Lux modifications if Lux was AGPL.
The GPL is pretty much banned across the entire industry because of the fact that it forces accompanying software to be open sourced as well, which is a deal breaker for most companies.
The GPL explicitly doesn't require accompanying software to be released under any particular license. (See, e.g., GPLv3 Sec. 5, ending with "Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.")