This is very bad news. I think this effectively makes GNUstep (and many other similar projects) infringing now.
There was a period of time in the GNOME community where we had some really high quality applications that were best in class: Banshee, F-Spot, and Tomboy. They fell out of favour because some folks felt that eventually Mono would some day be deemed infringing or patent violating and that using it should be avoided.
At the time I thought it was a bit ridiculous and paranoid. I think this ruling means Stallman was right (again).
The irony is here Mono is actually safe - Microsoft extensively uses it themselves and de facto owns it after buying out Xamarin. (I really hated the old Mono FUD, because the FUD held it back for years, as well as Gnome’s applicationsm)
Really, if Mono et al is unsafe, then things like the Linux kernel are unsafe, especially as they implement ABIs and APIs originally implemented by proprietary systems. And now, with the fallout of this lawsuit…
The Mono FUD really annoyed me, too, and now retroactively annoys me because the state of desktop applications is dire. Mono spawned a few applications, some of which I named above, that were best in class and the developers seemed to be able to move really quickly. The Mono FUD caused people to go back to the “less good” mechanisms for writing desktop applications.
And now the “recommended” way to develop GNOME applications is apparently JavaScript, and now I don’t even know whether I should computer at all anymore. :/
The Mono FUD really annoyed me, too, and now retroactively annoys me because the state of desktop applications is dire. Mono spawned a few applications, some of which I named above, that were best in class and the developers seemed to be able to move really quickly. The Mono FUD caused people to go back to the “less good” mechanisms for writing desktop applications.
And now the “recommended” way to develop GNOME applications is apparently JavaScript, and now I don’t even know whether I should computer at all anymore. :/
In 2010, Oracle sued Google. In 2012, District Court ruled API uncopyrightable. In 2014, Appeals Court ruled API copyrightable. Google petitioned Supreme Court, which denied the petition. In 2016, District Court, operating under the assumption that API is copyrightable, ruled Google’s use was fair use. In 2018, Appeals Court ruled Google’s use was not fair use. Now the case is back in District Court to determine the damage, operating under the assumption that API is copyrightable and Google’s use was not fair use.
Google has appealed again, but if the court decides in favor of Oracle, basically any open source software that mimics the API of something closed-source will be in trouble. Linux, various GNU libraries, and so on, all implement numerous classic Unix interfaces. It would render essentially the entire Linux ecosystem (and likely most other open source operating systems) as infringing.
Not necessarily. Remember that the EU has specifically written into their copyright law that APIs (and anything needed for interoperability) are not subject to any copyright protection (This, incidentally, is why EU law generally considers GPL and LGPL identical, as the linking restriction would violate this rule, and this is also why the EUPL 1.2 is compatible with MPL, LGPL, GPL, and more).
So projects such as VLC (and with that, ffmpeg) which are legally in the EU, or the entire KDE suite, aren’t affected.
This was also used by LibreOffice/OpenOffice/StarOffice when it was originally created by reverse engineering the Microsoft Office formats, because StarOffice was developed in Germany, and also didn’t have to worry about US copyright law.
If I recall correctly (but don’t quote me on this), some parts of the WINE project were also based on reverse engineered Windows code that was reversed in the EU for similar reasons, but for compliance with US law, these parts were later replaced by untainted code.
Clean-room reverse engineering is known to be legally safe in the US. We rely on this for GNU Octave, since we are implementing the Matlab language.
(I get a general air of snobbery from Europeans about how stupid US law is and how enlightened and less onerous European law is, but I don’t think this is generally true.)
Clean-room reverse engineering is known to be legally safe in the US.
Making a compatible product through reverse engineering is exactly the kind of thing the API ruling makes me worry about. It seems like it was intended to bolster profitable lock-in in the long-term.
In Europe the recitals 10 and 15 of the Directive 2009/24/EC on the protection of computer programs seems to invalidate the idea of “strong copyleft”: any portion of code that is strictly necessary for implementing interoperability can be reproduced without copyright infringement. This means that linking cannot be submitted to conditions or restricted by a so-called “strong copyleft licence”. As a consequence, linking two programs does not produce a single derivative of both (each program stay covered by its primary licence). Therefore the EUPL v1.1 and v1.2 are copyleft (or share-alike) for protecting the covered software only from exclusive appropriation, but it is without pretention for any “viral extension” to other software in case of linking.
Thanks! They seem to be arguing that interoperability allows you to use an API, but they seem cautious to assert this unequivocally (“it seems that”). It looks like the actual case is still untested in courts, both in the EU and the US, and I don’t know of anyone who has tried to challenge it by linking to GPLed programs in Europe and not releasing their own code under a compatible license.
I would be cautious, therefore, to assert that this means the LGPL and the GPL are equivalent in Europe (I am also not a lawyer), unless it becomes a well-established legal consensus there, which doesn’t seem to be the case so far.
It will definitely be messy, but (IANAL) Caldera (SCO) released ancient UNIX under a BSD license [1]. Since the BSD license and the GPL are compatible, wouldn’t it simply be a matter of adding the Caldera copyright notice/license?
Also, there is the deal between USL and BSDi/University of California that basically cleared BSD-Lite. So, there is the similar option there to make APIs BSD-derived?
Of course, System V-based APIs may be a different story altogether.
This is very bad news. I think this effectively makes GNUstep (and many other similar projects) infringing now.
There was a period of time in the GNOME community where we had some really high quality applications that were best in class: Banshee, F-Spot, and Tomboy. They fell out of favour because some folks felt that eventually Mono would some day be deemed infringing or patent violating and that using it should be avoided.
At the time I thought it was a bit ridiculous and paranoid. I think this ruling means Stallman was right (again).
Andrew’s law: Those who don’t believe Richard Stallman will eventually have a red face from face palming so hard.
The irony is here Mono is actually safe - Microsoft extensively uses it themselves and de facto owns it after buying out Xamarin. (I really hated the old Mono FUD, because the FUD held it back for years, as well as Gnome’s applicationsm)
Really, if Mono et al is unsafe, then things like the Linux kernel are unsafe, especially as they implement ABIs and APIs originally implemented by proprietary systems. And now, with the fallout of this lawsuit…
The Mono FUD really annoyed me, too, and now retroactively annoys me because the state of desktop applications is dire. Mono spawned a few applications, some of which I named above, that were best in class and the developers seemed to be able to move really quickly. The Mono FUD caused people to go back to the “less good” mechanisms for writing desktop applications.
And now the “recommended” way to develop GNOME applications is apparently JavaScript, and now I don’t even know whether I should computer at all anymore. :/
The Mono FUD really annoyed me, too, and now retroactively annoys me because the state of desktop applications is dire. Mono spawned a few applications, some of which I named above, that were best in class and the developers seemed to be able to move really quickly. The Mono FUD caused people to go back to the “less good” mechanisms for writing desktop applications.
And now the “recommended” way to develop GNOME applications is apparently JavaScript, and now I don’t even know whether I should computer at all anymore. :/
What happened? Did Oracle find a judge who does not know programming?
In 2010, Oracle sued Google. In 2012, District Court ruled API uncopyrightable. In 2014, Appeals Court ruled API copyrightable. Google petitioned Supreme Court, which denied the petition. In 2016, District Court, operating under the assumption that API is copyrightable, ruled Google’s use was fair use. In 2018, Appeals Court ruled Google’s use was not fair use. Now the case is back in District Court to determine the damage, operating under the assumption that API is copyrightable and Google’s use was not fair use.
Most people do not understand the significance of this decision, so it’s enough for Oracle to re-roll the dice until they get the answer they want.
Besides I think the crowds inflate the significance of this. It’s almost as if somebody unconditionally respected copyrights here.
Google has appealed again, but if the court decides in favor of Oracle, basically any open source software that mimics the API of something closed-source will be in trouble. Linux, various GNU libraries, and so on, all implement numerous classic Unix interfaces. It would render essentially the entire Linux ecosystem (and likely most other open source operating systems) as infringing.
Not necessarily. Remember that the EU has specifically written into their copyright law that APIs (and anything needed for interoperability) are not subject to any copyright protection (This, incidentally, is why EU law generally considers GPL and LGPL identical, as the linking restriction would violate this rule, and this is also why the EUPL 1.2 is compatible with MPL, LGPL, GPL, and more).
So projects such as VLC (and with that, ffmpeg) which are legally in the EU, or the entire KDE suite, aren’t affected.
This was also used by LibreOffice/OpenOffice/StarOffice when it was originally created by reverse engineering the Microsoft Office formats, because StarOffice was developed in Germany, and also didn’t have to worry about US copyright law.
If I recall correctly (but don’t quote me on this), some parts of the WINE project were also based on reverse engineered Windows code that was reversed in the EU for similar reasons, but for compliance with US law, these parts were later replaced by untainted code.
Are you a lawyer? I am not seeing a precedent that the GPL’s strong copyleft is untenable in the EU. For example, the VMWare case seems to rely on the copyleft of the GPL in a way that the LGPL would not have, right?
The strong copyleft of the GPL in the US does not rely on copyrightability of APIs, I have heard people say.
This FOSDEM talk also suggests that the GPL is quite strong.
Clean-room reverse engineering is known to be legally safe in the US. We rely on this for GNU Octave, since we are implementing the Matlab language.
(I get a general air of snobbery from Europeans about how stupid US law is and how enlightened and less onerous European law is, but I don’t think this is generally true.)
Making a compatible product through reverse engineering is exactly the kind of thing the API ruling makes me worry about. It seems like it was intended to bolster profitable lock-in in the long-term.
I am not a lawyer, but the authors of the EUPL (who are lawyers) have written about this situation, and declared that they believe it is the case.
I was looking for this interpretation from the EUPL authors, but couldn’t find it. Can you show it to me?
See https://joinup.ec.europa.eu/page/eupl-compatible-open-source-licences#section-3 and https://joinup.ec.europa.eu/page/eupl-compatible-open-source-licences#section-4
Thanks! They seem to be arguing that interoperability allows you to use an API, but they seem cautious to assert this unequivocally (“it seems that”). It looks like the actual case is still untested in courts, both in the EU and the US, and I don’t know of anyone who has tried to challenge it by linking to GPLed programs in Europe and not releasing their own code under a compatible license.
I would be cautious, therefore, to assert that this means the LGPL and the GPL are equivalent in Europe (I am also not a lawyer), unless it becomes a well-established legal consensus there, which doesn’t seem to be the case so far.
It will definitely be messy, but (IANAL) Caldera (SCO) released ancient UNIX under a BSD license [1]. Since the BSD license and the GPL are compatible, wouldn’t it simply be a matter of adding the Caldera copyright notice/license?
Also, there is the deal between USL and BSDi/University of California that basically cleared BSD-Lite. So, there is the similar option there to make APIs BSD-derived?
Of course, System V-based APIs may be a different story altogether.
[1] http://www.lemis.com/grog/UNIX/
[2] https://en.wikipedia.org/wiki/UNIX_System_Laboratories,_Inc._v._Berkeley_Software_Design,_Inc.#Terms_of_the_settlement
This case is one reason Ive promoted Wirth’s languages for mobile a lot. Could be one of the only things that’s memory- and legally-safe. ;)
A Wirth language is not very useful if it can’t use any system APIs, because they are all in copyright violation ;).
I meant with their own API’s. You’d do this at the start of Android.
Aren’t most if not all of those ‘classic unix interfaces’ defined somewhere in the POSIX standard?