Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Can Technical Tricks Circumvent the GPL?

3 views
Skip to first unread message

Richard Stallman

unread,
Jan 12, 1993, 9:18:55 AM1/12/93
to
Can Technical Tricks Circumvent the GPL?

People often speculate about technical procedures that might
circumvent the GPL in some way. For example, they may suggest a
modified version could be cut artificially into two pieces, one free
and one proprietary, that are called two independent programs.

This kind of scheme is based on the premise that the legal system
operates in the fashion of a stupid computer program, and that
superficial manipulations of the way files are grouped and labeled
would fool it. While the legal system often does seem stupid and
easily fooled in comparison with common sense, the FSF's lawyer told
us that it would not be stupid about this.

The lawyer said that such a scheme would fail because a judge would
regard it as a subterfuge. The judge would conclude that the two
parts are really one program in disguise, and go on from there.

Our lawyer also said that a judge would tend to be harsh toward anyone
perceived to be trying a subterfuge.

As hackers, we tend to become absorbed in the technical details of the
proposed schemes, and not pay enough attention to the wider context.
The possibility of a loophole in the GPL might be interesting
abstractly in its own right, but its main importance is in connection
with whether the GPL does what it is supposed to do: ensure that
modified versions of a program are free.

Hackers also tend to model the GPL based on concepts used for security
systems, assuming that any puncture makes it collapse like a soap
bubble. But business doesn't move like a gas; more like molasses. If
a real, legally sustainable loophole were found, its effect would be
diminished by the inconvenience of using it. This is likely to be
significant, and would dissuade most companies from trying. Thus, the
GPL would still retain most of its effect.

Experience shows that companies are not eager to try to circumvent the
GPL. If they think their plans might conflict with the GPL, they
generally contact the FSF to make sure there is no conflict.

The most fundamental point--the "bottom line"--is that as a practical
matter the GPL does achieve its goal. Improvements to our software
are actually made free, and no amount of speculation can override this
fact. Apparently, any loopholes are sufficiently inconvenient that
they are not much of a factor.

Mikhail Zeleny

unread,
Jan 13, 1993, 2:26:40 AM1/13/93
to
As always, my exceedingly shy interlocutor is receiving a copy of this
article in the mail.

In article <930113001...@mole.gnu.ai.mit.edu>
r...@gnu.ai.mit.edu (Richard Stallman) writes:


I propose a thought experiment.

Let us suppose that I am now working on a way to compel FSF to face a
choice between accepting the unpleasant fact of immediate release of
every successive version of its software into the public domain, or
suing my own charitable outfit for patent infringement. Let us further
suppose that I have at my disposal the professional services of several
talented and dedicated people, who support me in this campaign. What I
want to produce, as my final programming project, a fitting swan song
for fifteen years of sporadic drudgery, is a C code reinterpreter, -- a
program that would produce at least an equally readable and useable, yet
everywhere syntactically different, synonymous version of any C program.
Each new release of GNU would be passed through my filter, and released
to the public on the Berkeley terms, copyrighted in my name, and
accompanied by the source code for the converter, along with the full
story of its origin.

Note that, in principle, I could use my supposed program, which I would
be designing as an independently usable tool, without ever looking at
the GNU source code, confirming sufficient divergence by using the diff
utility, and so avoiding any claims of copyright infringement. The
reason software companies cannot use this technique has to do with the
fact that their legal protection is partly based on trade secrecy, and
partly -- on software patents. But the truly piquant part of this
wholly fictional scenario, is that the Free Software Foundation is
effectively the private charity of one Richard M. Stallman, a hacker
extraordinaire, known mainly for his ingenious editing macros, but also
desperately wishing to be known as the intrepid champion of software
freedom, and a staunch opponent of any form of algorithm or data
structure protection, such as is opposed by the League for Programming
Freedom, of which he is, not altogether coincidentally, the head cheese.

