Skip navigation
Wooden gavel AlexStar/Thinkstock

Court Ruling Adds New Power to Open Source Licenses

Thanks to a recent federal court ruling, open source licenses can now be enforced as contracts.

Any organization using open source source software should make sure there is a strong open source policy in place that dots the "I"s and crosses the "T"s. Why? Because open source licenses recently became even more enforceable than they were already.

For some time case law has made them enforceable in copyright cases. Now, with a federal district court ruling in Artifex vs. Hancom, they're clearly enforceable in contract disputes as well.

First a little history.

For a long time after Richard Stallman penned the first General Public License in 1989, there was a cloud with a question mark inside hanging over all open source projects. No one knew whether the license would be legally enforceable. When consulted, legal eagles were pretty much in agreement that they should be enforceable -- with the caveat that lawyers and judges have sometimes disagreed on seemingly clear points of law. Until there was a court case centered on their enforceability, they said, open source projects were in limbo.

That case finally came in Jacobsen v. Katzer, which was filed in 2006 in the United States District Court for the Northern District of California. The case, centering around model trains, was fairly convoluted, starting out as a patent case against Jacobsen and his open source project, the Java Model Railroad Interface. When Jacobsen counter-sued, claiming copyright infringement of his open source code, case law was made. On appeal, the court handed down a ruling that established the enforceability of both open source and proprietary licenses in copyright cases.

However, it might be difficult -- maybe impossible -- to go after an infringer for copyright infringement who's working outside the United States, which is one reason the recent ruling is important.

The latest case involved Ghostscript, a PDF interpreter developed by Artifex Software that's available under the open source GPL license or a commercial proprietary license. Trouble arose when South Korean-based Hancom began integrating Ghostscript code into its proprietary office productivity products.

To be compliant with the terms of the GPL, Hancom would have to both make the source code available, which it didn't, and allow anyone with a copy of the product to distribute it freely, which wasn't going to happen. That left purchasing a commercial license as Hancon's only option, which it didn't do.

Eventually Artifex sued, both for copyright infringement and for breach of contract, based on the terms of open source software license. Artifex's position was that by using the software Hancom had agreed to its licensing terms.

"You are not required to accept this license in order to receive or run a copy of the program...," the company said in its brief to the court. "However, nothing other than this license grants you permission to propagate or modify any covered work. These actions infringe copyright if you do not accept this license. Therefore, by modifying or propagating a covered work, you indicate your acceptance of this license to do so."

According to the National Law Review, Hancom responded with three arguments.

"First, it alleged Plaintiff failed to state a claim for breach of contract and that any such claim is preempted by copyright law. Second, it alleged Plaintiff’s copyright claim must be dismissed in part because Plaintiff has failed to allege that Defendant committed a predicate act in the United States. Finally, Defendant moved to strike portions of the relief sought in the complaint."

On April 25 the court ruled against Hancom, rejecting all three of its arguments.

This ruling underscores the need for developers utilizing open source code to carefully vet the code for infringement issues which could be costly down the road. It also highlights the need to have a policy dictating how outside open source code can be used and how it should be documented.

Many companies are lax in this area, due to what Flexera Software's VP of product management, Jeff Luszcz, called a "clear disconnect" in a recent article on Linux.com. He pointed out that often management has no idea what open source code, if any, developers might be using, while the legal department assumes developers know what they're doing and are checking for compliance. Meanwhile, developers are under pressure to get product installed or shipped.

"This disconnect is very clear when a company building a software product is required to produce an independently verified disclosure of all the open source and commercial code it uses," he wrote. "Organizations are very surprised to see a 20 times or more difference between what they think they are using, and what they are really using. They are typically out of compliance with each of those previously unknown components."

The good news for Devs and DevOps using open source is that open source projects are unlikely to sue for accidental non-compliance and view legal action as a last resort. On its website, the Free Software Foundation, author of the GPL, says it has only had to resort to legal action once in its history. "The vast majority of our compliance work happens behind the scenes," it says, "for good reason: it allows the majority of violators to quietly ameliorate compliance problems and join the free software community."

The good graces of the open source community might not always be enough, however. There are open source profiteers. For example, for a number of years there have been concerns about Patrick McHardy, a Linux kernel developer and former chair of the open source Netfilter core team, who is reputed to have filed numerous lawsuits in Germany seeking damages for infringement of his code within GPL projects.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish