GPL & Possible Derivative Work
Mike
If I were to study GPL'ed source in order to understand a protocol that
it implements, would I need to and if so how would I cite this in any
program I create which uses any knowledge gained?
Michael Spang
--
To UNSUBSCRIBE, email to debian-leg...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Måns Rullgård
> Hello all,
>
> If I were to study GPL'ed source in order to understand a protocol
> that it implements, would I need to and if so how would I cite this in
> any program I create which uses any knowledge gained?
Stating where you obtained the information is always a good idea.
IIUC, you are intending to write your own implementation of the
protocol, or perhaps write a client for a server. As long as you do
not copy any code, you will not be creating a derived work, and hence
will not be bound by the GPL in any way. There is, AFAIK, no dispute
about this.
IANAL, TINLA, etc.
--
Måns Rullgård
m...@inprovide.com
Arnoud Engelfriet
> Mike <mi...@midgard.no-ip.org> writes:
> > If I were to study GPL'ed source in order to understand a protocol
> > that it implements, would I need to and if so how would I cite this in
> > any program I create which uses any knowledge gained?
>
> Stating where you obtained the information is always a good idea.
> IIUC, you are intending to write your own implementation of the
> protocol, or perhaps write a client for a server. As long as you do
> not copy any code, you will not be creating a derived work, and hence
> will not be bound by the GPL in any way. There is, AFAIK, no dispute
> about this.
Usually the advice is to write your own code based on descriptive
information about the protocol, without looking at the original
implementation. In other words, use the RFC, not the code.
This avoids accusations about nonliteral copying.
Arnoud
--
Arnoud Engelfriet, Dutch patent attorney - Speaking only for myself
Patents, copyright and IPR explained for techies: http://www.iusmentis.com/
Mike
> Usually the advice is to write your own code based on descriptive
> information about the protocol, without looking at the original
> implementation. In other words, use the RFC, not the code.
> This avoids accusations about nonliteral copying.
>
> Arnoud
>
Too bad it's a closed source protocol. But I will give reverse
engineering it a try it might be interesting. It's a tiny protocol I
might just be able to figure it out. There might even be some unofficial
docs on the web somewhere.
Thanks for the tips,
Mike
Andrew Suffield
> Arnoud Engelfriet wrote:
> >Usually the advice is to write your own code based on descriptive
> >information about the protocol, without looking at the original
> >implementation. In other words, use the RFC, not the code.
> >This avoids accusations about nonliteral copying.
>
> engineering it a try it might be interesting. It's a tiny protocol I
> might just be able to figure it out. There might even be some unofficial
> docs on the web somewhere.
The best way to break derivation for stuff like this is to
reverse-engineer it and write a description of the protocol. Then
implement your own version using *only* the description. Never touch
both at once.
To be really robust, you must have different people doing the two
parts, but even with only one, following the discipline gives you a
solid defence against accusations of copying.
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |
Michael K. Edwards
This sort of reverse engineering to specification, followed by
cleanroom implementation, is primarily used to defend against
accusations of misappropriation of trade secrets. The reverse
engineering team is vetted to make sure that they have had no
privileged access to the target's knowledge going in, and the process
is documented to demonstrate that it followed procedures available to
any competitor. Hunting "unofficial" docs on the web is exactly the
kind of thing that you shouldn't be doing if the source code and
protocol are trade secrets.
If you don't have any contractual relationship to the vendor or any
information obtained through privileged access, then you don't have to
worry about trade secrets, just copyright. If the implementation is
closed source, and you're cloning its function, the burden is still on
you to demonstrate that you copied only what you absolutely had to.
Independently arriving at a very similar solution to the same problem
is not a very good defense, since you are obviously reverse
engineering a specific implementation.
If you are in a position to compare the two by decompiling the
original, you are obliged to make a reasonable effort to do so (in for
a dime, in for a dollar) and to diverge from the expressive content of
the original in pretty much every way possible while retaining
interoperability. See, for instance, the recent Lexmark case in the
Sixth Circuit, in which Static Control was permitted to copy the
entire Toner Loading Program verbatim, but only because they
demonstrated that its cryptographic checksum had to match in order to
interoperate.
The dissent in Lexmark is very well argued, and covers the history of
reverse engineering cases at appellate level in the US. Judge Feikens
felt that Static Control should have been obliged to work even harder
at the reverse engineering, spot a flag that could be used to turn off
the checksum operation, flip that flag and write their own Toner
Loading Program. That view did not prevail, but it's an indication of
the degree of thoroughness a judge expects from a reverse engineering
project's avoidance of unnecessary literal copying.
When you are talking about published source code, there is no trade
secret to be misappropriated. You can't really claim not to have had
access to the original source code, and there's no evidence that you
didn't read the source code other than your own word. The only
purpose of reverse engineering under those circumstances is to help
demonstrate that, where your code resembles the original, that
reflects functional necessity rather than plagiarism.
It's complete folly not to look at openly published source code if
you're trying to clone its function without infringing copyright. If
it comes to a court battle, you have to be able to demonstrate that
every bit of overlapping expressive content is a matter of engineering
necessity. Publishing the source code of the original raises the
burden of proof on the cloner, since it facilitates a good-faith
effort on the cloner's part to avoid plagiarism.
Cheers,
- Michael
(IANAL, TINLA)
Bruce Perens
>If you don't have any contractual relationship to the vendor or any
>information obtained through privileged access, then you don't have to
>worry about trade secrets, just copyright.
>
Michael,
Clean-room is an excellent strategy for avoiding copyright infringement.
It enables someone to write a functionally compatible program without
having seen the original. In an infringement case, it makes it entirely
plausable to the court that the writer never saw the original
implementation and was working only from the functional description.
I'm not clear why you didn't consider that.
Thanks
Bruce
Michael K. Edwards
> Clean-room is an excellent strategy for avoiding copyright infringement.
> It enables someone to write a functionally compatible program without
> having seen the original. In an infringement case, it makes it entirely
> plausable to the court that the writer never saw the original
> implementation and was working only from the functional description.
>
> I'm not clear why you didn't consider that.
Plausible isn't much help here. Courts mostly only ask "is it
plausible that the resemblances are coincidental" when evaluating
claims of copying of non-literal elements from a rejected screenplay,
film scenario, creature sketch, etc. into a fictional work (such as a
movie) made later. That sort of "constructive availability" test can
weaken a claim of infringement at the factual copying stage, but
usually only if it's demonstrably improbable that the later author
even knew what was in the work alleged to have been copied.
When there's no question that the new work was written with knowledge
of the original's existence and general content, all that a
"clean-room" technique can do is help substantiate the defense that
certain non-literal similarities are a matter of engineering necessity
in the course of a Computer Associates v. Altai type
abstraction-filtration-comparison test. It is my impression that
(under US law) literal similarities are handled the same whether or
not they went through a "specification" stage, and are generally OK
only when they are demonstrably inseparable from ideas, methods of
operation, or compatibility requirements. I cite various examples
below.
Note however that anti-reverse-engineering clauses are enforceable
(through a breach of contract claim), at least in negotiated
contracts, at least in some circuits; compare Bowers v. Baystate at
http://caselaw.lp.findlaw.com/data2/circs/Fed/011108v2.html . Note
that in that case the appeals court upheld the district court judge's
omission of damages for copyright infringement from the final
reckoning, on the grounds that awarding damages for both breach of the
anti-reverse-engineering clause and copyright infringement would
constitute double recovery.
Cheers,
- Michael
(IANAL, TINLA)
As far as copyright is concerned, reverse engineering is reliably a
protected fair use in the US, except in the rare case (like Atari v.
Nintendo) in which an otherwise successful defense of fair use for
reverse engineering purposes is weakened by skulduggery such as fraud
on the copyright office. And even in that case, the court ruled that
the actual quantity of literal copying exceeded engineering necessity.
The criterion for copyright infringement in a final product is the
amount of copied material and the extent to which affirmative defenses
like copyright license and fair use apply to the product itself, not
to the process by which it was written.
Reverse engineering does frequently come up in cases where copyright
infringement is among the claims; see, for instance, Sony v. Connectix
(in which Connectix successfully justified its extensive use of the
Sony BIOS in the course of creating its PlayStation Emulator, partly
because Sony didn't claim to have found actual copying into the
emulator's final form) and Alcatel v. DGI (the one at
http://laws.findlaw.com/5th/9711339cv0v2.html ; there's a whole
DSC/Alcatel saga), in which the entire gamut of causes of action came
up except for claims of literal copying into DGI's product. But
"improper means" of reverse engineering are generally a trade secret
consideration, with little effect on the evidence for copyright
infringement.
See also Bateman v. Mnemonics (at
http://www.law.emory.edu/11circuit/mar96/93-3234.ma2.html ; FindLaw's
copy appears to be mangled). The Bateman court vacated and remanded
the district court's judgment that copyright infringement had
occurred, partly because the jury had not been properly instructed
that compatibility requirements may justify literal copying. The
Eleventh Circuit said that it would be "an incorrect statement of the
law that interface specifications are not copyrightable as a matter of
law" but did "join [the 9th, 2nd, and 5th] circuits in finding that
external considerations such as compatibility may negate a finding of
infringement."
The Bateman court's ruling was not long after Lotus v. Borland was
affirmed by an equally divided court, and other circuits weren't in a
big hurry to follow the First as far as "not copyrightable as a matter
of law". However, the Sixth Circuit went very nearly this far in the
recent Lexmark case, writing (in the course of reversing the district
court's ruling): "When a work itself constitutes merely an idea,
process or method of operation, or when any discernible expression is
inseparable from the idea itself, or when external factors dictate the
form of expression, copyright protection does not extend to the work."
It has been reported that the Supreme Court denied certioriari on
Lexmark, making it a pretty strong precedent.
Bernhard R. Link
> On 6/17/05, Bruce Perens <br...@perens.com> wrote:
> > Clean-room is an excellent strategy for avoiding copyright infringement.
> > It enables someone to write a functionally compatible program without
> > having seen the original. In an infringement case, it makes it entirely
> > plausable to the court that the writer never saw the original
> > implementation and was working only from the functional description.
> >
> > I'm not clear why you didn't consider that.
>
> Plausible isn't much help here. Courts mostly only ask "is it
> plausible that the resemblances are coincidental" when evaluating
> claims of copying of non-literal elements from a rejected screenplay,
> film scenario, creature sketch, etc. into a fictional work (such as a
> movie) made later. That sort of "constructive availability" test can
> weaken a claim of infringement at the factual copying stage, but
> usually only if it's demonstrably improbable that the later author
> even knew what was in the work alleged to have been copied.
I do not know about you, but I prefer adhereing to the law than to
break it in a way you have the best chance of getting away.
As was stated before, proper clean room implementation makes it impossible
to have undeliverately copied something protected. With all the
specifications made you also get a good documentation of what actually
happened. Noone can force you to make it more 'different' to the orginal
(and even less to make less verbatim copies, because there are no
verbatim copies, only things ended up to be verbatimly the same).
The only possibility to attack this scheme it to persuade to court
you did not do so and lied and produced specifications and
documentations and the like to disguise the facts. It is not even
your word against someone else's word, but your word against someone
else's wild guessings.
Bernhard R. Link
Michael K. Edwards
> * Michael K. Edwards <m.k.e...@gmail.com> [050618 01:30]:
> > plausible that the resemblances are coincidental" when evaluating
> > claims of copying of non-literal elements from a rejected screenplay,
> > film scenario, creature sketch, etc. into a fictional work (such as a
> > movie) made later. That sort of "constructive availability" test can
> > weaken a claim of infringement at the factual copying stage, but
> > usually only if it's demonstrably improbable that the later author
> > even knew what was in the work alleged to have been copied.
>
> I do not know about you, but I prefer adhereing to the law than to
> break it in a way you have the best chance of getting away.
> As was stated before, proper clean room implementation makes it impossible
> to have undeliverately copied something protected. With all the
> specifications made you also get a good documentation of what actually
> happened. Noone can force you to make it more 'different' to the orginal
> (and even less to make less verbatim copies, because there are no
> verbatim copies, only things ended up to be verbatimly the same).
>
> The only possibility to attack this scheme it to persuade to court
> you did not do so and lied and produced specifications and
> documentations and the like to disguise the facts. It is not even
> your word against someone else's word, but your word against someone
> else's wild guessings.
The difficulty is that specification-followed-by-reimplementation
doesn't have any effect on whether you have copied expression from the
original. Copying is judged on the facts of resemblance, not on the
process by which it happened -- except in the quite rare case
(generally a work of fiction) in which the author of the later work
demonstrably didn't know much about the original and the resemblances
are credibly coincidental. That simply doesn't hold water when
reverse engineering is in play.
As I wrote, the procedure you describe may be of some use in
bolstering the affirmative defense that the resemblances were dictated
by ideas, methods of operation, and compatibility requirements. But
the "clean-room" technique was largely conceived as a defense against
claims of trade secret misappropriation, not against copyright
infringement. Protocol cloning _is_ a deliberate effort to copy the
ideas and methods of operation without running afoul of copyright in
the expressive content of the original, and should proceed accordingly
-- which means producing evidence, not that resemblances are
coincidental, but that they are _necessary_ for interoperation. And
that usually means comparing the two at implementation level and
purging any resemblances that you can possibly reimplement
differently.
Sean Kellogg
Shocking as it may sound, I agree with everything Michael has said here.
Cleanroom implementation is not a good defense against copyright
infringement. If you want to write code and release it under a license under
the GPL, then don't look at the GPL'ed code. Otherwise you are copying
something... and while its possible that that "something" isn't itself
copyrightable material, chances are good that it is AND it really goes
against the whole "meaning and intent" of the GPL.
-Sean
--
Sean Kellogg
2nd Year - University of Washington School of Law
GPSS Senator - Student Bar Association
Editor-at-Large - National ACS Blog [http://www.acsblog.org]
w: http://probonogeek.blogspot.com
So, let go
...Jump in
...Oh well, what you waiting for?
...it's all right
...'Cause there's beauty in the breakdown
Glenn Maynard
> Shocking as it may sound, I agree with everything Michael has said here.
> Cleanroom implementation is not a good defense against copyright
> infringement. If you want to write code and release it under a license under
> the GPL, then don't look at the GPL'ed code. Otherwise you are copying
> something... and while its possible that that "something" isn't itself
> copyrightable material, chances are good that it is AND it really goes
> against the whole "meaning and intent" of the GPL.
This seems to boil down to "once you've looked at GPL code that does
something, you're forever banned from writing anything similar to it
under another license". I hope I'm not the only one that finds that
questionable. And no, it doesn't go against the intent of the GPL;
the GPL is intended to lock a piece of software into itself, not whole
programmers.
I've seen a whole lot of GPL'd code. It's awfully hard to make money
writing GPL'd code. Should I be looking for a new career?
--
Glenn Maynard
Michael K. Edwards
> On Sat, Jun 18, 2005 at 06:11:45PM -0700, Sean Kellogg wrote:
> > Shocking as it may sound, I agree with everything Michael has said here.
> > Cleanroom implementation is not a good defense against copyright
> > infringement. If you want to write code and release it under a license under
> > the GPL, then don't look at the GPL'ed code. Otherwise you are copying
> > something... and while its possible that that "something" isn't itself
> > copyrightable material, chances are good that it is AND it really goes
> > against the whole "meaning and intent" of the GPL.
If Sean is saying that you can't look at GPL'ed code and then write
something non-GPL with similar functionality, I respectfully disagree.
You are, however, under an obligation (moral and legal) to take
considerable pains not to copy expressive content that is not either
inseparable from the ideas and methods of operation (doctrine of
merger) or necessary for interoperability purposes. That's
substantially the same standard of plagiarism avoidance that applied
in my sixth grade history course -- if you take some notes on an index
card, keep track of their origin, and verify afterwards that you
didn't even inadvertently copy the original's phrasing -- and applies
about the same to any _published_ material irrespective of what
license may be attached. (Trade secrets are a different story.)
> This seems to boil down to "once you've looked at GPL code that does
> something, you're forever banned from writing anything similar to it
> under another license". I hope I'm not the only one that finds that
> questionable. And no, it doesn't go against the intent of the GPL;
> the GPL is intended to lock a piece of software into itself, not whole
> programmers.
The GPL-as-an-instrument-of-law ensures that an implementation deeded
into the commons remains there as it evolves, and that forks can take
place when the current maintainers go off in a direction that doesn't
meet other people's needs. The GPL-as-an-instrument-of-subversion is
another story, and some people would have you believe that its intent
is indeed to divide the world into free-software altruists and
benighted greedheads who mustn't be permitted to build on any
functionality provided by or knowledge obtained from a GPL work.
Choose your worldview, I suppose.
> I've seen a whole lot of GPL'd code. It's awfully hard to make money
> writing GPL'd code. Should I be looking for a new career?
It's not so hard to make money writing code for a specialized purpose
(such as a scalability test harness for a telecoms company's product)
and offering GPL terms as a "square deal" between consultant (who can
reuse the code elsewhere) and client (who can hire someone else for
the next proposal cycle). It's not even that hard to wear a "free
software" face for PR purposes and still monopolize the market for
tech support, customization services, and license to embed within a
more complex product. What looks hard from where I'm sitting is to
make the former scale beyond three guys in a garage, or to retain your
soul in the course of the latter.
Cheers,
- Michael
(IANAL, IANADD)
Glenn Maynard
> > I've seen a whole lot of GPL'd code. It's awfully hard to make money
> > writing GPL'd code. Should I be looking for a new career?
>
> It's not so hard to make money writing code for a specialized purpose
> (such as a scalability test harness for a telecoms company's product)
> and offering GPL terms as a "square deal" between consultant (who can
It's possible to make money writing GPL'd code--it's just harder. (That's
just a simple practical matter: it can be hard to get a job writing code
at all, much less one that allows you to use the GPL; it's hard to make
money selling software, much less with the GPL's restrictions.) Much of
my own work is released under the MIT license; it's clearly possible.
The point was simply that if, after looking at huge reams of GPL code (which
many free software programmers do, over the course of time), you couldn't
write anything closely related to what you'd seen except under the GPL,
you'd have a pretty serious problem. I just don't think that's the case;
I don't claim to know exactly where the boundary is for a "derived work" in
these cases, but I don't think someone who's worked on the Linux kernel
is branded for life, forbidden from working on a non-GPL kernel.
> reuse the code elsewhere) and client (who can hire someone else for
> the next proposal cycle). It's not even that hard to wear a "free
> software" face for PR purposes and still monopolize the market for
> tech support, customization services, and license to embed within a
> more complex product. What looks hard from where I'm sitting is to
> make the former scale beyond three guys in a garage, or to retain your
> soul in the course of the latter.
Most of that is hard to do freely. In practice, it's possible to forbid
embedding in certain environments, since many embedded environments are
practically GPL-incompatible.
(Well, "embed in a more complex product" can be done with patch clauses,
which can make code reuse next to impossible. Incidentally, that's one
place where I disagree with the DFSG; I just don't believe patch clauses
are free.)
Sean Kellogg
> On Sat, Jun 18, 2005 at 06:11:45PM -0700, Sean Kellogg wrote:
> > Shocking as it may sound, I agree with everything Michael has said here.
> > Cleanroom implementation is not a good defense against copyright
> > infringement. If you want to write code and release it under a license
> > under the GPL, then don't look at the GPL'ed code. Otherwise you are
> > copying something... and while its possible that that "something" isn't
> > itself copyrightable material, chances are good that it is AND it really
> > goes against the whole "meaning and intent" of the GPL.
>
> This seems to boil down to "once you've looked at GPL code that does
> something, you're forever banned from writing anything similar to it
> under another license". I hope I'm not the only one that finds that
> questionable. And no, it doesn't go against the intent of the GPL;
> the GPL is intended to lock a piece of software into itself, not whole
> programmers.
>
> I've seen a whole lot of GPL'd code. It's awfully hard to make money
> writing GPL'd code. Should I be looking for a new career?
Look at all the GPL'ed code you want... but if you intend to look at code,
attempt to cleanroom the code YOURSELF, and then re-implement it, as the
original poster suggested, then I think you've got a problem.
But it raises a unique problem from a legal test perspective. Non-literal
infringement generally requires two things A) similarity, B) access. In the
case of proprietary code, B is often missing... but how does the test work
in a FOSS setting where everyone has access? Is the only legal issue
similarity, or does the public availability alter the analysis?
-Sean
--
Sean Kellogg
2nd Year - University of Washington School of Law
GPSS Senator - Student Bar Association
Editor-at-Large - National ACS Blog [http://www.acsblog.org]
c: 206.498.8207 e: skel...@u.washington.edu
Arnoud Engelfriet
> But it raises a unique problem from a legal test perspective. Non-literal
> infringement generally requires two things A) similarity, B) access. In the
> case of proprietary code, B is often missing... but how does the test work
> in a FOSS setting where everyone has access? Is the only legal issue
> similarity, or does the public availability alter the analysis?
There was a US case in the 1970s where George Harrison was
convicted for copyright infringement of a song that was
on popular radio when he was writing his own song. The level
of public availability seems comparable.
Larry Rosen wrote an article discussing this case, although
he uses the example to warn against engaging in any MS Shared Source
initiative.
Linkname: lj8
URL: http://www.rosenlaw.com/lj8.htm
The case itself is at
Linkname: ABKCO Music v. Harrisongs Music
URL: http://digital-law-online.info/cases/221PQ490.htm
Arnoud
--
Arnoud Engelfriet, Dutch patent attorney - Speaking only for myself
Patents, copyright and IPR explained for techies: http://www.iusmentis.com/