Re: Emacs contributions, C and Lisp

[Óscar Fuentes]

David Kastrup <address@hidden> writes:

>>> Not particularly.  The GPL has been crafted to use a subset of
>>> restrictions created by copyright law for ensuring a corpus of software
>>> that cannot be used to create software with other restrictions.
>>
>> IIUC what you say does not apply on this specific case,
>
> You don't understand correctly.
>
>> because those "heavy contributors" I'm talking about are, in essence,
>> Google employees who are interested on creating tools for
>> themselves. AFAIK the GPL is not an issue for them on this case and
>> they will be happy to contribute back those tools to GCC, as they do
>> for Clang.
>
> The Google employees are not the ones who have to figure out the
> technical consequences of letting the GPL keep serving its purpose with
> GCC.  Apparently you believe that all one needs to do for copyleft to
> achieve its goals is to write the GPL and/or slap it on arbitrary
> software and then retire.  Which would probably have made Richard quite
> more popular with a number of people, but that was never an objective.
>
> The basic "irony" requires more than just maintaining the GPL itself, it
> also means technical and strategical decisions that serve to make the
> GPL extend to derived applications in a useful and court-defensible
> manner.
>
> In this particular case, as I understand it basically from hearsay as
> I am not involved with GCC, there were several decisions made by Richard
> in the past stopping various attempts at modularizing GCC, like
> particular forms of plugins.  The GPL can place demands on a derived
> work "as a whole" but does not extend its reach to separate programs
> that can, thanks to using well-defined interfaces, be considered as not
> being part of the same work.
>
> It does not really matter whether or not the Google engineers would have
> been willing to contribute under the GPL: their work would have become
> part of upstream GCC only when they were willing/able to assign
> copyright to GCC.  But providing the interfaces where they would not
> have needed to work with the source code of GCC itself would have meant
> _exactly_ that they would not even have needed to release their part of
> the work under the GPL because it was _separable_.  Whether or not they
> would have released under the GPL and/or reassigned copyright anyway,
> anybody else would have been able to release works depending on GCC with
> parts released under non-free licenses.
>
> That's the "ironic" line that Richard and the FSF are navigating.  And
> if you are planning to sway his opinion, it would be smart to first
> understand what it is based on.

[Thanks for the detailed explanation. This is a complex topic, my
English is poor and I have little time, so forgive me if what follows is
not too very well connected.]

I understand that spreading and enforcing copyleft is the raison d'être
of the FSF. It is also true that on the past other not-so purist
strategies were used (GPL+runtime exception, LGPL).

The ironic part I was talking about not only consists on hackers who
right now are contributing to Clang when they could be contributing to
GCC.

Due to its insistence on making things difficult for non-free software
by banning GCC modularization and API opennes, the FSF helped to create
the environment for Clang to arise. So now non-free software has a more
convenient tool than GCC ever could be (friendly API plus non-copyleft
license) *and* on addition GCC's long-term relevance is threatened.

If GCC architecture turned to be more Clang-like, the GPL would still be
a deterrent for non-free software developers, but GCC could be competing
on technical merit with Clang beyond the traditional compiler realm.

The argument about non-free backends using GCC as a front-end does not
hold much water, because that could be happening now. See gcc-xml: if it
falls short of exporting the full tree is probably because the author
was uninterested on doing that, not because the information is missing.

If you have a minute, take a look at how Clang can be used by external
software (apart from the GCC-style of running the driver and collecting
the output on some file/stream) and see how the GPL would be effective
against non-free applications of Clang, if it were GPLed:

http://clang.llvm.org/docs/Tooling.html

There are essentially two methods: link to a Clang library (and then you
have a combined work) or command the driver to load a plugin, which is
also acceptable by the FSF (IIRC GCC and ld support that.) So there is
not too much of an opportunity to make a "separable" work there, unless
you do a stub driver that uses the Clang libraries, dumps the output to
a stream, and then read that stream from the separate, non-free tool.
But, as mentioned, that was always possible with GCC.

Sorry if I'm still missing the crux of your argument, but nevertheless I
hope to have provided some food for thought.