Infringement and disclosure risk in development on copyleft platforms

While many companies that write apps or develop parallel platforms grounded in open source willingly disclose code and comply with copyleft rules (e.g., some transferees to also disclose their code), others prefer to protect (e.g., not disclose) some of their code and not force customers who resell products to disclose their code. The issue for these companies has always been how can they approach an open source platform or program without being caught in the copyleft “license” with a duty to disclose if they retransfer their products. The answer has never been certain, but the stakes today have never been higher.


The problems lie in the details. A Working Paper produced by a Free Software European Legal Network underscores how difficult it is to decide when a line is crossed and copyrighted code has been copied, triggering copyleft license obligations.  


Let’s take a “simple” question: if developer of program B replicates all or part of a copyleft program’s api or header files (e.g., of the core Linux kernel), do the copyleft rules e.g., of GPL v.2) apply to program B and, possibly, to programs based on it, requiring disclosure of source code and other limitations on licensing? The reality is that no one can give a viable general legal opinion on this. There is wild uncertainty in both the views of the community and in law. That defines a huge risk for companies engaged in this space.


To start with, the term “api” has different meanings that affect the legal issues.


A free software Working Paper states: “The term “API” or programming interface is used in two manners, being two sides of the same concept. On the one hand, an API is an abstraction, being a set of conventions or definitions to which a developer should develop his/her program … [On] the other hand, the term is used to describe the actual code or part of a program that receives/handles the input from the other programs …” 


Wikipedia states: “the scope of meaning is usually determined by the context of usage.”


Are api’s or header files copyrighted? If we are talking only about concepts, the answer may be no, depending on how general these are. If we are talking about details, then the answer is maybe. 


Header names are not copyrighted, but that is like saying that each individual word in this paragraph is not copyrighted. True, but that says nothing about the copyrightability of the paragraph. Complex programs and header file structures are generally copyrightable because they involve numerous choices by the designer and because the way in which these choices organize the terms and code constitutes expression. The Linux core header files, for example, involve large amounts of text and code, they are almost certainly copyrighted. Indeed, one U.S. court held that taken as a whole, a table of nine variables used to predict the performance of pitchers in baseball games was copyrighted. In contrast, another court held that a short piece of code (25 bytes) used to lock out use of a printer cartridge was not copyrightable - it was entirely caught up in the process it served. A European Directive states that computer “interfaces” are not protected by copyright, but does not indicate what “interface” means. Numerous U.S. courts hold that user interfaces taken as a whole are copyrighted.


When is use of particular copyrighted header files or api’s infringement?In U.S. law, this asks whether what is copied or caused to be copied involves copyrightable elements of the first program, or whether the second program is a “derivative work” of the first. Each case stands on its own. 


For example, Google, in creating its Android program based in part on the Linux kernel, uses script to “cleanse” Linux core header files, removing comments and some code. It asserts that the result contains no copyrighted material from Linux and distributes Android generally under an Apache license which is less demanding as a copyleft matter on Google and on resellers than GPL v.2.  For there to be no expression remaining, however, what must have been removed is not only the human readable text, but also the expressive features involved in the structure of the header files. This seems difficult to achieve since the goal was to borrow the effectiveness of the Linux system at least in part. Not having examined the facts, I don’t know the actual truth of the matter. Investigating the truth, however, is important for any Android developer because the method is relatively unique. It is a good illustration of the problem for our Program B developer in any context – i.e., the open question about when a software system is “based on” another program.


The U.S. Copyright Act uses that term. It defines a “derivative work” as any “work “based upon” one or more preexisting works [in any] form in which a work may be recast, transformed, or adapted.” “Based upon” is a concept not yet tested in reference to computer code. One meaning might be merely that the second program takes code from the other work. Another, supported by cases outside of those involving code is that a derivative must contain or cause the copying of expression of the infringed work. When this might occur is open to question. For example, some instances of dynamic linking would qualify, while others may not. Some replications of api capture expression, while others will not.


