4 ms·

Google's actions with Java's APIs were quite different from any other API implementation that I know of How were Google actions different from what the Apache

by jkn 11y ago

Google's actions with Java's APIs were quite different from any other API implementation that I know of How were Google actions different from what the Apache Foundation did with the Harmony project (which Google used for their Java implementation), or from any other API implementation? Is it just that the copyright holder eventually released a GPL version of the code while Google chose to stick with their own implementation? I don't see how that is relevant. API copyright being enforcable is huge for the industry, it means it was illegal for the Harmonly project to implement Java without a license, or for GNUStep to implement Cocoa, or for Mono to implement .NET Windows.Forms. Also 1991 Linux was probably illegal and Wine definitely is. These are just off the top of my head, just search for "open source implementation of" on Bing, chances are most of the results are about illegal projects, including open source implementation of various standards: standards don't necessarily come with a universal license grant, at least for patents (see e.g. the H.264 situation). I would be interested to know if things are different regarding copyright licenses.

pron 11y ago
> How were Google actions different from what the Apache Foundation did with the Harmony project The harmony project was intended as a drop-in replacement for JDK classes, namely as a component in a system interoperable with Java. Android is not such a system (although Android may yet be ruled to be fair-use, too). > it means it was illegal for the Harmony project to implement Java without a license, or for GNUStep to implement Cocoa, or for Mono to implement .NET Windows.Forms. Also 1991 Linux was probably illegal and Wine definitely is. That is the wrong conclusion. That something is copyrighted does not automatically mean that replicating it is illegal because of something called fair-use. If the goal of your implementation is to create an interoperable system, then you might be within your rights to implement an API even without complying with the license[1]. [1]: https://www.cs.duke.edu/courses/cps182s/fall02/cscopyright/Copyrights/Copyright-Fairuse.htm https://www.cs.duke.edu/courses/cps182s/fall02/cscopyright/C...
- jkn 11y ago
  Ah that is a good point. It's an important difference between Android on one side and Harmony, GNUStep and Wine on the other side. However I would put Linux together with Android then: Linux was similarly replicating Unix APIs for the convenience of compatibility with existing code, and explicitely not aiming for full interoperability. Octave is another project with an approach similar to Android: trying to provide an open-source Matlab that is mostly compatible, for convenience and to increase the appeal of the platform to Matlab developers, but they are not interested in compatibility for its own sake[1]. Mono falls in the middle, as they are not only providing an alternative runtime for .NET applications, they're also interesting in expanding the platform with new APIs such as POSIX bindings and Gtk#. [1] At least that was the case a few years ago. It might have changed lately. And this disinterest for full compatibily was partly due there being no "Matlab standard" to implement. See this post from 2000 by the Octave maintainer (https://lists.gnu.org/archive/html/help-octave/2000-12/msg00042.html https://lists.gnu.org/archive/html/help-octave/2000-12/msg00...): I never intended Octave to be a Matlab clone, nor am I really interested in creating such a thing, but that seems to be what many users of Octave want. It is not very interesting to me to simply reimplement all the features/bugs of Matlab. I am finding it too constraining to try to maintain almost any level of compatibility with a proprietary product for which there is no standard. It stifles any creativity by the threat of future incompatibility. I see this is as a real problem, not just an imagined one. Free software needs a vision beyond reimplementation of existing proprietary tools. Those of us who are interested in free software tools must become leaders rather than followers, and I am optimistic that this can happen for numerical software. But I don't believe it can happen if Octave continues down its current path.

by jkn 11y ago

pron 11y ago

> How were Google actions different from what the Apache Foundation did with the Harmony project The harmony project was intended as a drop-in replacement for JDK classes, namely as a component in a system interoperable with Java. Android is not such a system (although Android may yet be ruled to be fair-use, too). > it means it was illegal for the Harmony project to implement Java without a license, or for GNUStep to implement Cocoa, or for Mono to implement .NET Windows.Forms. Also 1991 Linux was probably illegal and Wine definitely is. That is the wrong conclusion. That something is copyrighted does not automatically mean that replicating it is illegal because of something called fair-use. If the goal of your implementation is to create an interoperable system, then you might be within your rights to implement an API even without complying with the license[1]. [1]: https://www.cs.duke.edu/courses/cps182s/fall02/cscopyright/Copyrights/Copyright-Fairuse.htm https://www.cs.duke.edu/courses/cps182s/fall02/cscopyright/C...

jkn 11y ago
Ah that is a good point. It's an important difference between Android on one side and Harmony, GNUStep and Wine on the other side. However I would put Linux together with Android then: Linux was similarly replicating Unix APIs for the convenience of compatibility with existing code, and explicitely not aiming for full interoperability. Octave is another project with an approach similar to Android: trying to provide an open-source Matlab that is mostly compatible, for convenience and to increase the appeal of the platform to Matlab developers, but they are not interested in compatibility for its own sake[1]. Mono falls in the middle, as they are not only providing an alternative runtime for .NET applications, they're also interesting in expanding the platform with new APIs such as POSIX bindings and Gtk#. [1] At least that was the case a few years ago. It might have changed lately. And this disinterest for full compatibily was partly due there being no "Matlab standard" to implement. See this post from 2000 by the Octave maintainer (https://lists.gnu.org/archive/html/help-octave/2000-12/msg00042.html https://lists.gnu.org/archive/html/help-octave/2000-12/msg00...): I never intended Octave to be a Matlab clone, nor am I really interested in creating such a thing, but that seems to be what many users of Octave want. It is not very interesting to me to simply reimplement all the features/bugs of Matlab. I am finding it too constraining to try to maintain almost any level of compatibility with a proprietary product for which there is no standard. It stifles any creativity by the threat of future incompatibility. I see this is as a real problem, not just an imagined one. Free software needs a vision beyond reimplementation of existing proprietary tools. Those of us who are interested in free software tools must become leaders rather than followers, and I am optimistic that this can happen for numerical software. But I don't believe it can happen if Octave continues down its current path.