emacs-devel
[Top][All Lists]
Advanced

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

Re: Contributing LLVM.org patches to gud.el


From: David Kastrup
Subject: Re: Contributing LLVM.org patches to gud.el
Date: Mon, 09 Feb 2015 12:21:13 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Richard Stallman <address@hidden> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > If we try to close down every cooperation with non-GNU free software, we
>   > are sacrificing our goals for the sake of our temples.
>
> I agree.  But is anyone proposing that?

GCC's approach to plugins took years to do exactly in order not to
interface with software not under the GPL.  A generic dynamic library
loading facility to Emacs has been in discussion and vetoed for decades.
Somewhat amusingly, the only working run-time dynamic library loading
that I know of in Emacs is the loading of image libraries (free ones, of
course) under Windows.  At the current point of time we are seeing about
a year of roadblocks on trying to get Emacs and GCC to communicate about
various issues.  While the more recent batch of blocking LLVM
cooperation (which is non-GNU free software) has started with blocking
LLVM on the grounds that GCC should go first, the subsequent attempts to
integrate GCC first have been blocked on grounds that this would open
too many paths to interoperating with LLVM or proprietary compilers.

So yes: you _are_ very much sacrificing the interoperation of GNU
software on the grounds that it would also enable the interoperation
with software that is either unfree or "too free".  Whether or not this
is "proposed", it is being done.

As long as our only weapon is copyright, we cannot block interoperation
except by blocking all interfacing.  If we want to block interoperation
selectively, the only meaningful way to do that is to start hacking
patent law in a similar manner to how the GPL hacked copyright law:
collecting patents and providing public licenses.  Patents reach beyond
interoperation.  Which is part of what makes software patents a bad idea
in the first place.

At any rate: crippling GNU until we reduce open-ended interoperation to
the degree where it becomes infeasible without touching
copyright-propagating parts is a strategy for obsolescence.

As long as our sole weapon is copyright, we need to focus on using it in
a manner where it hurts us less than our opponents.

Part of doing that is to have feasible strategies, and easy and
effective rules that can be applied by project managers with confidence.
The GNU project is far too large, and interoperation far too important
that it is even feasible to route all the decision-making through the
"Richard oracle" with unknown outcome.  Top-level decisions are a scarce
resource, so the project cannot afford this process frequently.

Partly one gets the impression that you think if you wait long enough,
the problem will go away.  But what rather tends to go away is the
window of opportunity.

We did our part in making the creation of LLVM attractive to a diverse
set of people because we decided that catering to their causes would
have been disruptive to our own goals.  The rise of LLVM or other
compiler technologies was an _expected_ consequence of our actions:
compiler technology is not an inaccessible art, so it was clear that
alternatives to GCC would get developed and maintained eventually.

What happens now is burning down the barn after the mule has bolted.
And it's not like we didn't open the door, beat it and yell for it to go
away.

More by accident than anything else I have been in some "IT planning for
startups" talk on a conference.  The speaker did a lot to explain how
import contingency plans were when things went wrong.  But what he also
said: "the worst mistake a manager can commit is to be unprepared
catering for the eventuality of success".  If you are not prepared for
dealing with success, where is the point in even starting?

So we worked on making GCC a bad choice for proprietary vendors.  What
do they do?  They manage to unite an industry-spanning coalition of
different parties including academia into creating a free software
compiler framework.  Free to the degree that we could just take it, slap
the GPL on it and distribute our own version of it (assuming we were
prepared to dealing with pissing everybody off in the process).

So what's our reaction to our and GCC's role in causing a large-scale
industry cooperation creating a free compiler framework?

Panic.  We are not prepared to deal with people doing on their own terms
what we have fought to happen for decades.  So now we try to fight those
in our midst who want to make use of what we have fought for.

And since LLVM is relicensable as GPL if anybody bothered to, the only
effective means to "fight" LLVM is by necessity effective in fighting
GPLed software in just the same manner.

It seems sort of pointless to be fighting our spoils because they were
given to us in the wrong kind of ceremony.

-- 
David Kastrup



reply via email to

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