So, I return to the basic premise, that this is an uncertain world both technologically and legally. In addition, it is overlaid with numerous conflicting license terms, most of which have never been litigated. GPL v.2 is still the most used copyleft license. Its terms remain a legal mystery to many, including experts. It applies copyleft (e.g., disclosure rules) to the transfer and the re-transfer of any program that in whole or in part “contains” or is “derived” from the first program or any part of it, It does not apply to distribution of independent programs or of programs merely aggregated on a single medium.


I will let the reader ponder the meaning of those and other GPL terms as a matter of contract. I have written about the GPL v.2 before in this blog.


The point here is the legal uncertainty and risk in an environment in which lawsuits about intellectual property are increasingly common. For entities that do not desire to disclose code or force their customers to do so, or otherwise conform to copyleft obligations, working with copyleft platforms and programs presents a very significant and uncertain, risk-reward equation.

Written By:Dmytro Mazurok On March 1, 2011 9:07 AM

A good advise for Software Company to think twice before to use copyleft tool or library. But a real problem in my opinion lies in artificial applying copyright rules (originally designed for printed sources) to computer software. Plus broad information sharing that couldn't be controlled. The best way is to reform copyright law according to real public needs.

Written By:ldillon On March 17, 2011 2:00 PM

I think you're over-blowing concerns about GPL software.
Very few companies have been sued for GPL violations and only after they were given a chance to come into compliance. Many companies and individuals have been sued for running afoul of regular commercial software licenses, often for staggering amounts of money.

From what you say, it appears that Google may be trying something shady. If a company isn't intentionally trying to do something shady, they're unlikely to have problems with Copyleft software.

Written By:EdAlG On March 17, 2011 7:50 PM

It is unwise (if not bordering stupidity) to try to use software designed for freedom, and try to restrict the GPL freedoms. SCO is fried because of such an idea.
Also sofrware patents, and quite a lot of patent laws must be reviewed. I recall someone in Australia patented the wheel using a fancy wording to prove this point.

Written By:William Ahern On March 21, 2011 2:29 AM

"A good advise for Software Company to think twice before to use copyleft tool or library."

Mr. Mazurok, that's horrible advice. You're implying that the same considerations don't apply to non-copyleft and, specifically, closed-source software products.

The fact of the matter is that the waters are often far less murky when using copyleft software. (Just because they're impenetrable, as with closed-source, hardly makes them safe.) In either case, the best possible solution is indemnification from a well capitalized supplier. Short of that, at least with copyleft products one can do significantly more due diligence than with closed-source products. You have no idea if that closed-source product contains illicit code from third-parties.

With copyleft the source repositories are open and contributions can be examined in exacting detail. Substantive portions inevitably are contributed by a handful of people whose rightful authorship is more easily investigated. Small contributions are unlikely to have been illicitly lifted from other projects because they're always so specific to the particular product.

That most companies don't exercise this sort of diligence themselves doesn't mean they don't rely on it. A small company could reasonably rely on the presumptive due diligence of larger targets like an IBM or Google using the same copyleft software. Believe it or not, many engineers do practice due diligence when adopting copyleft projects in-house. This simply can't be done for closed-source applications; no company would voluntarily incriminate themselves--or open themselves up to incrimination--in response to inquiries from a customer.

The derivative work grey area concerning the GPL is easily avoided; the big, easy questions have already been answered in court several times, such as running regular applications on top of Linux without any co-mingling of non-ISO defined APIs. If an application can be built on any other Unix, it can be built on Linux without copyleft concerns; period.

Other than Linux itself, few copyleft software products that a proprietary business might wish to utilize use the GPL. The vast majority use licenses, such as the LGPL, for which there is no grey area; derivative uses covenants are well-defined.

Written By:Niels Woisin On March 23, 2011 9:20 AM

nicely written...

Though IBM seems to make too much profit with Linux to ever regret it, if some legal thing blows up on them.

While I respect Google, I am disappointed with their sloppy ways with copyright issues. It seems their programmers could use crash courses on legal issues, to avoid making the company look really bad.

As an Android developer, I wouldn't loose any sleep over small apps like world clocks and such. But enhancing, say, a trade system with proprietary analysis tools, to also run on Android phones, would seem a lousy idea.

My hope would be, that doing the actual processing on your own server, reducing the Android code to merely display results remotely supplied, would alleviate this issue?