Recall that my intention is to compel the FSF to change its hypocritical
software hoarding ways; although I would prefer this to occur through
free cooperation, the same goal can be attained by forcing it to file a
lawsuit that would automatically discredit its claim to freedom and good
will. By changing the text of GNU everywhere, without once looking at
it, I would have produced a functionally equivalent program, wholly
exempt from the FSF copyright, or the terms and conditions of the GPL.
On the other hand, my algorithms and data structures, not to mention the
"look and feel" characteristics, would be absolutely identical to those
employed by GNU. Now, in our imaginary situation, Stallman would have
to choose between suing me, or tolerating me. Should he complacently
choose the latter, he would have to resign himself to the worthlessness
of the GPL; on the other hand, by using the legal recourse, he would
automatically undermine the credibility of his own LPF.

Heads -- I win, tails -- you lose.

cordially,
mikhail zel...@husc.harvard.edu
"Les beaulx bastisseurs nouveaulx de pierres mortes ne sont escriptz
en mon livre de vie. Je ne bastis que pierres vives: ce sont hommes."

Dave Sill

unread,
Jan 13, 1993, 9:14:33 AM1/13/93
to
In article <1993Jan13.0...@husc3.harvard.edu>, zel...@husc10.harvard.edu (Mikhail Zeleny) writes:
>
>In article <930113001...@mole.gnu.ai.mit.edu>
>r...@gnu.ai.mit.edu (Richard Stallman) writes:
>
>[Uninterrupted, unabridged copy of the entire article deleted.]

Please don't do this. It's a waste of bandwidth. If anyone wants to refer to
RMS's article, they can find the original.

>... What I


>want to produce, as my final programming project, a fitting swan song
>for fifteen years of sporadic drudgery, is a C code reinterpreter, -- a
>program that would produce at least an equally readable and useable, yet
>everywhere syntactically different, synonymous version of any C program.
>Each new release of GNU would be passed through my filter, and released
>to the public on the Berkeley terms, copyrighted in my name, and
>accompanied by the source code for the converter, along with the full
>story of its origin.

I believe that would violate the GPL, but I don't care enough about it to quote
chapter and verse. I personally wouldn't have anything to with them, and I
suspect few people would.

>Note that, in principle, I could use my supposed program, which I would
>be designing as an independently usable tool, without ever looking at
>the GNU source code, confirming sufficient divergence by using the diff
>utility, and so avoiding any claims of copyright infringement.

I think copyright goes deeper than "diff", and, as for the argument that not
looking at the GNU source strengthens your claim of not violating copyright,
consider the case of a simple filter that trivially reformats code and renames
variables.

>The
>reason software companies cannot use this technique has to do with the
>fact that their legal protection is partly based on trade secrecy, and
>partly -- on software patents.

And partly on copyright, and partly on morality.

>Recall that my intention is to compel the FSF to change its hypocritical
>software hoarding ways; although I would prefer this to occur through
>free cooperation, the same goal can be attained by forcing it to file a
>lawsuit that would automatically discredit its claim to freedom and good
>will.

This would blow up in your face. Contrary to what you apparently believe, the
public is pleased with the FSF, and isn't interested in coercing it into making
its software available under different terms. Sure, there's a small minority
of programmers that would like to see that happen, but there a very small
group--and motivated mostly by a selfish desire to take advantage of the GNU
code against the will of the copyright owner. In such a situation, it's pretty
clear who the public would assign the white and black hats to.

>... Now, in our imaginary situation, Stallman would have


>to choose between suing me, or tolerating me. Should he complacently
>choose the latter, he would have to resign himself to the worthlessness
>of the GPL;

Why? The availability of non-GPL'd derivatives of GNU programs wouldn't be the
same as removing the GPL restrictions from GNU code. Your translated programs
would be slightly more useful than binaries. Nobody would be maintaining them
and nobody would understand how they work. They'd be totally unsupported and
totally dependent upon FSF releases for bug fixes and updates.

>on the other hand, by using the legal recourse, he would
>automatically undermine the credibility of his own LPF.

Wrong.

>Heads -- I win, tails -- you lose.

Wrong too. Of course, this is all just a though experiment. I suggest you
whup up that reinterpreter and see how it goes.

--
Dave Sill (d...@ornl.gov) Computers should work the way beginners
Martin Marietta Energy Systems expect them to, and one day they will.
Workstation Support -- Ted Nelson

Steve Simmons

unread,
Jan 13, 1993, 7:25:47 AM1/13/93
to
zel...@husc10.harvard.edu (Mikhail Zeleny) writes:

>I propose a thought experiment.

Gee, from a thoughtless guy yet.

