Slashdot Mirror
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."
Katzer did considerably more than fail to comply with modest license terms. He filed a patent application for something he did not invent and claimed copyright to something he did not write. This was not a case of a minor license violation, but rather deliberate fraud. Consequently, the penalties he faced were much higher,
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.
Is this really a new risk? If you're distributing software that includes a proprietary closed-source component, and someone upstream in the company that created that component illegally included copyrighted proprietary software in it, wouldn't that expose you to exactly the same risks for exactly the same reasons, and permit you exactly the same defenses? I don't see where open-source makes any difference here, in all cases (open-source and closed-source) where you redistribute someone else's software you have to trust that they haven't committed copyright infringement in what they're providing to you.
Open-source is, if anything, less vulnerable to these risks. So far all the cases I've seen reported have involved the inclusion of non-licensed software (both proprietary and open-source) in closed-source proprietary products. The only allegations going the other way, of inclusion of unlicensed code in an open-source project, were SCO's allegations of the inclusion of SysV code in Linux and IBM shredded those so thoroughly you need a microscope to find the pieces (and in the process made a good argument that it's in fact SCO that's been including Linux code in their products in violation of the license).
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.
AccountKiller
The reality is that free and open source code is no different in *any* way from code from any other source. If it's not yours you cannot legally use it, _unless_ you abide by the licensing terms of the licensor.
It astounds me how many companies get trapped thinking that copyright is somehow different for free and open source software. Boggles the mind. It also boggles my mind that companies buy into the idea that things like the GPL can "infect" the company's IP. In a corporate world stuffed full of lawyers--IP lawyers even--how such basic misunderstandings of copyright law can be so widespread in industry is really disheartening.
Yeah the only reason Moskin has concerns is due to the propensity for the proprietary world to steal code, ie violate the licensing terms and NOT want to suffer the consequences. To bad. You think Microsoft would extract their pound of flesh for violating their licensing terms? Oh wait, why don't you go ask those who have had a visit by the BSA.
My karma is not a Chameleon.
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.
There is always a risk with using software for any purpose, be in as an end user, developer, or whatever. It is up to the user and the administrators to insure compliance. The only time an issue will every come up, be it in open, closed, or revolving software will be when the assumption is made that the software, code, ideas can be used for free, with no real or opportunity costs. Honestly, this assumption is made quite often, and every once in a while someone is caught. Fines are put into place to deter others from doing the same.
So nothing really changes. If one is a legitimate business, one still needs to insure that all supplies are kosher. Assuming that somehow the laws of physics have changed just because are going on the internet and getting stuff for free has gotten many a bussiness in trouble long before this ruling.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
GPL can "infect" a company's IP. And that's not a bug, it's a feature. RMS has said so himself and others are also quite clear on this.
My fellow Americans, let's restore the death penalty for child rapists. Let's do it . . . for the children.
...even when using source code licensed under open source terms!!!
And all these corporations using open source software to run their business are at risk of violating the terms of those licenses and will now drop open source like a sub-prime mortgage derivative laundered ten times over.
Oh, wait, it was a proprietary product that violated the open source license....ZOMG is right, proprietary vendors are screwed, how can you know if your closed source vendor has stolen open source code until after you've invested in using their product and put your business at risk.
Gee, I guess its just one more reason to use open source software from open source vendors. Who knows what kind of trouble those closed source vendors are getting you into.
You said:
GPL can "infect" a company's IP. And that's not a bug, it's a feature. RMS has said so himself and others 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
Let's repeat.
Yeah if you do that enough times, maybe it will become true!
You just explained in your #1 bullet point exactly how it is capable of infecting your code. You include it in your project and the whole thing becomes GPL if you distribute the binary even once. Even if you take it out and close it later, you've been forced to expose your source code to the whole world.
No it doesn't become GPL. Changing the license on your code is not one of the remedies a court can decide. The court can only decide on injunction against distributing the code, money and in extreme cases jail.
The only way the license can change on your code is if you decide it, possibly through a settlement.
OG.
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). The abstract: