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.

3 Comments

  • Jack,

    Kindly think before you write. This article is so badly written, I couldn’t believe it.

    1) The Jacobsen vs Katzner case changes nothing. Copyright infringement is still copyright infringement, as Katzner found out. Acting like Slime has a tendency to backfire.

    2) Jonathan Moskin may be a lawyer, however he shows a lack of ability. The Jacobsen case raised no new concerns. Nothing has changed. Copyright infringement is still copyright infringement.

    3) This is not new legal ground. Copyright cases involving software are common, and the infringer has always lost in every case I AM aware of.

    4) Michael Overly is incorrect. While the courts have not addressed the GPL directly, they have addressed proprietary software licenses, and since legally a software license is a software license, the GPL is as strong as Microsoft’s license, and would be treated the same way in court. Again, copyright infringement is copyright infringement.

    5) I notice that you didn’t interview anyone at the Free Software Foundation. Curious. A good part of the article is about them, why wouldn’t you interview them?

    6) What this article comes down to, is that theft (whether theft of source code, or theft of money) is still theft. The copyright act is a strong protection for code written under the GPL and other Free Software licenses.

    7) Keeping code in-house may be a partial protection for a business trying to steal Free Software code, however if it is put on a web site (like a content management system) it may have to be released (see the AGPL).

    8) Why is everyone so excited about having to release source code? Why do lawyers seem to be so worried about this? Is it possible that the lawyers themselves have been stealing GPL code? Or is it just that they are trying to drum up business by getting potential customers worried about something that is easily understood.

    Quite frankly, the excitement about GPL compliance is ridiculous. You are either compliant, or you aren’t. If you aren’t, take the steps required to be compliant.

    GPL Compliance is not difficult. Neither the Free Software Foundation, nor Free Software authors like myself want to kill your company. All we want is that you comply with the license. Do that, and we are happy if you use our code.

    • Your video is of limited usefulness to anyone, as you don’t explain properly what "freeware" is.

      Or why anyone would use "freeware" when there is usually GPL or BSD licensed programs that will do the same thing, are usually better written, and don’t have the limitations that "freeware" has. Because "freeware" isn’t free, just like "free software" isn’t free in a monetary sense. There’s more than one meaning of the word free, with free software being free in the "free speech" sense.

  • It is true that one’s exposure to liability is reduced when using free software, however there are still numerous points of legal liability associated with using ANY piece of software.

    The cost of the license and software is immaterial.

    The liability of utilizing free software comes from the agreement, and the binding terms, thereof. With commercial products, like Microsoft, Adobe, etc, the terms are centered around fiduciary obligations.

    Often with freeware, the terms are centered around specific performance, disclosure and distribution.

    As the FSF recently explained to Cisco in a federal lawsuit… "It’s all about the contract."

    My group has a video about "Freeware" and the associated problems with utilizing such located here… http://video.sadien.com/Freeware-224.html

    G.C. Hutson
    Chief Executive and Senior Partner
    Sadien Intellectual Property, Inc.

Leave a Comment

Please sign in to post or reply to a comment. New users create a free account.

LinuxInsider Channels