🚀 go-pugleaf

In article <371l4f$608@nntp1.u.washington.edu> tzs@u.washington.edu (Tim Smith) writes:

   If we apply the arguments FSF used last year during the gmp/RIPEN
   debate, then if the only implementation of that language is GPL'ed,
   you could only distribute source code written in that language
   under GPL, because leaving it to the end user to obtain the compiler
   is equivalent to shipping the compiler yourself if there is only
   one compiler available.  As soon as someone else implements the
   language (no matter how badly), it will then be OK to ship source
   in that language under non-GPL licenses.

The above paragraph is correct only if you replace "arguments FSF used"
with "arguments [Tim Smith] repeatedly puts in the FSF's mouth".  The
FSF has never made claims of the sort he makes above -- if it has,
I'd like to see them posted verbatim (and they'd better say "if the
only implementation of that _language_"...).

After all, there are almost certainly features gcc offers that extend
the capabilities accessible by C source-code programmers (say, nested
functions, or label variables, &c, or any combination of those features),
yet there is no evidence that the FSF has in any way threatened to
force under the GPL any distribution of code it perceives to have
made use of those unique capabilities in its source.

Furthermore, I'm not even aware of any cases where the FSF has
tried to claim the GPL applies to distributions containing GNU EMACS
byte-compiled files.  This is a different case, since though GNU EMACS
surely comprises a unique implementation of a language, EMACS is
an interpreter, and hence is far more likely to be arguable as
being _part_ of any "program" distributed in the form of GNU EMACS
source or "object" (byte-compiled) code than is a compiler such as
GNU CC.  Maybe nobody's distributed just byte-compiled files, but I'd
find that hard to believe, and rather suspect the FSF simply considers
them to constitute (potentially) a program that, whereas it runs "under"
EMACS, is not inherently a "program including portions derived from
EMACS".  If I'm right about these observations, then clearly the FSF
isn't asserting exactly the same sort of "interface copyright" a few
zealots claim it has, since surely the "space" between a byte-compiled
file and the EMACS code that processes it can be called an "interface",
and GNU EMACS is the only product that implements that interface!
(And surely the FSF is at least as interested in protecting the GPL
with regards to GNU EMACS as it is with regards to gmp, and surely
it would _love_, philosophically speaking, for all code written in
GNU EMACS LISP to inherently be GPLed...but it seems not to have
attempt to make such claims.)

All this isn't surprising, because not only does the FSF probably realize
it has no legal standing in such cases -- I believe it has stated that
the output of a GPLed compiler is not inherently GPLed, and I suspect
it would make or has made a similar statement regarding the output of
GNU EMACS' byte-compiler -- it also does not believe languages or
interfaces should be copyrightable, as is evident to anyone who has been
paying attention and using their heads.

(Things would probably be quite different if, say, the output of the EMACS
byte compiler was an executable containing all of EMACS itself, i.e.,
if it was an application generator instead.  Then the FSF might well
argue that the "program" included EMACS, and hence was GPLed, even
if the distribution avoided including any GPLed code by leaving it
up to the user to generate the app in an automated fashion from a
shrouded, proprietary EMACS LISP source file using a separately
obtained, or aggregated, copy of GNU EMACS.)

