Article View: comp.lang.misc
Article #7150Re: Why you should not use Tcl
From: Craig Burley
Date: Tue, 11 Oct 1994 12:51
Date: Tue, 11 Oct 1994 12:51
296 lines
18914 bytes
18914 bytes
In article <37d76u$101@nntp1.u.washington.edu> tzs@u.washington.edu (Tim Smith) writes:
Craig Burley <burley@gnu.ai.mit.edu> wrote:
>my posts saying that. But changing nouns, such as pretending my saying
>"the GPL covers entire programs" is the same as saying "the GPL covers
>entire languages", doesn't count.
Ah, perhaps I now see where the confusion arises. I'm not making an argument
about GPL. I'm making an argument about copyright law. Let's take it from
the top. The basis of GPL is copyright law. What I mean by that is if
you write a program and distribute it, and if doing so would not violate
the copyright of some GPL'ed code, then your code does not have to be
GPL'ed.
Put another way, the way one becomes bound to GPL is by doing something
that would infringe the copyright of some GPL'ed code if one did not have
permission to do that thing.
Good so far.
Now, go back to gmp/RIPEM. FSF was claiming that the code distributed
had to be distributed under GPL. For this claim to be valid, they must
have been alleging a copyright violation somewhere. The violation is
not in the RIPEM code itself, for it did not contain GPL'ed code.
(To prove copyright violation, you have to show substantial similarity
between the code alleged to have been copied and the alleged infringing
code, and there was no such similarity in the RIPEM source and the gmp
source, unless FSF could somehow copyright the names and calling sequences
of functions, and I think we've all agreed that they cannot and they do
not claim to have such a copyright, right?).
Uh, no, and this is where I become totally bewildered and suggest that
perhaps you carefully _read_ what mib, myself, and others supporting
the FSF's position (or, in my case, at least _explaining_ its basis
in copyright law) and this time _pay attention_. The explanation given
from these sources is simple, clear and direct:
gmp/RIPEM violated the GPL because it constituted a distribution of
a _program_ that contained GPLed code (RIPEM+RSAREF+gmp). The fact
that technical means were used to avoid the necessity for distributing
gmp itself is considered by the FSF to be basically irrelevant, since
the clear purpose of the distribution was to distribute a _complete_
program, and the difference to the end user between what was distributed
and what would have been distributed had there been no licensing
problems (the RSAREF license being the problem here) was essentially
nil (i.e. the mere invocation of a command such as "make" or "patch").
So the gmp/RIPEM distribution included a "phantom distribution", as I
call it, of gmp (heck, that's why we _all_ call it by some name including
the phrase "gmp" -- we all recognize that the distribution _virtually_
included gmp). In fact, the "mere aggregation" clause of the GPL says
that gmp itself _could_ have bee included without changing the situation
(after all, if you distribute source code X and it doesn't infringe
anyone's copyright, as you claim is the case with gmp/RIPEM, then how
could the GPL prevent distributing a mere aggregation of X + gmp??).
So, where is the infringement? One possibility is what is called
"contributory infringement". The idea is that if you do something that
enables someone else to infringe a copyright, you can be liable for
the infringement. For that to work, what the end user does has to be
an infringement. The problem here is that that in terms of infringing
the copyright of X, there is no difference between (1) an end user obtaining
Y, modifying Y to work with X, and linking together X and Y, and (2) someone
else modifying Y to work with X, giving that to the end user, and the end
user linking X and Y.
That is something over which you and many IP lawyers disagree. There
_is_ a difference in the creative input of (1) and (2) by the end user;
in fact, (2) is much more similar to (3) simply shipping the X+Y executable
(in terms of end-user involvement), and will become even more so as
network ease-of-use improves, than (2) is to (1). _Any_ end user
could do (2); only those with specific expertise, making particular
creative decisions (however trivial), could do (1), and the audience
is vastly different.
If you claim that's wrong, then answer this question: if (1) and (2) are
basically the same in terms of infringing a copyright, then you must
claim they are the same in terms of creation of non-distributed works
(since copyright is a matter of artistic creation _plus_ its distribution;
e.g. you and I can each independently "create" our own versions of a song
like Boston's "More Than A Feeling" for our own use, but cannot distribute
them to each other). And, if so, what do you think the gmp/RIPEM distributor
would have done had there been _no_ copyright/licensing issues -- decide
that since (1) and (2) are so similar, he might as well do (1) (i.e.
not bother distributing the patches that made RIPEM use gmp since it is
so trivial for _all_ users to create them each on their own)? I claim
that, instead, he'd have gone in the opposite direction and simply
(3) distributed the complete source-code set, perhaps even executables for
popular machines.
If (1) does not infringe the copyright, then neither
does (2) (unless the mods to Y include actually physically copying part of
X into Y). Neither GPL nor copyright law make any distinction here.
This is one of the reasons contrbutory infringement won't apply.
Again, you're arguing as if these points are completely agreed upon.
And clearly the FSF, its IP lawyers, and many other paid IP lawyers
disagree with you. That seems to be inconceivable to you, since you
not only disagree with them, you pretend as though there's no disagreement
on this issue, and thus conclude (publically and with a motive that,
at this point, I'm beginning to question, or else I must question your
ability to read, comprehend, and retain laboriously-and-repeatedly
posted explanations such as this) that the FSF must be resting on
some _other_ basis for its objection to gmp/RIPEM, like the mythical
"interface copyright" and now the even more insidious hold you're
claiming the FSF might claim on _any and all_ code written in a language
implemented only by GPLed software (a blatant error, since there _are_
such languages and the FSF has never claimed such a GPL hold on code
written in them, as I pointed out earlier -- yet you continue to argue
this error).
(If GPL included something like "you may link GPL'ed code with code you
write for your own use, but you cannot link it with code you obtain from
third parties unless that code is GPL'ed or is normally distributed with
the operating system", then the end user doing (2) would be violating
GPL, and a contributory infringement claim against the person who modifies
and distributes Y to work with X might fly).
Perhaps you're right, but I think we have case law that shows that such
a restriction would fly only if the licensee, in this case the end user
doing the _creative_ work in linking GPLed code, signed a copy of the
license prior to, and as a condition of receipt of, the GPLed code.
The distinction here is that the GPL applies only to _distribution_ of
programs, and does not (and, in the opinion of many IP lawyers at this
point, cannot, due to its architecture as an unsigned document)
restrict private use of the work. That means a person can make
full creative use of the work as long as he or she does not distribute
it. The FSF essentially claims that "creative use" does not include
merely running some canned script written by someone else, but that
in such a case the "creative use" was made by _that_ someone else, and
that distribution of the canned script _could_ be viewed as a subterfuge
for distributing the resulting derived work (in source or binary form) if
certain other conditions are present indicating that a subterfuge was
intended, rather than coincidental compatibility.
Copyright law does recognize another form of indirect infringement.
That is where one does something to make someone else under their direct
control infringe a copyright. Since the RIPEM people weren't forcing
anyone to build RIPEM with gmp, that won't apply.
Again, you're wrong, and the RIPEM people _were_ forcing people to build
RIPEM with gmp to get one of the _advertised_ benefits of their distribution.
That is, they were "forced" in the same sense that a person is "forced"
to load an executable into memory so as to run the program -- obviously
nobody was holding a gun to their head. But the copyright infringement
is alleged to have occurred when the RIPEM distribution was made, not
when the user did the link or loaded the executable into memory or any
such later time, because the distribution of the RIPEM package,
due to the present of other supporting conditions, was in effect a
distribution of a GPL-code-laden program, and the GPL talks about _programs_,
not just arbitrary snippets of code. (If the GPL applied only to
arbitrary snippets of code, it'd be just about useless -- it could
be trivially gotten around, allowing full-fledged proprietary
program to be released containing as much as 99% GPLed code. But
this is just an argument for people who support the overall goals of
the GPL to not spend time trying to weakening it in public debate and
perhaps encourage someone to challenge it by releasing such a program --
if that happens, and the courts rule that the GPL does apply only to
snippets of GPLed source code and not to entire programs despite its
clear language, then, well, the GPL becomes just about useless, and
there's nothing we can do about it at that point, except maybe weaken
it further so the mildly burdensome steps of having the user do the
link can be avoided to make things more convenient for everyone using
all those proprietary packages containined GPLed code.)
That leaves us with direct infringement. Now, perhaps I misunderstood,
but what I thought you and FSF were claiming was that if A is only useful
with B, and someone distributes A without B, telling the distributees to
obtain B themselves and combine A and B, then legally the person will be
treated as having distributed B with A. When A == RIPEM and B == gmp,
then the RIPEM distribution in effect included gmp, and so was a *direct*
copyright infringement, and since gmp is GPL'ed, was only legal if
RIPEM was GPL'ed. If, however, there is a drop-in substitute for B
available, then the distribution of A is no longer an implicit
distribution of B, and so A can be distributed without being put
under GPL.
You got some of the fascinating technical detail of the above argument
right, but you continue to miss the big picture.
If this is what was claimed, then I don't see anything that limits B to
being libraries. This should work for any copyrighted code. If B is
a copyrighted compiler, and there is no other compiler for that language,
and A is code written in that language, it seems to me that the same
arguments could be used by the owner of the copyright on the compiler.
I see nothing in the Copyright Act or the case law or the leading treatises
that indicates that there is a distinction between libraries and compilers
as far as copyright law goes. FSF has only made this argument with respect
to libraries, as far as I know, and I seriously doubt that they would make
it with respect to a language, but they are not the only people who write
compilers.
Okay, the big picture is this: gmp/RIPEM was a _program_ containing GPLed
code (gmp). Right? (The distribution also contain a RIPEM without gmp,
but that's irrelevant.) The complete program, as source or binary, was
not distributed because of licensing problems with RSAREF (and these
remain even without the GPL licensing problems). Instead, a technical
means for, in essence, "magically" linking in gmp was contrived so users
wouldn't have to make this decision and take the creative steps on their
own.
Now, how do we know the original gmp/RIPEM was a program containing
gmp, and not something else? Among other things, here are some key
points:
1. Clearly the intention was for the end user to end up with a program
containing RIPEM, RSAREF, and some other code, that did a good job
at what it did. (That is, the distribution was not just a bunch
of snippets of unrelated text, and nobody should be arguing that it
was, since copyright law doesn't perform reductions like that.)
2. Looking at the interfacing in the program _minus_ "some other code"
_for_ that "some other code" is a means of identifying possible
candidates for what that "some other code" is intended, or expected,
to be.
3. At the time of the FSF's objection, gmp was the only possible
candidate for that "some other code", because it was the only
package that matched the interface expected by the RIPEM+RSAREF
code.
4. gmp's interface was not considered sufficiently "obvious" for _any_
package of its type for the RIPEM+RSAREF distribution to be considered
a coincidental result of someone writing an incomplete program in
the form of source code and then distributing that in the hopes
that others would complete it (and, in fact, either documentation
in the RIPEM+RSAREF package, or statements by the distributor, made
it clear that gmp was the intended "some other code").
Now, how can you apply _all_ of the above points to a situation where,
instead of a part of an incomplete program such as gmp, you substitute
a compiler such as gcc? The answer is, you can't. The GPL would no
more apply to the output of a GPLed compiler where no other compiler for
that language existed than it would apply to the output of gcc. That's
because the end result, the _program_, does not contain any code
derived from the compiler (in a legal sense). So the very first point
above, #1, does not apply, and there is therefore no need to apply
the remaining _evidentiary_ points to support it, nor is there any
need to go ranting and raving about all the other things those
_evidentiary_ points, in _isolation_, could be successfully applied
to (like your mythical "language copyright virus" case).
I will write to you no longer on this topic. Object to it, disagree
with it, imply that somehow I and a few FSF people are making up an
issue out of whole cloth with which no well-respected IP lawyer would
agree (and hand-wave the ones who have agreed, like NeXT's lawyers),
and I'll finally have a reason to create a killfile -- to put you into
it. I have explained this reasoning _directly_ to you before, and
there's no question you've read my explanation and, clearly, others
as well (like those of mib, who, unlike mine, are short, sweet, and
to the point), so if, after this, you ever pretend to not understand
that the essential point behind the FSF's claim about gmp/RIPEM was
_not_ some kind of "interface copyright" but rather what I call
a case of "phantom distribution", and try to imply the FSF would
make similar claims (e.g. that distributing a program compiled by
a GNU compiler was a subterfuge for distributing a program _containing_
the GNU compiler, which is what your "language copyright virus" claim amounted
to), then I'll assume you are either excessively paranoid regarding the
FSF or simply lacking in reading, comprehension, and/or long-term
memory skills, and that other things you have to say about which
I've understood less and heretofore assumed you had something worthwhile
to teach me must therefore be equally suspect.
(Perhaps before you post more about this to USENET, you could spend
a little of your own $$ and hire an experienced IP lawyer to review
the GPL along with all of the FSF postings, even including mine if
you want, and see if he or she can explain to you what the legal
ramifications are, even if he or she disagrees that they'd stand
up in court?)
A final note: if a case like gmp/RIPEM ever comes up in court, and the
court rules that a distribution like RIPEM, being merely in the form
of a partial program plus patch files that apply to other, nondistributed
code, does not infringe the copyright of any other code (e.g. RSAREF
or gmp) -- i.e. if it rules that there is no "phantom distribution"
as I call it -- then I believe the case will be lost right there.
I see no way for some other avenue to be found for the FSF to keep
the GPL in effect for such programs. Mythical inventions by others
like "interface copyrights" will neither be invoked nor, if they are
(and they cannot be by the FSF), be successful. The "phantom distribution"
claim is, IMO, the one and only critical point on which the FSF's
legal objections to distributions like gmp/RIPEM hinge.
(Interestingly, if the FSF were to lose that point, all other source
code distributed freely would have pretty much the same _effective_
status as GPLed code, including code distributed "freely as long
as not for commercial purposes" -- in that one could easily distribute
commercial, proprietary packages incorporating such code by simply
leaving the user to do the link. The free-software community has
_lots_ to lose, in terms of trying to keep the playing field level
between "software-hoarding proprietary vendors" and "openly-sharing
free-software distributors" if the "phantom distribution" claim is
proven legally unworkable.)
--
James Craig Burley, Software Craftsperson burley@gnu.ai.mit.edu
Technical Details
Message-ID:
<BURLEY.94Oct11085114@churchy.gnu.ai.mit.edu>Path:
arc1-ca.pugleaf.net!bga.com!news.sprintlink.net!howland.reston.ans.net!spool.mu.edu!bloom-beacon.mit.edu!ai-lab!life.ai.mit.edu!burleyReferences:
<9409232314.AA29957@mole.gnu.ai.mit.edu> <BURLEY.94Oct8022815@churchy.gnu.ai.mit.edu> <377lfj$iqj@nntp1.u.washington.edu> <BURLEY.94Oct10154145@churchy.gnu.ai.mit.edu> <37d76u$101@nntp1.u.washington.edu>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f891f,f52b5c9f448476db X-Google-Attributes: gidf891f,public X-Google-Thread: 1025b4,ec95c6b7e531a9a8 X-Google-Attributes: gid1025b4,public X-Google-ArrivalTime: 1994-10-11 19:10:06 PST Path: arc1-ca.pugleaf.net!bga.com!news.sprintlink.net!howland.reston.ans.net!spool.mu.edu!bloom-beacon.mit.edu!ai-lab!life.ai.mit.edu!burley From: burley@gnu.ai.mit.edu (Craig Burley) Newsgroups: comp.lang.misc,gnu.misc.discuss Subject: Re: Why you should not use Tcl Date: 11 Oct 94 12:51:14 GMT Organization: Free Software Foundation 545 Tech Square Cambridge, MA 02139 Lines: 296 Message-ID: <BURLEY.94Oct11085114@churchy.gnu.ai.mit.edu> References: <9409232314.AA29957@mole.gnu.ai.mit.edu> <BURLEY.94Oct8022815@churchy.gnu.ai.mit.edu> <377lfj$iqj@nntp1.u.washington.edu> <BURLEY.94Oct10154145@churchy.gnu.ai.mit.edu> <37d76u$101@nntp1.u.washington.edu> NNTP-Posting-Host: churchy.gnu.ai.mit.edu In-reply-to: tzs@u.washington.edu's message of 11 Oct 1994 05:18:22 GMT