The Death of “Free” Software or How Google Killed GPL
linkedin.comGoogle did not take Java code. It wrote it's own software with exactly same API.
Any API that is "in the open" is free to be emulated. Especially Open Source ones!
What this mean for open source software is that if I write a GPL library, and someone can't use GPL software and writes it's own implementation to be a drop-in replacement, it's free to do so. Which I believe is OK with everyone, except Oracle corporate rent-seekers, that can't get over the fact, that they can't monetize SUN Microsystems corpse even more.
> Which I believe is OK with everyone
What's the FSF's position on this, I wonder. The whole premise of the GPL as opposed to the LGPL is that even dynamic linking creates a derived work.
If someone creates a completely drop-in replacement for readline (I don't know if libedit and kin are drop-in or not) and releases it under a BSD license, there's no way to distinguish my app linking against one vs the other, I'm simply making use of the API in the abstract.
This isn't exactly the same as the Java case, but the copyright status of APIs per-se sure seems to have implication for the GPL's teeth.
Lets imagine that we create a third way to link software. There is static linking, dynamic linking, and now we got this imagined third thing called adaptive linking. In this made up linker, it magically combines the different parts and uses neural networks (ie, more magic) to figure out how to make the two parts communicate without a API.
Okey, in this fantasy world, do we still have the concept of derivative work? I would say Yes. Would thus GPL still apply? Yes. Is there an API? No.
GPL is not based on the technology of linking. As a software license, it used the concept of derivative work, distribution and other concept in copyright law to define the scope. LGPL in contrast do specify linking technology, but that is only an additional permission which would need to be modify if it were to function with new linking technologies.
If you created a drop-in replacement for readline, the argument that the complete work is readline + some code get weaker. However, if the police finds some emails on your drive that states your intention to combine readline + some code, and then go to copy readline by reimplemented the software in a identical (copy'ish) way, then you might very well be infringing on the right of the readline authors. It depend what a judge/jury think your intentions was.
It's an interesting thought experiment.
I agree that GPL doesn't get it's "teeth" unless linking creates a derivative work. The FSF (and Linus) for that matter have Opinions about what does,though, so I'm curious how and whether this ruling changes those.
I don't know whether to be thankful or not that there's still a circuit split in the US over what constitutes a derivative work in the software realm.
RMS and the FSF seem to be okay with copying header files.
see http://lkml.indiana.edu/hypermail/linux/kernel/0301.1/0362.h...
Came here to say this. What do they think POSIX is?
Yeah, the post confuses APIs with source code.
Wasn't there some alleged nine lines of actual code borrowed by Google? Some trivial "rangeCheck" function.
To laywers, that's a big deal. These are people who can be legally retained for just one dollar, after all.
It's honestly pretty difficult to take an Oracle lawyer's word on what would be good or bad for open source or free software.
I really wish that Google had bought Sun instead of Oracle. I worked at Sun up until 2007 and the feeling at Sun was very supportive of what Google was doing.
Oracle bought Sun's assets and they have every right to what they are doing. But a failed business effort to make additional fees is not, in my opinion, a risk to "free" software.
This is a decidedly non-factual account. In more detail:
> Google won a verdict that an unauthorized, commercial, competitive, harmful use of software in billions of products is fair use.
No, the only part of this description that is clearly correct is that Google won a verdict that its particular unauthorized commercial use (that the use was unauthorized and commercial are facts not in dispute) of Java APIs is "fair use". While the verdict required the jury to weigh whether and to what extent that use was harmful, a separate finding on that point was not made.
> No copyright expert would have ever predicted such a use would be considered fair.
IIRC, several copyright experts publicly did predict that, at least, a finding that the use in question was "fair use" was a reasonably likely outcome after the ruling that APIs were copyrightable in the first place.
> the free software movement itself now faces substantial jeopardy.
Certainly, any ruling which restricts the scope of copyright protection or finds broad fair use rights poses problems for enforcing the restriction of copyleft licenses, so, while I think the concern here is exaggerated greatly, there is some impact to the GPL.
OTOH, there's very little impact to the utility of permissive free software licenses in achieving the goals of said licenses.
> Google's narrative boiled down to this: because Java APIs have been open, any use of them was justified and all licensing restrictions should be disregarded. In other words, if you offer your software on an open and free basis, any use is fair use.
No, it didn't. Google's arguments included a lot of points, including arguing that Google's use of Java increased the commercial relevance of the Java, and boosted Oracle's business. They did not argue, at any point that I can find documented that free licensing made any use fair. This seems to be a pure invention.
> No business trying to commercialize software with any element of open software can afford to ignore this verdict. Dual licensing models are very common and have long depended upon a delicate balance between free use and commercial use.
While Hurst radically misrepresents both the substance of the verdict and the nature of the argument Google made in pursuit of it, there is some truth to this: certainly, firms relying on an extremely broad interpretation of the scope of copyright protection and an extremely narrow interpretation of the fair use exception in developing a business plan around dual licensing like the "copyleft or pay us" model, should carefully consider what impact actual rulings on the scope of copyright and fair use like this one have on their business models.
OTOH, lots of commercial software that has an element of open software don't rely on the restrictive nature of copyleft license as a means to upsell to commercial licenses, instead packaging additional features and/or professional services with commercial licenses (e.g., EDB's Postgres-based products.) These kinds of commercial open-core systems aren't particularly impacted.
> It is hard to see how GPL can survive such a result.
Well, sure, its hard to see how the GPL could survive the rule that Hurst fantasizes was applied here becoming generally accepted, where any use of any software under an open-source license was "fair use". But that has little bearing on reality.
Viewing the use of the Java APIs in this case as fair use might imply that some of the FSF's interpretation of where adherence to the GPL is required might be wrong, but this doesn't invalidate the GPL. (It might, if well-established in law, actually make the GPL more attractive for use, though it would no doubt be somewhat troubling to those who see the GPL as a wedge to force other and only tangentially-related software to be released under the same terms.)
> Nonetheless, Google exerts control over its APIs. Google prohibits copying of its APIs for competitive uses.
I can't see any evidence of Google either asserting that its APIs are protected or acting to prevent competitors from copying them. Is there any example of this?
> In fact, Google has in the past settled with the FTC over the manner in which it has restricted its APIs.
This is pure equivocation (using the same term, "API", for two different meanings.) What Google has settled with the FTC isn't over APIs-as-elements-of-intellectual-property, it was over APIs-as-specific-services. This has nothing to do with the APIs-as-IP issue in this case.
When a court finds API implementation to be fair use, there is an impact on free software, and that impact is basically positive. The idea of API's being copyrightable threatens the status of free software projects which implement ("clone") previously proprietary API's.
> When a court finds API implementation to be fair use, there is an impact on free software, and that impact is basically positive.
It certainly is positive for the ability to create new free software. It is negative for the ability to control other people's actions through copyleft licenses, since the same ability to create new free software also allows creating new permissive licensed or commercial software rather than adhering to the copyleft terms.
So, for some interpretations of the "Free Software Movement", there may be a net negative effect (though, again I should emphasize, nowhere near of the size or nature of that that Hurst is trying to paint.)
Agreed. As a point of practicality I can't think of anyone whose created 'commercial' open source who depends on copyright protection 'of the API' for their commercial elements though, can you?It certainly is positive for the ability to create new free software. It is negative for the ability to control other people's actions through copyleft licenses, since the same ability to create new free software also allows creating new permissive licensed or commercial software rather than adhering to the copyleft terms.It feels like the OSS ecosystem has always concluded that creating drop-in replacements using API's are 'fair use'.
Hurst's argument would be somewhat convincing if there were people trying to apply the GPL to prohibit, say, the Windows Subsystem for Linux (or other efforts to make Linux binaries run natively under Windows). I don't think it would be easy to find a consensus that that is appropriate or supported by the law, and indeed, there's been tons of concern that proprietary software copyright holders will try to sue people for writing new interoperable implementations that use the same protocol or API.
Maybe there are some narrower cases involving proprietary Linux kernel modules (which many people have suggested could be improper derived works that constitute copyright infringement of the kernel); there this result might make the infringement argument more difficult.
But as people here have pointed out, almost nobody ever attempts to limit implementation or use of APIs as a "work based on the program" for GPL purposes, almost nobody assumes that would be successful, and almost all uses of the GPL are based on limiting the literal copying of code from one program into another.