>Note that, in principle, I could use my supposed program, which I would
>be designing as an independently usable tool, without ever looking at
>the GNU source code, confirming sufficient divergence by using the diff
>utility, and so avoiding any claims of copyright infringement. The
>reason software companies cannot use this technique has to do with the
>fact that their legal protection is partly based on trade secrecy, and
>partly -- on software patents.

Thoughtless indeed. Go see a lawyer who specialized in copyright and
ask him the meaning of "derived work". Try actually reading the header
of fsf-copyright files, where is says "copyright", not "patented" or
"trade secret".

Want a simple counterexample? Invent a mechanical translator, translate
a copywritten book from English to French and back, then sell the result
as if it weren't copyright. Keep repeating the words "derived work",
"derived work", "derived work". Keep remembering the the method of
derivation isn't relevant.
--
"When Dexter's on the Internet, | "Make me taste like things I've never
can Hell be far behind?" | tasted before!" Mr Peanut to Candied
s...@lokkur.dexter.mi.us | Bergen in `Caramel Knowledge'

Kenneth Herron

unread,
Jan 13, 1993, 10:41:49 AM1/13/93
to
zel...@husc10.harvard.edu (Mikhail Zeleny) writes:

>What I want to produce...is a C code reinterpreter, -- a


>program that would produce at least an equally readable and useable, yet
>everywhere syntactically different, synonymous version of any C program.
>Each new release of GNU would be passed through my filter, and released
>to the public on the Berkeley terms, copyrighted in my name, and

>accompanied by the source code for the converter...

Derivative work. Gnu retains the copyright. Case closed. >Whack<
--
Kenneth Herron khe...@ms.uky.edu
University of Kentucky +1 606 257 2975
Dept. of Mathematics "Your ball goes over them, it sails off the edge into a
huge cauldren of fire-breathing dragons." "And they call this a par three?"

Mikhail Zeleny

unread,
Jan 13, 1993, 12:02:29 PM1/13/93
to
In article <1993Jan13....@ms.uky.edu>
khe...@ms.uky.edu (Kenneth Herron) writes:

>zel...@husc10.harvard.edu (Mikhail Zeleny) writes:

>>What I want to produce...is a C code reinterpreter, -- a
>>program that would produce at least an equally readable and useable, yet
>>everywhere syntactically different, synonymous version of any C program.
>>Each new release of GNU would be passed through my filter, and released
>>to the public on the Berkeley terms, copyrighted in my name, and
>>accompanied by the source code for the converter...

>Derivative work. Gnu retains the copyright. Case closed. >Whack<

Maybe so. But observe that everything, but the algorithms and data
structures, would have been changed. In the absence of patent
protection, what would protect the invariant parts of the software?

>--
>Kenneth Herron khe...@ms.uky.edu
>University of Kentucky +1 606 257 2975
>Dept. of Mathematics "Your ball goes over them, it sails off the edge into a
>huge cauldren of fire-breathing dragons." "And they call this a par three?"

cordially,
mikhail zel...@husc.harvard.edu
"Le cul des femmes est monotone comme l'esprit des hommes."

Mikhail Zeleny

unread,
Jan 13, 1993, 12:11:30 PM1/13/93
to
In article <1993Jan13.1...@lokkur.dexter.mi.us>
s...@lokkur.dexter.mi.us (Steve Simmons) writes:

>zel...@husc10.harvard.edu (Mikhail Zeleny) writes:

>>I propose a thought experiment.

>Gee, from a thoughtless guy yet.

I see you are trying to engage in meaningful dialogue.

>>Note that, in principle, I could use my supposed program, which I would
>>be designing as an independently usable tool, without ever looking at
>>the GNU source code, confirming sufficient divergence by using the diff
>>utility, and so avoiding any claims of copyright infringement. The
>>reason software companies cannot use this technique has to do with the
>>fact that their legal protection is partly based on trade secrecy, and
>>partly -- on software patents.

>Thoughtless indeed. Go see a lawyer who specialized in copyright and
>ask him the meaning of "derived work". Try actually reading the header
>of fsf-copyright files, where is says "copyright", not "patented" or
>"trade secret".

My point is precisely that GNU is not protected by trade secret or
patents. Perhaps you could explain the meaning of "derived work", as
it unambiguously applies to my imaginary case.

>Want a simple counterexample? Invent a mechanical translator, translate
>a copywritten book from English to French and back, then sell the result
>as if it weren't copyright. Keep repeating the words "derived work",
>"derived work", "derived work". Keep remembering the the method of
>derivation isn't relevant.

The salient feature of my example, is that paraphrase of software is
effectively tractable, unlike natural language translation. As for
the method of derivation being irrelevant, tell it to the Japanese.

>--
>"When Dexter's on the Internet, | "Make me taste like things I've never
> can Hell be far behind?" | tasted before!" Mr Peanut to Candied
> s...@lokkur.dexter.mi.us | Bergen in `Caramel Knowledge'

