emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs contributions, C and Lisp


From: David Kastrup
Subject: Re: Emacs contributions, C and Lisp
Date: Sat, 01 Mar 2014 21:17:56 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Óscar Fuentes <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
>> Óscar Fuentes <address@hidden> writes:
>>
>>> Just in passing I'll mention that that was one of the main motivations
>>> for creating Clang. Some of today's Clang heavy contributors would
>>> have preferred to do that modularization on GCC instead of starting
>>> from scratch on a new project, but that was forbidden. Hence Clang is,
>>> in great part, a consequence of the GNU policies intended to avoid GCC
>>> usage by non-free software. Ironic, uh?
>>
>> 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.

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]