Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2014/01/26/llvm.html

[ Please keep in mind in reading this post that while both FSF and
Conservancy are mentioned, and
that I have leadership roles at both organizations, these opinions on
ebb.org, as always, are my own and
don’t necessarily reflect the view of FSF and/or Conservancy. ]

Most people know I’m a fan of RMS‘
writing about Free Software and I agree with most (but not all) of his
beliefs about software freedom politics and strategy. I was delighted to
read RMS’ post
about LLVM on the GCC mailing list on Friday. It’s clear and concise,
and, as usual, I agree with most (but not all) of it, and I encourage
people to read it. Meanwhile, upon reading comments on LWN on
this post, I felt the need to add a few points to the discussion.

Firstly, I’m troubled to see so many developers, including
GCC developers,
conflating various social troubles in the GCC community with the choice of
license. I think it’s impossible to deny that culturally, the GCC
community faces challenges, like any community that has lasted for so long.
Indeed, there’s a long political history of GCC that even predates my
earliest involvement with the Free Software community (even though I’m now
considered an old-timer in Free Software in part because I played a small
role — as a young, inexperienced FSF
volunteer — in helping negotiate the EGCS
fork back into the GCC mainline).

But none of these politics really relate to GCC’s license. The copyleft
was about ensuring that there were never proprietary improvements to the
compiler, and AFAIK no GCC developers ever wanted that. In fact, GCC was
ultimately the first major enforcement test of the GPL, and ironically that
test sent us on the trajectory that led to the current situation.

Specifically, as I’ve spoken about
in my
many talks
on
GPL compliance, the
earliest publicly discussed major GPL violation was by NeXT computing when
Steve Jobs attempted and failed (thanks to RMS’ GPL enforcement work) to
make the Objective C
front-end to GCC proprietary. Everything for everyone involved would
have gone quite differently if that enforcement effort had failed.

As it stands, copyleft was upheld and worked. For years, until quite
recently (in context of the history of computing, anyway), Apple itself
used and relied on the Free Software GCC as its primary and preferred
Objective C compiler, because of that enforcement against NeXT so
long ago. But, that occurrence also likely solidified Jobs’ irrational
hatred of copyleft and software freedom, and Apple was on a mission to find
an alternative compiler — but writing a compiler is difficult and
takes time.

Meanwhile, I should point out that copyleft advocates sometimes conflate
issues in analyzing the situation with LLVM. I believe most LLVM
developers when they say that they don’t like proprietary software and that
they want to encourage software freedom. I really think they do. And, for
all of us, copyleft
isn’t a religion, or even a belief — it’s
a strategy to maximize software freedom, and no one
(AFAICT) has
said it’s the only viable strategy to do that. It’s quite
possible the strategy of LLVM developers of changing the APIs quickly to
thwart proprietarization might work. I really doubt it, though, and here’s
why:

I’ll concede that LLVM was started with the best of academic intentions to
make better compiler technology and share it freely. (I’ve discussed this
issue at some length
with Chris Lattner
directly, and I believe he actually is someone who wants more software
freedom in the world, even if he disagrees with copyleft as a strategy.)
IMO, though, the problem we face is exploitation by various anti-copyleft,
software-freedom-unfriendly companies that seek to remove every copyleft
component from any software stack. Their reasons for pursuing that goal may or may not
be rational, but its collateral damage has already become clear: it’s
possible today to license proprietary improvements to LLVM that aren’t
released as Free Software. I predict this will become more common,
notwithstanding any technical efforts of LLVM developers to thwart it.
(Consider, by way of historical
example, that
proprietary combined works with Apache
web server continue to this very day, despite Apache developers’ decades of
we’ll break APIs, so don’t keep your stuff
proprietary claims.)

Copyleft is always a trade-off between software freedom and adoption. I
don’t admonish people for picking the adoption side over the software
freedom side, but I do think as a community we should be honest with
ourselves that copyleft remains the best strategy to
prevent proprietary improvements and forks and no other strategy has been
as successful in reaching that goal. And, those who don’t pick copyleft have priorities other than
software freedom ranked higher in their goals.

As a penultimate point, I’ll reiterate something
that Joe Buck pointed out on the
LWN thread: a lot of effort was put in to creating a licensing solution
that solved the copyleft concerns of GCC plugins. FSF’s worry for more
than a decade (reaching back into the late 1990s) was that a GCC plugin
architecture would allow writing to an output file GCC’s intermediate
representation, which would, in turn, allow a wholly separate program to
optimize the software by reading and writing that file format, and thus
circumvent the protections of copyleft.
The GCC
Runtime Library Exception (GCC RTL Exception) is (in my biased opinion)
an innovative licensing solution that solves the problem — the ironic
outcome: you are only permitted to perform proprietary optimization with
GCC on GPL’d software, but not on proprietary software.

The problem was that the GCC RTL

Exception came too late. While I led the GCC RTL Exception drafting
process, I don’t take the blame for delays. In fact, I fought for nearly a
year to prioritize the work when FSF’s outside law firm was focused on
other priorities and ignored my calls for urgency. I finally convinced
everyone, but the work got done far too late. (IMO, it should have been
timed for release in parallel with GPLv3
in June 2007.)

Finally, I want to reiterate that copyleft is a strategy, not a moral
principle. I respect the LLVM developers’ decision to use a
different strategy for software freedom, even if it isn’t my preferred
strategy. Indeed, I respect it so much that I supported
Conservancy’s offer
of membership to LLVM in Software Freedom Conservancy. I still hope
the LLVM developers will take Conservancy up on this offer. I think that
regardless of a project’s preferred strategy for software freedom —
copyleft or non-copyleft — that it’s important for the developers
to have a not-for-profit charity as a gathering place for developers,
separate from their for-profit employer affiliations.

Undue for-profit corporate influence is the biggest problem that software
freedom faces today. Indeed, I don’t know a single developer in our
community who likes to see their work proprietarized. Developers,
generally speaking, want to share their code with other developers. It’s
lawyers and business people with dollar signs in their eyes who want to
make proprietary software. Those people sometimes convince developers to make
trade-offs (which I don’t agree with myself) to work on proprietary
software (— usually in exchange for funding some of their work time
on upstream Free Software). Meanwhile, those for-profit-corporate folks
frequently spread lies and half-truths about the copyleft side of the
community — in an effort to convince developers that their Free Software
projects “won’t survive” if those developers don’t follow the
exact plan The Company proposes. I’ve experienced these
manipulations myself — for example, in April 2013, a prominent corporate lawyer with
an interest in LLVM told me to my face that his company would continue
spreading false rumors that I’d use LLVM’s membership in
Conservancy to push the LLVM developers toward copyleft, despite
my public
statements to the contrary. (Again, for the record, I have no such
intention and I’d be delighted to help LLVM be led in a non-profit home by its rightful
developer leaders, whichever Open Source and Free Software license they
chose.)

In short, the biggest threat to the future of software has always been
for-profit companies who wish to maximize profits by exploiting the code, developers and users while
limiting their software freedom. Such companies try every trick in pursuit of
that goal. As such, I prefer copyleft as a strategy. However, I don’t
necessarily admonish those who pick a different strategy. The reason that I
encourage membership of non-copylefted projects in Conservancy (and other
501(c)(3) charities) is to give those projects the benefits of a non-profit
home that maximize software freedom using the project’s chosen strategy,
whatever it may be.