cordially,

John F. Woods

unread,
Jan 13, 1993, 2:04:51 PM1/13/93
to
[I don't get talk.philosophy.misc; redirect followups there if you want]

zel...@husc10.harvard.edu (Mikhail Zeleny) writes:
>In article <1993Jan13.1...@lokkur.dexter.mi.us>
>s...@lokkur.dexter.mi.us (Steve Simmons) writes:
>>Go see a lawyer who specialized in copyright and
>>ask him the meaning of "derived work".
>My point is precisely that GNU is not protected by trade secret or
>patents. Perhaps you could explain the meaning of "derived work", as
>it unambiguously applies to my imaginary case.

Your mechanical translator -> translates <- the work into "another" language
which happens to be identical to the original language ;-). Translation is
already covered by copyright law; if you don't know that, please read up on
current copyright law before going any further. If anything, the fact that
the translation is mechanical probably reduces the copyright interest in
the resulting work by the "translator", since no creativity *in the translation
process* will have been involved -- perhaps a court would declare that the
copyright to your translated work was owned *solely* by FSF, an even worse
situation (from your viewpoint) than if you had sat down with a printed copy
of GNU true.c (or whatever) and typed in a new version while reading it.

Writing an abstract English description of the functioning of the program (as
long as it isn't "put ten into variable foo; call printf with arguments..." or
something equally trivial) and then writing a new program from that description
gets you around copyright, of course (the "clean room" technique, of course,
uses separate teams to read and write to avoid having one person's memory
accidentally duplicate code from memory, rather than from necessity). Of
course, if you had a way of automating that process, with a genuine abstract
form in the middle, you'd be wasting your time using it to rewrite GNU
software, especially since the second half of it is the Holy Grail of
automatic program generators...

It is exactly GNU's eschewal of patent or trade secret protection that enables
you to sit down and use their code as a poorly-written textbook[1]; it is,
of course, the difficulty of studying the entire corpus of EMACS (say) and
then saying "OK, now that I know everything there is to know about how EMACS
works, how would *I* write a twenty-megabyte editor?" which ensures that this
is largely a non-issue in the real world ;-).

[1] As English prose goes, it ain't "A Tale of Two Cities", is it?

Mikhail Zeleny

unread,
Jan 14, 1993, 2:06:19 AM1/14/93
to
In article <20...@ksr.com>
j...@ksr.com (John F. Woods) writes:

>[I don't get talk.philosophy.misc; redirect followups there if you want]

Yes, I heard about your problem. Done.

>zel...@husc10.harvard.edu (Mikhail Zeleny) writes:

>>In article <1993Jan13.1...@lokkur.dexter.mi.us>
>>s...@lokkur.dexter.mi.us (Steve Simmons) writes:

SS:


>>>Go see a lawyer who specialized in copyright and
>>>ask him the meaning of "derived work".

MZ:


>>My point is precisely that GNU is not protected by trade secret or
>>patents. Perhaps you could explain the meaning of "derived work", as
>>it unambiguously applies to my imaginary case.

JFW:


>Your mechanical translator -> translates <- the work into "another" language
>which happens to be identical to the original language ;-). Translation is
>already covered by copyright law; if you don't know that, please read up on
>current copyright law before going any further. If anything, the fact that
>the translation is mechanical probably reduces the copyright interest in
>the resulting work by the "translator", since no creativity *in the translation
>process* will have been involved -- perhaps a court would declare that the
>copyright to your translated work was owned *solely* by FSF, an even worse
>situation (from your viewpoint) than if you had sat down with a printed copy
>of GNU true.c (or whatever) and typed in a new version while reading it.

