6

GNU Emacs is licensed under the GNU General Public License (GPL). The GPL is a copyleft license that requires any derivative work to also be GPL-licensed. Does that impose restrictions on what license can be chosen for third-party Emacs packages such as those found in MELPA and several other repositories around the internet?

I believe the answer to this question depends on the interpretation of the legal term derivative work: if a third-party package is a derivative work of GNU Emacs then the package must be GPL, else it can use another license. (Similar concerns have historically arisen with dynamically linked libraries.) I didn't find any clearly stated opinion on this matter on EmacsWiki, the Emacs Lisp reference manual or the GNU website.

In practice, we have third-party packages bearing e.g. the MIT license notice, but I wonder whether that license notice has legal clout and the real license ought to be GPL anyway.

Lassi
  • 377
  • 1
  • 7
  • The word `derivative` does not appear in the text of the GPLv3. It actually refers to modifying the original program, where previous versions referred to creating a derivative. I'm not sure what the legal consequences of that are. In plain english, I think it's easier to make the case that a package is a 'derivative' than that it is actually a 'modification'. – Tyler Nov 29 '18 at 16:11

1 Answers1

3

An MIT license is clearly fine, since it is compatible with the GPLv3+.

What is less clear is whether it would be legal to release an Elisp package with a license that is not compatible with the GPLv3+ (e.g. a proprietary license).

I believe it wouldn't be legal unless you can show that this package also works with some other non-GPL'd implementation of Elisp.

Stefan
  • 26,154
  • 3
  • 46
  • 84
  • It's true that any MIT code can be combined with any GPL code. However, if the MIT code is a derivative work of the GPL code (instead of being a completely unrelated work) then it's not clear that its authors had permission to release it under MIT in the first place. If this weren't so, then in the extreme case you could take any GPL code you found and re-release it as MIT. This is one of the infamous muddy problems of open source licensing, and AFAIK the answer always comes down to interpretation by the courts or the rights holders. – Lassi Nov 29 '18 at 15:45
  • Another thing that's not clear is whether the Emacs Lisp language itself is under GPL. And if you made a clean-room implementation of it without looking at the Lisp interpreter inside GNU Emacs, could you claim that you reverse engineered it and therefore the GPL doesn't apply. – Lassi Nov 29 '18 at 15:46
  • 1
    To state the main problem even more clearly: "From a legal standpoint, is every Emacs Lisp package actually a derivative work of GNU Emacs?" Or many or most packages, at any rate. Where should we draw the line? – Lassi Nov 29 '18 at 15:51
  • Elisp packages are not derivative works of Emacs, no. But they *link* to Emacs, hence the need to be GPL-compatible. – Stefan Nov 29 '18 at 17:16
  • The linking issue arises in the first place because linked code is potentially a derivative work in legal terms. https://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works summarizes this well. – Lassi Nov 29 '18 at 17:43
  • 1
    The most common interpretation of this linking problem seems to be that a communicating OS process is not a derived work, but a dynamically or statically linked library is. Programs in a programming language are usually not considered derived works, even if there's only one implementation of the language. But then Emacs Lisp is a special purpose programming language for one application only (Emacs). None of these views are unanimous. So unfortunately it is absolutely not clear that an MIT ELisp package is fine or that ELisp packages are not derivative works of Emacs :-/ Hence this question. – Lassi Nov 29 '18 at 17:53