FOSS and the Labyrinthine Land of Licensing

The open source movement may well have gotten a greatboost from a court decision that could make it easier to enforce FOSS licenses.

Last December, the U.S. Court of Appeals for the FederalCircuit issued a decision in the matter of Jacobsen v. Katzer, rulingthat breach of an open source license can support a claim forcopyright infringement with associated remedies. The court’s rulingmay also require recognizing that the open source copyright owner hasstanding to sue downstream licensees for copyright infringement.

However, the unintended side effect of that ruling may be that many software developerscould shy away from potential legal conflicts by avoiding open sourceprogramming altogether — and that could lead to more attention on licensingissues that have always existed but never got much attention.

For example, say an enterprise application that your businessdeveloped in-house and relies upon heavily incorporates a bit of opensource code. How much of the entire product must be treated as opensource? How do the various open source licenses differ in addressingthis issue? Who investigates and enforces the rules?

“The Jacobsen case raises a new set of concerns for developers ofproprietary software,” Jonathan Moskin, partner in the intellectualproperty practice of White & Case, told LinuxInsider.

New Legal Ground

No court decisions in cases involving the use of open source code inproprietary software products existed prior to the Jacobsen case,according to Moskin, a fact that he finds remarkable.

The opensource movement is at least 10 years old and previously had no legal precedent for theenforcement of open source licensing.

“Before Jacobsen v. Katzer, commercial software developers alreadyoften avoided incorporating open source components in their offeringsfor fear of being stripped of ownership rights,” said Moskin, who haswritten about this case.

As a result of this decision, he said, commercialsoftware developers should be even more cautious of incorporating anyopen source code in their offerings.

“Potentially far greater monetary remedies — not to mention continuedavailability of equitable relief — make this vehicle one train to boardwith caution,” emphasized Moskin.

Maybe Not Groundbreaking?

Whether the Jacobsen case will chart new protections for opensource developers remains to be seen. Much will depend on who startsfiling new lawsuits under that court ruling, noted Moskin.

Theissues in this case may be too narrow to carry much punch in broadercases, he reasoned.

The Jacobsen case may be among the most recent court decisions on opensource license contentions, but it is not necessarily the first oronly definitive case.

Open source license litigation has about a dozencases 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 Itake my GPL license and add it to my proprietary program, am Irequired 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.,” Overlytold LinuxInsider.

License Silly Stuff

The courts have ruled that open source licenses are enforceable. Thatis 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 theperson distributing open source code to others has to hand them a copyof the license. Usually, the distributor has to make available thesource code for the original program.

“What is happening is that not all folks are doing that. So what weare seeing is a growing number of lawsuits about that stuff. Therequirements seem pretty easy and show the sort of stuff that shouldnever get to a courtroom,” he said.

Case Details

The Jacobsen v. Katzer case involved software used to control a modeltrain product. The federal circuit court reversed a lowerdistrict court’s ruling that there was no enforceable license at play inthe case.

The federal court said the language did not simply use contractualterms, obligations and covenants. It made a legal distinction thatrequired 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 astrict liability tort. What that means for a commercial developer ofsoftware is that if any of the company’s engineers borrow or steal or makecareless use of open source material covered by copyright, both thesoftware developer and his customers using the code are liable forcopyright agreement violations, Moskin explained.

“Now, because a developer uses a chunk of open source code, the entireotherwise proprietary program may have to be submitted to thecommunity,” he said.

Says Who?

Unlike interstate trade or banking industry activities, no governmentregulatory agency such as the Federal Trade Commission monitors who does what with software code. Since nooutside agency gets involved in overseeing the use of software, it’s up to the copyright or license holder to pursue achallenge 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 ownershiprights, then you, as the owner, can sue, Moskin said.

Litigant Lineup

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 majorself-appointed enforcers. The Open Source Initiative is anotherwatchdog group.

The Software Freedom Law Center is primarily looking to have peoplevoluntarily comply with open source licenses. It sues only whenthe person not following the license refuses to cooperate, accordingto Overly. Some trade and legal organizations are bringing lawsuits inthis area as well.

“The Open Source Initiative is the self-declared arbitrator of what isopen source and what is not. You can find most of the common licensesthere listed, but what you won’t find is any explanation of how theywork together. They believe this isn’t their problem, which some of usfind less than helpful,” Franz Maruna, founder and CEO of contentmanagement system developer Concrete CMS, toldLinuxInsider.

Code Combatants

The other category is comprised of the complaining company’s competitors. If one company finds out that its competitor used opensource parcels, it can try to leverage a possible license violationto 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, Overlynoted.

“The Free Software Foundation wrote the GPL license and is out thereactively looking for violators. Like bounty hunters, they have avested interest in enforcing the open source licenses,” Kim Weins,senior vice president of products and marketing for OpenLogic, toldLinuxInsider.

Rules Get Fuzzy

Open source license rules cover two distinct use cases, according to Weins, whose company offers productsto guide enterprises and software developers through the open sourcelicense 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 opensource code outside the walls of their organizations as part ofanother program. Once that happens, there are a lot of clauses thatcome into play.

“If you mix open source with your proprietary code, you may have torelease the entire package as open source. These clauses are oftenfound in the GPL-type licenses. It is what some people refer to as”copyleft” (as opposed to copyright) obligations,” Weins toldLinuxInsider.

The rules here can be more subtle than some companies realize. For instance, a firmdoes not have to sell the software. Instead, it could provide it for free to customers or give it to itspartners. This can constitute distribution, explained Weins.

License by the Numbers

Open source license rules are clearly not cut and dried. However, LaurentDuperval, president of the Montreal, Canada, firm Duperval Consulting,explained in broad strokes how licensing works.

If the code isonly used internally, no license issues generally arise.

Those using a GPL-type license can change theoriginal software and modify it for their own needs. However, if theydecide to redistribute or sell the software, they have to provide thesource code for those changes to anyone who wants it.

“The idea behind this model is that if you gained a leg up to get yourproduct off the ground, then you have to extend that same courtesy toothers who can benefit from your work,” Duperval told LinuxInsider.

Those using software covered by a BSD-type license can modify theoriginal source code and do whatever they want with it. This includesdistributing or selling their changes without having to divulge theirsource code, he said.

“The idea behind this model is to lower the barrier to commercialdistribution because many companies are wary of making their sourcecode available. In this case, no legal enforcing is needed. Otherlicenses usually fall somewhere in between the BSD and the GPL,”Duperval said.