This is a good point. However, I am confused about the extent of
copyright protection of translations, -- how much of this is due to
the US law, as opposed to the Berne convention, which does not cover
software? More importantly, it seems to me that copyright protection
on translation could not be the same for software, as it is for texts
produced for human consumption, inasmuch as such identity would
obviate the perceived need for separate algorithm and data structure
patents.

JFW:


>Writing an abstract English description of the functioning of the program (as
>long as it isn't "put ten into variable foo; call printf with arguments..." or
>something equally trivial) and then writing a new program from that description
>gets you around copyright, of course (the "clean room" technique, of course,
>uses separate teams to read and write to avoid having one person's memory
>accidentally duplicate code from memory, rather than from necessity). Of
>course, if you had a way of automating that process, with a genuine abstract
>form in the middle, you'd be wasting your time using it to rewrite GNU
>software, especially since the second half of it is the Holy Grail of
>automatic program generators...

Here I may have to disagree. The key question is, just what sort of
abstraction level is required to defeat the copyright legislation; it
is not altogether clear that the said level would have to be high
enough to parallel the problem of automatic program generation.

JFW:


>It is exactly GNU's eschewal of patent or trade secret protection that enables
>you to sit down and use their code as a poorly-written textbook[1]; it is,
>of course, the difficulty of studying the entire corpus of EMACS (say) and
>then saying "OK, now that I know everything there is to know about how EMACS
>works, how would *I* write a twenty-megabyte editor?" which ensures that this
>is largely a non-issue in the real world ;-).

Well, I just can't help wondering how far that liberty goes. Recall
that my conjecture was that automatically producing an optimized,
readable paraphrase, which left only the algorithms and data
structures undisturbed, was well within the present-day technological
capacities. Your "clean room" parallel makes me think that, from a
legal standpoint, it would suffice to automatically translate
everything into an _ad hoc_, sufficiently detailed algorithm and data
structure specification language, and then automatically reimplement
the program. How about it?

JFW:


>[1] As English prose goes, it ain't "A Tale of Two Cities", is it?

Church once noted that _Principia Mathematica_, no less than Milton's
_Paradise Lost_, is part of the English language. I doubt that the
same could be said about Emacs. If all computers were rendered
permanently inoperable by an electromagnetic pulse of WWIII, only the
opus of Whitehead and Russell would retain its cognitive value.

Give my regards to Mike Cherepov.

Danny Thomas

unread,
Jan 15, 1993, 4:59:08 AM1/15/93
to
In article <1993Jan14.0...@husc3.harvard.edu> Mikhail Zeleny,

zel...@husc10.harvard.edu writes:
>Here I may have to disagree. The key question is, just what sort of
>abstraction level is required to defeat the copyright legislation; it
>is not altogether clear that the said level would have to be high
>enough to parallel the problem of automatic program generation.
my Noddy-level understanding of copyright was that it revolves around
authorship, a creative process. I believe it would be possible for
identical works to be copyrightable by two individuals if separate
authorship could be proven; not an easy task. Normally a lack a
difference between two works can buttress the argument for one work to be
a derivation of another, but it is a murky area. How many notes have to
differ in music? how many words in literature? Could the claimed author
have experienced the other work? How much of the similarity could be
explained by common forms in the mode of expression, eg chord
progressions in blues music?
If my understanding of copyright being based on creative authorship
is correct then no _mechanical_ form of translation, no matter how subtle
or clever, can circumvent copyright. Human language translation is
interesting precisely because it does involve a creative (human)
component. According to this perspective, a judicial decision could be
based on whether the translation was considered creative which is what
Mikhail was asking here. I would argue that the translation counts as a
derived work unless the program tools can generate code from an abstract
specification, instead of from a specific coding. Feed in buggy source
and thats what youll get out (though it might be clever enough to
correct some classes of bugs). Creativity also implies the ability to ask
for changes and I dont think I could instruct the translator please add
the DCTEncode compression filter to GhostScript. Thats why I think the
question really does require the level of automatic program generation.
Apart from the legal question, *my feeling* is that the proposal to
circumvent copyright by translation is ethically unsound.

cheers,
Danny Thomas

0 new messages