!20050315 Critique of "Open Source Licensing" book by Larry Rosen
==
Across the book, Rosen states at least one thing right: open source licenses (and they are licenses, not contracts) rest completely on copyright. Licenses like BSD avoid the copyright problem by dedicating whatever may be copyrightable to the public. Some quotes on copyright:
"Open source is built upon a foundation of intellectual property
law, particularly COPYRIGHT law." (page xx)
"Open source software always starts with one or more original
authors and their original works of authorship. COPYRIGHT
law describes an original work in the following broad terms
..." (page 19)
"Even if the contract [view of GPL] fails, a bare license
remains, and that license can be enforced under COPYRIGHT
law - with all the limitations on such enforcement actions
described earlier - or it can be revoked." (page 66)
"Thus are the first three exclusive rights of a COPYRIGHT
owner from 17 U.S.C. 106 introduced [in the GPL]." (page 125)
"The GPL relies on an entirely different set of legal principles,
based on COPYRIGHT law rather than contract law." (page 138)
"All open source licenses rely, at heart, upon the COPYRIGHT
law, as the GPL says in its section 5." (page 139)
It is the implications of this strong reliance on copyright that Rosen's book fails. First, like many IP lawyers, he ignores the growing overlap of patents and copyrights:
"Expressions are subject to copyright law; ideas are subject to
patent law." (page 15)
MISLEADING. First, expressions are also protectable by design patents, for example, user interface designs which are an element of open source projects. Design patents should be mentioned as an alternative. Second, "artistic" expressions are being protected in utility patent claims as articles of manufacture. Software "expressions", e.g., specific algorithms and data structures, are protected in patent claims. Finally, between substantial similarity, Whelanisms and adaptations/derivatives, copyright law for software is wrongly providing narrow idea protection.
"Finally, after much debate, in 1980 Congress decided that
software should be copyrightable, ...." (page 17)
FALSE, if by "decided" he means that they voted on a bill signed by the President. In 1980, Congress added the definition of a computer program to section 101 of the copyright laws (an unethical definition for not using "process"). But Congress did not say in section 101 that such computer programs are literary, or in section 102a that computer programs are one class of copyrightable works (see the next quote). He should have quoted the bible of copyright law, Nimmer on Copyright, that says that computer program copyright is "tacitly assumed" to be a law because of Congress' ongoing failure to vote on copyright for computer programs. All open source books should mention this serious concern of Nimmer, especially if they are familiar with the BCIA.
Having got it write with the reliance of open source licenses on copyright, the book starts running into trouble:
"Copyright law describes an original work in the following
broad terms:
Copyright protection subsists ... in original works
of authorship fixed in any tangible medium of
expression, now known or later developed, from
which they can be perceived, reproduced, or otherwise
communicated, either directly or with the aid of a
machine or device ...." (17 U.S.C. 102)
HIGHLY MISLEADING, EXTREMELY SLOPPY. There is no statute 17 U.S.C. 102. What Rosen is quoting is part of 17 U.S.C. 102(a). What Rosen NEVER quotes anywhere in the book is a statute he never explicitly names in his book (and lay readers won't expect because the '(a)' is deleted):
In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, REGARDLESS OF THE FORM in which it is described, explained, illustrated, or embodied in such work. 17 U.S.C. 102(b)
Not mentioning 102(b) is INEXCUSABLE for a statute so troubling to the foundation of the copyright that GPL rests on.
For example, are those open source computer programs, "regardless" of the "form" of how they are "described/explained" by Java "methods (of operation)", UNCOPYRIGHTABLE? One of the dirty secrets of the copyright world is this nasty phrase "regardless of form".
Worse, the '....' from his 102(a) quote represents the minimal list of types of expression (e.g., music, sculpture, pantomime, movies) for which copyrights are possible. The list is short enough to be included in the quote, unless you don't want to have to explain why "computer program" is not on the list because of Congress' refusal to add "computer program" somewhere in 102(a).
"The arrangement and organization of the collection of individual
modules are often the most original aspects of a software program."
(Page 27)
And therefore, in some circuits, the most uncopyrightable aspects of open source computer programs. What he is coyly alluding to here is what the law refers to as the "structure, sequence and organization" (SSO) of a computer program, for which a) some circuit courts allow to be copyrightable - the unscientific followers of Whelan, b) some circuit courts don't allow to be copyrightable (the Altai courts), and c) the Copyright Office, which in 1989 issued a circular saying it won't register SSO. And there is a good reason not to allow SSO to be copyrighted - structure, sequence and organization are all features of functionality and systems, and thus utilitarian features statutorily covered only by patent claims. Sloppy to not mention the controversy of SSO's "metaphysics".
"A patent differs from a copyright in a fundamental way: A
copyright prevents a third party from copying or modifying
the original work, but a patent restricts everyone who
uses the patented invention whether the invention has been
copied or not. Even someone who independently creates ..."
(page 30)
Again, sloppy. Copyright law has a formal independent creation defense. But for open source users, the defense vanishes (something Linus Torvald hasn't had explained to him) - indeed, the whole point of open source is to make the world one large DEPENDENT CREATION phenomena. The growingly dubious independent creation defense rests on the historic inability to find out about existing works (as opposed to the complete historic prior art mastery of the patent world, as possible in Posner-land), which for open source software in the Internet era is a fallacy.
"It is a complex and enormously expensive task to find all
relevant patent claims and analyze them to determine whether
you have the right to make, use, sell or offer for sale, or
import your software." (page 33)
Compared to what in the copyright world? First, finding relevant patent claims using free online patent databases is comparable to finding out about relevant open source codes and their copyrights using sourceforge. Patents don't have the problem of chain of (undocumented) authorship of copyrights. But WORSE, analyzing software copyright infringement is orders more difficult without the equivalent of patent claims. It is not until many months (and dollars) into a copyright court case that a judge creates the equivalent of patent claims (abstract/filtration) - before then there is no public notice provided by the software author about what parts of his software he knows to be copyrightable. And often the judge's analysis also provides no notice, given the high rate of reversal by the appeals courts. Copyright head-to-toe is random ad hoc jurisprudence - profitable for lawyers like Rosen, not too assuring for open source programmers.
"Current U.S. law provides that, for new works, copyrights last
for the life of the author plus 70 years or, for a work of
corporate authorship, the shorter of 95 years from publication
or 120 years from creation. New patents last for 20 years from
the date the patent application is filed." (page 36)
A bit hypocritical for Rosen to not mention that leading open source advocates like Lessig are filing lawsuits challenging this much longer term of copyright law, when open source relies so much on copyright.
"In the absence of a contract, the terms and conditions of a
bare license may be subject to varying court interpretations
around the world. Some legal scholars even argue that the
terms and conditions of bare licenses like the GPL are
completely unenforceable, although the legitimacy of the GPL
has never been tested in any court. Neither have any other
open source licenses. This vague uncertainty hovering over
bare licenses like the GPL has not been much of an obstacle
to the adoption of GPL-licensed software, but it is unpleasant
for attorneys nonetheless." (page 55)
And unpleasant to the Supreme Court and Circuit Court of Appeals, who have repeatedly ruled that vagueness, especially in the law, can be a violation of the Constitution. Rosen's neglect in not mentioning this, even something as short as a single sentence referring to the Fifth Amendment, is not acceptable. And it would be important to open source developers, if only THEIR lawyers would explain vagueness concerns to them. I find it incredible the amount of law kept from open source programmers from the open source lawyers, a denial more threatening to open source programming than anything involving patents. Open source programmers should stop complaining about a hypothetical threat from patents, and instead demand that their lawyers clarify the many threatening weaknesses of copyright.
"Some of these GPL detractors are licensors of <i>proprietary</i>
software. Their complaints are hypocritical. They too have
created islands of software from which nothing can escape.
The ONLY principled complaint about the GPL comes from those
who license their software under <i>academic</i> open source
licenses." (page 104)
FALSE. It is a principled complaint to argue that nothing about software is copyrightable (especially in light of copyright caselaw and patents) to then complain about GPL's uselessness. It is a principled complaint to argue, like Rosen mentions, that the GPL is a vague, unenforceable license. It is a principled complaint that GPL is useless because it violates copyright's misuse concerns when it makes you open up your GPL-related code to the public. It is a principled complaint to complain that there are multiple principled complaints. There are all sorts of principled complaints available to GPL detractors.
"But it is legally unnecessary to know what the drafter of a
licence - usualy just an attorney with no stake in the matter
Dubious advice. If the license is vague, it has enforceability problems. So it is useful to know if the license drafter is incorrectly/vaguely using the law in the license (or incorrectly/vaguely understands the law). Indeed, a few paragraphs later on the same page, Rosen writes (in a chapter on the GPL):
"One final warning: If there is an ambiguity or uncertainty of
interpretation in a [GPL] license, the license will generally
be interpreted <i>against</i> the licensor regardless of what
the license drafter meant to say." (page 120)
Why isn't this in bold, capital letters, since Rosen makes many comments in his book that the GPL license is ambiguous and uncertain, and this PATNEWS adds many more? Has he explained this to Stallman and Moglen as they go about rewriting the GPL? I suggest Stallman find some patent lawyers to provide him real IP law advice - I'd be glad to recommend the best, starting with Ms. Meeker (see the article below).
For "anarchists" like Moglen, what is even more fun than destroying the legal and proprietary software worlds with GPL? To undermine the open source programmers you are so using by convincing them to use the legally dubious as the GPL. BETRAY EVERYONE - one of the anarchists' creeds. I can see their laughters when the GPL is finally killed in the courts.
Rosen then goes onto the criticize elements of the LGPL, which is often used in the context of the GPL, and therefore offers no escape from the many problems of the GPL. He quotes a section of the LGPL:
"<i>If such an object file uses only numerical parameters, data
structure layouts and accessors, and small macros and small
inline functions (ten lines or less in length), then the use
of the object file is unrestricted, regardless of whether it
is legally a derivative work. LGPL Section 5. </i>"
(page 123)
It would be nice if the LGPL or Rosen noticed that this is not a "gift" from the LGPL licensors, but rather forced upon them by court decisions that ruled that these aspects of computer programs are uncopyrightable due to the 17 U.S.C. 102(b) prohibitions not mentioned in Rosen's book. At least he has a harsh criticism: "These sections of the LGPL are an impenetrable maze of technological babble." with a similar harshness on page 127: "The GPL is also silent about the scope and duration of the licenses it does grant."
"Nobody is quite sure what effect software and business method
patents will have on open source software." (page 133)
"Which software and which patent, and what effect on software
freedom, is a mystery until it actually happens." (page 134)
NONSENSE - there is little mystery if you understand law and economics. Since open source has been around for fifteen years (from GPL's birth in 1989) without having been affected by software and business method patents (at least compared to the orders more serious affects of patents experienced by PROPRIETARY software companies, i.e., companies with money), it is reasonable to expect that there will be little to no effect in the future with regards to patents and open source development. Don't forget that the key goal of patent litigation is to get money, and most open source efforts don't have any money to get.
"Words without definition are ambiguous; there is no reliable
way to predict how the parties - or a court - might interpret
a license without clear definitions when performance under it
is called for or questioned." (page 144)
Lessig says even more in one of his books: "[copyright law] burdens this creativity with INSANELY COMPLEX AND VAGUE rules". There are serious constitutional consequences of vague laws and licenses - why then the silence of lawyers like Rosen and Lessig? Real lawyers say that such licenses provide no public notice, that using such undefined words may be fatally vague (words like "idea" and "expression" as applied to software), and that such lack of notice and vagueness raises serious constitutional issues in light of the Fifth Amendment. The open source movement might want to get some advice from real constitutional lawyers.
The Book's Major Weakness: Rosen's Near Silence On 102(b).
Open source rests on copyright law, copyright law which has a major weakness when it comes to software - the 17 U.S.C. 102(b) prohibition on copyright for ideas, processes, methods and systems. The first chapter on any book on open source law should explain the near complete reliance of open source licenses on copyright. The second chapter, a very long chapter dwarfing the others in size, should explain the weakness of doing so because of 17 U.S.C. 102(b). That is, if you are charging people for your book.
Sadly, not only does Rosen not explicitly name 102(b), but he also doesn't mention any of the extensive caselaw flowing from 102(b) that greatly restricts the scope of software copyright. Instead, other than a few mentions, he only devotes five pages (39, 285-288) out of 400. This is a disservice to legally ill-informed open source developers. The second part of my critique focuses on these five pages.
First the teaser on page 39:
"EXCEPTIONS TO INTELLECTUAL PROPERTY PROTECTION
......
Once again, why the misinformation - why does Rosen refuse to explicitly mention 17 U.S.C. 102(b)? Why not write out the full statute for 17 U.S.C. 102(b) - only twice as many words:
In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, REGARDLESS OF THE FORM in which it is described, explained, illustrated, or embodied in such work.
To so mention 102(b) discloses terms programmers understand, terms common to programmers: "procedure", "process", and "method", "method" as in Java method, giving them the ability to think better about the law. So why not give the programmers this information?
"To determine whether a software program is a derivative work of
another software program, the courts need to disentangle these
abstractions ["ideas" from "expression"]. The procedure that
many courts use, called the abstraction-filtration-comparison
test, is described below." (page 285)
A partial truth. The AFC test is also used to see if there is anything copyrightable about a computer program before someone uses it to create derivatives. This distinction is important, since many lawyers argue that nothing should survive abstraction and filtration, especially if the lawyers know patent law. Their analysis makes GPL unenforceable. His use of "derivative" here is thus misleading. It would have been helpful for Rosen to mention the AFC test's case name: Computer Associates v. Altai, so open source programmers could search online for articles about the test (for example, an article by an IBM lawyer in which he states that the Altai test is "neither useable nor comprehensible ... a legal Chernobyl").
And the phrase "many courts use" is way too cavalier - open source programmers need to understand the politics of the federal court system the software attitudes of the various Circuit Court of Appeals, and the implicit confused understanding of these courts with regards to computer science as seen in the many higher court reversals of lower court decisions (the recent Lexmark case a classic example of confusion). For example, many courts still write that source codes (like in Forth, C or Prolog) are not directly executable by computers, even though there are (patented) microprocessors that directly execute (Basic, C and Prolog) source code.
"Some similarities relating to the basic functioning of computer
systems (e.g., subroutine entry and exit code, external interfaces)
can occur by coincidence or intentionally because "that's the
way computers have to work" [and thus are not copyrightable].
Some snippets of software may be too small and ordinary to be
copyrightable. In other cases program functions are coded in a
particular way because that is the only (or most effective, or
the industry standard) way to implement that specific function
on that particular architecture. Such source code must be
excluded from the comparison because it is not entitled to
copyright protection; instead it is idea that has merged into
expression, and is thereby rendered uncopyrightable. (page 286)"
It would have been nice to mention that these tests are part of the filtration stage of the AFC test. And Rosen should have mentioned that the AFC test is based on a law review article which wrongly bases this software analysis test on film/theatre theory. Wrongly in the sense that the Altai court decision announcing the AFC test is silent on whether or not patent claims are specific ideas that also must be filtered out (thus ensuring nothing survives filtration). It would have been a perfect point in the book for Rosen to apply these tests to the Linux kernel (which is unlikely to survive abstraction and filtration).
"Higher levels of abstraction may be needed to identify the
similarities [of two computer programs]. At those higher levels
of abstraction, ...." (page 287)
Again, one flaw of the AFC test is that it is NOT based on computer industry techniques for abstractioning and reverse engineering. Indeed, judges DON'T use commercial/academic software abstractioning tools to do software abstractioning.
"... copyright protection DOES NOT extend to any ideas, procedures,
processes, principles, or discoveries contained in the
original program." (page 287)
Finally, 287 pages into his book, he partially quotes 17 U.S.C. 102(b), once again doesn't identify the statute, and doesn't quote the full statute, especially the "REGARDLESS OF THE FORM" language. WHY? Why this repeated refusal to mention one of the two foundational points of copyright law? Do copyright lawyers melt if you sprinkle 102(b) on them? If we click our programmer shoes, will they go away? Why is 102(b) hidden behind the curtain?
"[copyright protection] MAY extend beyond the literal code of a
program to its nonliteral aspects, such as its architecture,
structure, sequence, organization, operational modules, and
computer user interface." (page 287)
Again, he mentions the Whelan-nonsense of SSO (rejected by the court that created the AFC test that Rosen does mention - put this stuff in context!). Even more unacceptably, Rosen mentions computer user interfaces MAY be copyrightable instead of mentioning that computer user interface MOST LIKELY AREN'T copyrightable in light of Lotus v. Borland and Apple v. Macintosh, and endless numbers of utility patents on GUIs.
"Nothing in the law of copyright suggests that linking between
programs is a determinative factor in derivative work analyses
by courts - except perhaps as evidence of one of the abstract,
nonliteral, copyrightable aspects of the software, such as
program architecture, structure and organization." (page 287)
Yeah, program architecture, structure and organization that is system utilitarian function - statutorily not copryightable but patentable.
"Companies that create software should make sure their employees
don't have access to preexisting software, and they should
train their employees not to copy other software." (page 289)
Wise advise outside the open source world. Completely hypocritical advice to give in the "we want everyone to have preexisting access" open source world. It is incredible a book on open source advices this anti-open-source-philosophy.
Forget about the omissions and mistakes in this book. The implications of just this book are that the GPL licenses have many potential fatal defects due to their licensing language and their reliance on the highly problematic theory of copyright for computer programs. Let's just say that I know lots of patent litigators who can take such defects and crush any assertion of GPL in court. The cowardice of the GPL crowd to not test and resolve the defects of GPL is not a good way to progress the arts and sciences. That organizations such as the ABA and AIPLA have allowed this confusion to fester is not public service.
Greg Aharonian
Internet Patent News Service
Some quotes from her article:
It would be neither original nor controversial to observe
that copyright is an awkward scheme to protect computer
software. ....
She is referring to the many court decisions greatly restricting the scope of copyright in a computer program, and law review articles condemning most, if not all, of computer program copyright (both sets of materials of which are rarely, if ever, mentioned to open source programmers by their open source lawyers).
Copyright protects expression, not ideas. But software is
not really all that expressive. .... This makes protection
of software via copyright trick, because functional elements
or ideas are not protected -- only expression. Not
surprisingly, actually identifying software copyright
infringement is like reading tea leaves. ... The serious
[software] copyright battles are over the copying of bits
and pieces, structures, design elements and so forth ---
and applying copyright law to those cases is difficult,
expensive and unpredictable.
Yes, the infamous metaphysical idea/expression dichotomy as applied to software - difficult, expensive and unpredictable (sounds like vague to me) - that is what GPL wants to rest on? A comment on dealing with the type of infringement issues that GPL will eventually face:
Easy as pie, huh? [describing the Altai tests]. And if you
aren't in a circuit that uses this test, like the second,
ninth or tenth judicial circuit, the law could be different.
And you [programmers] know which judicial circuit you are
in, don't you. Don't you?
Yes, one notice problems of software copyright - there is no national legal explanation of what is copyrightable about computer programs. Computer science has the same scientific axiomizations across the country - the law should be national as well, not circuit dependent.
Her next comments really express [financially] the dubiousness of software copyright law.
But basically, [patent infringement analysis is] a more
predictable process than engineering around a copyright.
How do I know? You can hire a lawyer to write an opinion
of whether a product infringes a patent. You can find
such a lawyer in the yellow pages - I am not kidding, you
can. That lawyer can even be legally liable if his
opinion is wrong. But you say you want to hire a lawyer
to write an opinion on whether a product infringes a
copyright? Good luck with that. People who read
[copyright's] tea leaves don't give guarantees.
That's right, what she is saying is that software copyright law is so legally pathetic, so crappy, that you can't even pay need-billable-hours lawyers to give you an opinion. Would any lawyer have bet their money on the outcome of the yes-it-is-no-it-isnt-copyrightable Lexmark decision? Her full article is at: www.linuxinsider.com/story/40676.html
Greg Aharonian
Internet Patent News Service
Received on Tue Mar 22 2005 - 02:45:02 GMT
This archive was generated by hypermail 2.2.0 : Mon Mar 26 2007 - 00:35:54 GMT