(However, this area does get pretty gray when it comes to making finer
and finer cuts into the definition of a "program", as illustrated by
things like dynamically linked libraries, easily modified operating
systems, and so on -- and these problems of defining "program" are not
limited to the GPL, but are and certainly will be affecting the entire
software industry as monolothic applications give way to larger
collections of smaller, independent units of code.  Certainly
"geeks" can argue endlessly that what an ordinary programmer might
call a set of procedures, or a library, can actually be viewed as
a compiler (it converts an input stream to an output stream, depending
on your definitions), an interpreter (like EMACS, it is code that sits
in memory and is invoked only when needed to process "code" written
in some "language"), or a toaster oven (again, for arbitrary definitions
of "bread", "heat", and "browned").  But the definitions courts
are interested in (or should be) are the legal ones, which can include
generous amounts of "intent", as in "did the authors of gmp intend
it as an interpreter, a compiler, or a library?" and "in similar
cases, such as distributions of similar end-products, where are the
distinctions between 'program', 'operating environment', 'library',
'interpreter', 'compiler', and so on?".)

   Note that when only the GPL'ed compiler exists, distributing *binaries*
   compiled with that compiler would be OK, because distributing binaries does
   not require the end user to obtain the GPL'ed compiler, and is so not
   equivalent to shipping the compiler.

   In other words, using FSF's interpretation of GPL and of copyright law, we
   have a situation where distributing a binary of a program under a restrictive
   license is OK, but distributing source is not!

Actually, if you distribute source code X in language Y for which
only GPL-licensed compiler Z exists, and if X plus whatever other
parts (such as libraries) it uses, other than Y and Z, constitutes
a program, then none of the above interpretations would be true.
Yet that is presumably the case Tim Smith is talking about.  (I can't
just say "the above is not true", since then he, or someone else,
will come up with a case that purportedly uses the acceptable scenario
but in fact constitutes a subterfuge in the legal sense and claim
I've just said the FSF wouldn't claim the GPL applied in such a
case.  In fact, that's the reason for many of these otherwise
unnecessary parenthetical notes -- it is a proven fact that the crowd
yelling "FSF claims interface copyright" will take just about any
attempt to clarify or explain what the FSF position actually and
twist it around to suit their paranoid view, just as Tim Smith did
at the very top of this post when he used the word "language" in a
context where the FSF, nor do I believe any of its supporters such
as myself, has ever done so.  Once again, with feeling: I believe
the FSF has explicitly disclaimed copyrights on interfaces, and
that it has [or would if asked] do so on languages.  I've said
the former many times, and nobody has posted anything to the contrary,
aside from saying "well, yes, they've done that but then they've
contradicted themsevles by doing XYZZY" where XYZZY constitutes
an intentional misinterpretation and impugning of the FSF's
motives.)

(Note that, in the "meat" of the above paragraph, I'm taking the view
that X no more includes Y than writing a Fortran compiler in C++ makes
the language the compiler implements object-oriented...that is, such
a compiler isn't "derived from C++", it just happens to be "written in
C++", and "generated by a C++ compiler", not "derived" from it.)

All of this is because the GPL refers to _programs_, not to Tim Smith's
incorrect interpretation of the FSF's position concerning the GPL.
If you're ever confused about these endless dumb discussions about
the FSF supposedly claiming an interface copyright, just read the
GPL and keep asking yourself "what constitutes the program" and
answer it in a normal, ordinary, common-sense, and _nonreductionist_
manner.  You'll see that the interface isn't the issue at all,
anymore than fingerpainting with blood on someone's sidewalk is
the issue in California's homicide laws (though in both cases they
can be evidence of something that _is_ the issue).

For example, if you write x.c, and compile it with gcc, and it produces
x, then it is not necessarily the case that x has any GPL-derived code
in it.  And the same thing would apply if you compiled x.Y with Z, this
mythical compiler that is the only one to compile programs written in
language Y, unless Z was not a compiler in the classic sense of the
term.

After all, if the program the end user runs contains no code derived
from GPLed code, which can be the case if Z is a compiler such as GCC,
then the source code of the program is not subject to the GPL, nor is
the binary.  (Fortunately, the GPL is incredibly plain about this.
Just Read It.  And remember that "program" != "any arbitrary collection
of source or object code", to understand why gmp/RIPEM was a problem
but "Z < x.Y > x" would probably not be.)

The gmp/RIPEM case was a totally different situation, where the program
contained code under conflicting licenses (GPL and a more typical
proprietary one, which also involved patents).

A more interesting case would be if, say, bison (and its GPLed skeleton,
which it inserts in its output) was the _only_ implementation of its
kind.  That is, if there was no such thing as yacc &c, would the FSF
complain if someone distributed a package containing the following:

1.  Object files and a "shrouded" .y (yacc/bison input) file

2.  No sources for the items in #1

3.  A non-sharing license (i.e. something that conflicts with the GPL)
    that covers the items in #1

4.  An automated shell script (or makefile) that uses bison in conjunction
    with standard tools to build a final executable from the items in #1
    that serves as the end-user's program

5.  Either the GNU bison package, merely aggregated with items 1-4,
    or a pointer to places where the end user can get it

Would the FSF claim that items 1 and 4 constituted a subterfuge by which
the intended end result, a program containing GPLed code (the derivation
of the GPLed bison skeleton), would have been distributed in their
stead had no license restrictions existed, and thus claim the distribution
fell under the GPL?

I suspect it might.  The bison skeleton is fairly trivial, I'm told,
so it might not bother with that particular case, but if that was true
in this scenario, the distributor would probably back down and write
a replacement skeleton before the FSF backed down.  After all, going
back to _reality_, plenty of people _have_ already come up with alternatives
to bison for at least this reason (not wanting to have every program
that is built with it fall under the GPL) instead of using the
above scenario as an alternative and risk fighting the FSF in court.

Ultimately, the interesting thing about all these gems posted by
Tim Smith is that not only are they _theoretically_ and _legally_
wrong, but in every real case that has been found, the FSF's
interpretation has won out.  That is, at least to my knowledge,
nobody has taken the approach of using subterfuges such as the above
to effectively release proprietary versions of popular GPLed
products such as GCC, GNU EMACS, or Linux, and stuck with said
approach despite FSF objections.  I suppose that might be because
_real_ IP lawyers, not net.lawyers like Tim Smith, are _paid_ for
their opinions, and recognize that the FSF _does_ have at least
an adequate legal leg to stand on, despite having publically declaimed
any and all interface copyrights on things like gmp.  And, as we
know from hard-won experience and observation, given the amount of $$
that could be made releasing effectively proprietary versions of
certain GPLed software, there should certainly be plenty of $$ to pay
lawyers to agree with Tim Smith's views and be willing to go to court
to defend them.  Maybe it is only a matter of time before that happens,
but it does not seemed to have happened yet.

(The FSF has had to make some clarifications, I believe, regarding
situations that appear to some to be similar in structure to the
gmp/RIPEM case but different in outcome.  Without knowing the details
of them, just remembering some cursory impressions I've had at the
times I've seen such clarifications, it seems to me these could be
viewed as clarifications of the FSF's answer to the question "where
does the program end and the operating environment begin?".  I've
never seen any such clarifications that seemed to me to be cases
of the FSF "losing" a battle over the issue of phantom distributions
of GPLed code.)
--

James Craig Burley, Software Craftsperson    burley@gnu.ai.mit.edu