FOSS and the Labyrinthine Land of Licensing
May 29, 2009 4:00 AM PT
The open source movement may well have gotten a great boost from a court decision that could make it easier to enforce FOSS licenses.
Last December, the U.S. Court of Appeals for the Federal Circuit issued a decision in the matter of Jacobsen v. Katzer, ruling that breach of an open source license can support a claim for copyright infringement with associated remedies. The court's ruling may also require recognizing that the open source copyright owner has standing to sue downstream licensees for copyright infringement.
However, the unintended side effect of that ruling may be that many software developers could shy away from potential legal conflicts by avoiding open source programming altogether -- and that could lead to more attention on licensing issues that have always existed but never got much attention.
For example, say an enterprise application that your business developed in-house and relies upon heavily incorporates a bit of open source code. How much of the entire product must be treated as open source? How do the various open source licenses differ in addressing this issue? Who investigates and enforces the rules?
"The Jacobsen case raises a new set of concerns for developers of proprietary software," Jonathan Moskin, partner in the intellectual property practice of White & Case, told LinuxInsider.
New Legal Ground
No court decisions in cases involving the use of open source code in proprietary software products existed prior to the Jacobsen case, according to Moskin, a fact that he finds remarkable.
The open source movement is at least 10 years old and previously had no legal precedent for the enforcement of open source licensing.
"Before Jacobsen v. Katzer, commercial software developers already often avoided incorporating open source components in their offerings for fear of being stripped of ownership rights," said Moskin, who has written about this case.
As a result of this decision, he said, commercial software developers should be even more cautious of incorporating any open source code in their offerings.
"Potentially far greater monetary remedies -- not to mention continued availability of equitable relief -- make this vehicle one train to board with caution," emphasized Moskin.
Maybe Not Groundbreaking?
Whether the Jacobsen case will chart new protections for open source developers remains to be seen. Much will depend on who starts filing new lawsuits under that court ruling, noted Moskin.
The issues in this case may be too narrow to carry much punch in broader cases, he reasoned.
The Jacobsen case may be among the most recent court decisions on open source license contentions, but it is not necessarily the first or only definitive case.
Open source license litigation has about a dozen cases on the books, according to lawyer Michael Overly of Foley & Lardner, who specializes in technology transactions.
"Open source licenses are enforceable. The bigger question is, if I take my GPL license and add it to my proprietary program, am I required to turn over the entire thing to the open source community? That question has yet to be answered by any court in the U.S.," Overly told LinuxInsider.
License Silly Stuff
The courts have ruled that open source licenses are enforceable. That is not at issue and is in a category of its own, according to Overly. The other category of litigation is what he calls "silly stuff."
For instance, certain open source licenses generally say that that the person distributing open source code to others has to hand them a copy of the license. Usually, the distributor has to make available the source code for the original program.
"What is happening is that not all folks are doing that. So what we are seeing is a growing number of lawsuits about that stuff. The requirements seem pretty easy and show the sort of stuff that should never get to a courtroom," he said.
The Jacobsen v. Katzer case involved software used to control a model train product. The federal circuit court reversed a lower district court's ruling that there was no enforceable license at play in the case.
The federal court said the language did not simply use contractual terms, obligations and covenants. It made a legal distinction that required users to satisfy certain conditions before a license would exist. The federal court said there was a violation of copyright and contract, according to Moskin.
Copyright infringement, unlike a breach of a license agreement, is a strict liability tort. What that means for a commercial developer of software is that if any of the company's engineers borrow or steal or make careless use of open source material covered by copyright, both the software developer and his customers using the code are liable for copyright agreement violations, Moskin explained.
"Now, because a developer uses a chunk of open source code, the entire otherwise proprietary program may have to be submitted to the community," he said.
Unlike interstate trade or banking industry activities, no government regulatory agency such as the Federal Trade Commission monitors who does what with software code. Since no outside agency gets involved in overseeing the use of software, it's up to the copyright or license holder to pursue a challenge to the use of the material in court, said Moskin.
"Normally, we don't think in terms of open source being proprietary, but under copyright law, there is a proprietary right which is enforceable by the owners," he explained.
Why is this significant? As long as you can establish ownership rights, then you, as the owner, can sue, Moskin said.
Who is going to court over all this? The answer falls into two categories. The Software Freedom Law Center, founded in 2005, is one of the major self-appointed enforcers. The Open Source Initiative is another watchdog group.
The Software Freedom Law Center is primarily looking to have people voluntarily comply with open source licenses. It sues only when the person not following the license refuses to cooperate, according to Overly. Some trade and legal organizations are bringing lawsuits in this area as well.
"The Open Source Initiative is the self-declared arbitrator of what is open source and what is not. You can find most of the common licenses there listed, but what you won't find is any explanation of how they work together. They believe this isn't their problem, which some of us find less than helpful," Franz Maruna, founder and CEO of content management system developer Concrete CMS, told LinuxInsider.
The other category is comprised of the complaining company's competitors. If one company finds out that its competitor used open source parcels, it can try to leverage a possible license violation to compromise its rival.
Of course, the software author can join this category of litigants as well. However, code writers usually do not get involved in that activity, Overly noted.
"The Free Software Foundation wrote the GPL license and is out there actively looking for violators. Like bounty hunters, they have a vested interest in enforcing the open source licenses," Kim Weins, senior vice president of products and marketing for OpenLogic, told LinuxInsider.
Rules Get Fuzzy
Open source license rules cover two distinct use cases, according to Weins, whose company offers products to guide enterprises and software developers through the open source license process. One involves companies that will be using open source in-house. Those users do not have to do anything.
The other involves companies that will distribute open source code outside the walls of their organizations as part of another program. Once that happens, there are a lot of clauses that come into play.
"If you mix open source with your proprietary code, you may have to release the entire package as open source. These clauses are often found in the GPL-type licenses. It is what some people refer to as "copyleft" (as opposed to copyright) obligations," Weins told LinuxInsider.
The rules here can be more subtle than some companies realize. For instance, a firm does not have to sell the software. Instead, it could provide it for free to customers or give it to its partners. This can constitute distribution, explained Weins.
License by the Numbers
Open source license rules are clearly not cut and dried. However, Laurent Duperval, president of the Montreal, Canada, firm Duperval Consulting, explained in broad strokes how licensing works.
If the code is only used internally, no license issues generally arise.
Those using a GPL-type license can change the original software and modify it for their own needs. However, if they decide to redistribute or sell the software, they have to provide the source code for those changes to anyone who wants it.
"The idea behind this model is that if you gained a leg up to get your product off the ground, then you have to extend that same courtesy to others who can benefit from your work," Duperval told LinuxInsider.
Those using software covered by a BSD-type license can modify the original source code and do whatever they want with it. This includes distributing or selling their changes without having to divulge their source code, he said.
"The idea behind this model is to lower the barrier to commercial distribution because many companies are wary of making their source code available. In this case, no legal enforcing is needed. Other licenses usually fall somewhere in between the BSD and the GPL," Duperval said.