The Long-Term Impact of Jacobsen v. Katzer

snydeq writes "Lawyer Jonathan Moskin has called into question the long-term impact last year's Java Model Railroad Interface court ruling will have on open source adoption among corporate entities. For many, the case in question, Jacobsen v. Katzer, has represented a boon for open source, laying down a legal foundation for the protection of open source developers. But as Moskin sees it, the ruling 'enables a set of potentially onerous monetary remedies for failures to comply with even modest license terms, and it subjects a potentially larger community of intellectual property users to liability.' In other words, in Moskin's eyes, Jacobsen v. Katzer could make firms wary of using open source software because they fear that someone in the food chain has violated a copyright, thus exposing them to lawsuit. It should be noted that Moskin's firm has represented Microsoft in anti-trust litigation before the European Union."

Maybe, maybe not

[rewt66]

IANAL. Having gotten that standard disclaimer out of the way, here's how I understand it. Jacobsen v. Katzer was a blatant, deliberate ripoff of open source code, followed (IIRC) by suing the original author for using his own code that the thief had claimed after stealing it. Said thief claimed that the open source license didn't mean anything, so that the thief's claim on the code was the only real one. Said thief lost the case. Now, I may have some of the foregoing details wrong. Don't take that as the gospel about what happened. But the point is, this case doesn't have much to do with accidental infringement. So let's take a specific example. Let's say open source project X unwittingly gets some code in it that is actually owned by company Y. Let's say that you, company Z, are using this code in a widget that you have shipped a large number (N) of. Now company Y is raising a stink. Do you have to either pay company Y for the use of their code or update all of your widgets in the field? Yes, unless company Y decides to be nice. (Note, however, that this is no different than a situation that Microsoft found itself in a few years back, so it's no different because the code was open source.) Are you liable for some large number of dollars times N to penalize you for stealing company Y's code? Probably not, unless your lawyers do a lousy job. You did it in innocence, which is completely different than the facts of this case.

Re:Long-term impact

[Anonymous Coward]

No corporation wants to use open sores software because they know somewhere along the line the ideas and code were almost certainly stolen from someone else. Lunis Noballs, Richard StillaVirgin and AIDS Perens can go suck a dong.

Translation: I like it rough and I'm trolling for dates.

So why doesn't this affect closed source software?

[Vellmont]

If you know even a tiny amount about the case, it actually was about commercial closed source software that violated the GPL. So if this is going to affect businesses opinions of software and risk, why is commercial software somehow immune from FUD?

It seems to me that open source software has LESS of a change of a license violation, for the very fact that anyone can look for anyone license violations. Closed source software is the one with the potential for all those scary skeletons in the closet. If you're to believe the Microsoft lawyer, I guess those closed source software operations should start shitting bricks.

Hmmm..

[drewsup]

From the summary... It should be noted that Moskin's firm has represented Microsoft in anti-trust litigation before the European Union." and just how is that working out for them... LOL

Two points

[MSG]

It's important to bear two things in mind:

1: The financial impact in this case was a result of Katzer's refusal to comply with the license. It was not an automatic result of his use of the code in question, but his failure to take corrective action when notified of his infringement.

2: Proprietary code may include proprietary components in violation of their license just as easily as it can contain Free Software components in violation of their license. The risk involved in using code licensed from a third party carries exactly the same risks whether or not it is Free Software.

Re:Maybe, maybe not

[Todd Knarr]

Is it? Here's a link to the GrokLaw article on the case. [groklaw.net] A quick check vs. the court filings indicates the article is correct. What I find: Jacobsen developed the software and methods included in it. Katzer took those, filed for patents on them, and tried to bill Jacobsen for using those patents. Jacobsen sued for declaratory judgement that his software wasn't infringing and the patents were invalid, based in part on the fact that Katzer failed to mention Jacobsen's software in his patent application or that the methods Katzer was claiming a patent on had been published more than a year prior to the filing.

And if you want more details, here's the Groklaw article on the Appeals Court's overturning of the district court's decision [groklaw.net]. It includes the complete text of the Appeals Court's ruling, so you can compare the analysis to what the court actually said and see for yourself that the analysis is on target.

Re:Open source code is no different than proprieta

[ion.simon.c]

You said:

GPL can "infect" a company's IP. And that's not a bug, it's a feature. RMS has said so [gnu.org] himself and others [gnu-pascal.de] are also quite clear on this.

The GPL is no more infectious than the "you can't sell the software that you build with this tool" clause of the license that accompanied "student" versions of MSFT's Visual C++ 6 and 7.

From the first link:

GPL and NDA

* To: gcc at gcc dot gnu dot org
* Subject: GPL and NDA
* From: Richard Stallman
* Date: Thu, 19 Jul 2001 05:07:10 -0600 (MDT)
* Reply-to: rms at gnu dot org

GPL-covered code may not be distributed under an NDA.
To do so is a violation of the GPL.

If someone asks you to sign an NDA for receiving GPL-covered code that
is copyright FSF, please inform the FSF immediately. If it involves
GPL-covered code that has some other copyright holder, please inform
that copyright holder, just as you would for any other kind of
violation of the GPL.

It is possible for a person or company to develop changes to a
GPL-covered program and sign an NDA promising not to release these
changes *to anyone*. This is a different case. As long as these
changes are not distributed at all, a fortiori they are not
distributed in a way that violates the GPL.

However, if and when the changes are distributed to another person or
outside the company, they must be distributed under the terms of the
GPL, not under an NDA.

This doesn't have anything to do with the licensing of works that derive from GPL-licensed code. Your inclusion of this information makes you look either illiterate or careless.

From the second link:

From: Phil Nelson
Subject: Inaccurate information in `GNU' section
Date: 23 Apr 2004, 09:33:30

Hash: SHA1

On Thursday 22 April 2004 11:45 pm, Peter N Lewis wrote:
> > > I'm confused by this. If it "does not contain code from any
> >
> >> GPL-covered software", then surely you can release it under any
> >> license you feel like, whether it can run stand-alone or not. If I
> >
> >A program can be free of code from a GPL-covered program, but it links
> >with a library licensed under the GPL, then it has to be under the GPL
> >as well. It is this catch, if you will, that led to the LGPL.
>
> This could only be true if you ship the binary with it linked.

First, the disclaimer, IANAL.

Second, I wrote gdbm for the FSF and have had many many conversations with Mr.
Stallman about the GPL and how it applies to libraries. The key to the GPL
is the understanding of "derivative work". I'll use gdbm as an example.

If code directly calls any of the gdbm functions, it *is* a derivative work.
Therefore, any work that directly calls gdbm functions and is distributed
must be distributed under the terms of the GPL. Of course, the GPL is
transitive, thus any program that has a call path that ends up in a gdbm
function is required to be under the GPL. (If distributed.)

If your code is written for the original dbm interface it is not a derivative
work of gdbm, even if you happen to use the dbm interface to gdbm.
It would be considered a derivative work of dbm.

I don't know if this would stand up in a court of law, but I'm very sure this
is what Mr. Stallman intended for the GPL. I have requested that gdbm be
put under the LGPL so that programs that use gdbm don't have to be under the
GPL, but he has chosen to keep the GPL on gdbm. Therefore, whenever people
ask about gdbm, the GPL and their programs, I must tell them that if they
plan to distri

Texas IP Law Journal on This Issue

[TheoMurpse]

For those who care, TIPLJ has a scholarly article in their latest issue about Jacobsen v. Katzer. Robert W. Gomulkiewicz, Conditions and Covenants in License Contracts: Tales from a Test of the Artistic License, 17 Tex. Intell. Prop. L. J. (Forthcoming 2009). [utexas.edu] The abstract:

The Federal Circuit upheld the Artistic License in Jacobsen v. Katzer, establishing at long last that open source licenses are enforceable. Although that outcome received most of the headlines, the caseâ(TM)s greater significance lies elsewhere. Jacobsen v. Katzer teaches valuable lessons about conditions and covenants in license contracts, lessons that apply to licenses of all persuasions. Moreover, the case raises an important question about the interplay between contract and intellectual property law: Can licensors manipulate the distinction between covenants and conditions in such a way that upsets the delicate balance in copyright law? This article explores the lessons taught by Jacobsen v. Katzer and the open issue that it leaves, concluding with a proposal that supports the business model innovation characterized by open source licensing.