Re: clang vs free software

[David Kastrup <dak@gnu.org>]

Helmut Eller <eller.helmut@gmail.com> writes:

> On Sun, Jan 26 2014, Richard Stallman wrote:
>
>>     Maybe nobody bothers because using clang is easier than to fight with
>>     FSF policies.
>>
>> If you mean the policy that we don't let GCC become a platform for
>> proprietary compilers, what does it mean to think of this as something
>> to "fight"?
>
> With "fight" I mean explaining for the hundredth time that the FSF
> policy of introducing artificial technical hurdles to prevent some
> nonfree programs does

Since the whole point of the GPL is to introduce an "artificial hurdle"
preventing turning code into proprietary programs, and since it works,
according to the copyright laws it relies on, by covering works "as a
whole", any technical measures intended to provide an interface that
separates components into separate identifiable wholes have an effect on
the range of the GPL.

The GPL introduces restrictions, and making those restrictions be part
of an overall strategy requires making decisions that take into account
the reach of those restrictions.

That's not artificial.  It's an inherent consequence of the approach
taken by the GPL that we'll be explaining and weighing consequences for
the hundredth and the thousandth time since the whole purpose of the GPL
is to execute a measure of control over the consequences.

>  a) cause more "collateral damage" than it prevents real damage.

This does not get any more true by repeating it the thousandth time.  If
you take a look at something like MacOSX, it is a largely closed-down
system used for restricting user freedom, and its operating system basis
is BSD UNIX.  This is a real and lasting damage to the freedom of
software users, and Apple has been handed the power to keep doing this
damage by the undiscriminating licensing of BSD derivatives.

Most compilers for special processors like GPUs are kept locked down,
denying the freedom of users to work with their hardware according to
their own problems.  They also deny the freedom of other hardware
vendors to study and learn from the code and improve on the design of
both hard- and software, thus advancing the field in a manner where the
advances are available to everyone.

Yes, the mechanisms of the GPL works through restrictions, and
restrictions apply to everyone.  That is why we have to vet our
technical decisions against the purpose of the GPL and the respective
effects of the restrictions all the time.

[...]

> IMO, we would be better served with legal hurdles than with technical
> hurdles.

It is wishful thinking that one can be separated from the other.
Copyright covers copyrightable entities, and entities are determined
mostly by technical designs and decision.

> E.g. the license could say that using GCC as platform for proprietary
> compilers (DragonEgg) are not allowed, while using GCC as platform for
> free compilers (or editors like Emacs) is allowed and welcome.

No, that is absolutely one thing that the license could not say.
Whatever is not prohibited by default by copyright is _nothing_ that we
have any power to enforce.  The GPL is not a contract, it is a license.
It spells out the conditions under which the full restrictions granted
by copyright will get waived.  It is not in our power to add additional
restrictions.  Running a program that you legally acquired, for any
purpose whatsoever, is your default right.

It may be easy to forget given all the fairy tale restrictions big
vendors place into their "licenses" that are actually contracts with
various mechanism for purported agreement, but that's not how licenses
work.  Licenses are permissions.

> (Clang/LLVM is free software, as far as I can tell. So discouraging
> integration of Clang with Emacs has probably not so much to do with a
> free/nonfree distinction but more with a gnu/nongnu distinction.)

It has nothing to do with free/nonfree with regard to the use itself.
What it has to do with is with encouraging solutions that are clearly
not trying to be a _sustainable_ source of freedom.  It's worse in that
respect than FreeBSD/NetBSD and similar since _those_ are at least
currently driven by communities that are, for better or worse, fighting
for _their_ kind of freedom.  In contrast, a lot of the substantial
support for Clang comes from parties who are rather interested in having
an upstream available that can be convenient for their kind of
unfreedom.

That's an area that we don't want GCC to compete in.  So we want to make
our technical decisions in a manner where we don't open GCC up for
integration into a market of proprietary tools, and that means that it's
not possible to take the technical measures where GCC can be used as an
entirely separate and independently licensed component for free
solutions, either.

That's a balancing act, and the question is not whether to do that
balancing act (we would not have the GPL if we had not answered that
question with "yes") but how.

And it's rather exasperating if people keep pretending that nobody has
thought about this before and that they have the better answers
rendering decades of painstaking legal and technical work redundant.

-- 
David Kastrup