[copyleft-next] HBR cure for 2013-02-03

Richard Fontana fontana at sharpeleven.org
Thu Feb 7 02:34:13 UTC 2013

I just realized that a part of my brief conversation with Mike
Milinkovic following my FOSDEM talk triggers HBR.

While not a substantive point, I noted to Mike my interest in
submitting some version of copyleft-next for OSI approval. (Mike, who
heads the Eclipse Foundation, is on the OSI board of directors.)

The substantive point, though, was this: we were talking about how the
EPL (like the MPL and its relatives) allows proprietary licensing of
binary versions. I told him that I had recently thought about whether
this was in conflict or not with the basic notion of strong copyleft,
and whether copyleft-next could or should be revised to allow more
restrictive licensing of binaries (more restrictive than
copyleft-next/GPL/AGPL, that is). That might sound heretical, but it
is not meant to be. It relates to a historical puzzle I have thought

I noted that the GNU GPL was originally intended for software that
would be compiled by proprietary compilers and run on proprietary
operating systems. The earliest binary versions of GNU Emacs must have
contained proprietary code. This of course was what led RMS to add
what came to be known as the system library exception to the
definition of 'complete source code'. But the system library exception
does not tell us what the license of a statically-linked binary formed
out of GPL-licensed code and 'system library' code is supposed to be.

I am not sure whether RMS thought about this issue. It is possible
that the licensing terms governing the various operating systems and
compilers in use among the early users/porters of GPL-licensed
programs like GNU Emacs were such that the question was thought to be

 - RF

More information about the copyleft-next mailing list