4 ms·

This blog post is laundering history. The choice quote: "With smartphone apps now common, we sometimes forget how hard it once was for developers to build apps

This blog post is laundering history. The choice quote: "With smartphone apps now common, we sometimes forget how hard it once was for developers to build apps across a wide range of different platforms. Our 2008 release of the open-source Android platform changed the game." This could be equally said of Java itself, a good eight to ten years prior, which brought a serviceable userland onto desktops of all kinds, mobile phones of the day, and embedded devices too. They lifted that API to bootstrap the developer ecosystem for Android after their efforts to license Java from Sun failed, and did a different cleanroom implementation underneath. In the gold rush to develop Android apps, their frozen-in-time copy of the Java ecosystem rose to prominence and sought-after Java libraries were held back for years to lag behind official Java's versions. Differences between Android's facsimile of Java and real Java (from plenty of other vendors) caused confusion and divergence to the Java ecosystem, as Oracle's own efforts to leverage Java faltered too. Android's popularity de facto forked Java for years and did so without the permission of the rightsholder. If the copyrightability of APIs isn't the answer we want in the field, what instrument do we need to prevent the same from happening to other products too?

ori_b 8y ago
> what instrument do we need to prevent the same from happening to other products too? ...We don't need such an instrument, because the outcome you mentioned is desirable. If we had such an instrument, Linux would not have been possible, because it's compatible with the Unix APIs. OSX would not have been possible, for the same reasons.
- temp-dude-87844 8y ago
  The difference between a blob storage system that implements an "S3-compatible" API, and AWS S3, is that no one is mistaking the other offering for S3. Dozens of libraries that implement the S3 API as a client, and offerings that implement it in the server aren't under pressure to diverge between fake S3 and real S3, because the API is feature-complete, and doesn't change in meaningful ways. There may be monetary harm to S3 from the competitor cloning their API and competing with them on price, but there is no reputational harm to S3. It would be revisionist to claim that there was no reputational harm done to official Java by Android's lookalike Java -- irrespective of any mismanagement by Oracle of the Java platform. How does one prevent that?
  - scarhill 8y ago
    Copyright law has nothing to do with "reputational harm," assuming Java in fact suffered any.
  - toyg 8y ago
    “Reputational harm” comes from trademark infringement, not copyright. And no, you cannot prevent this sort of scenario without losing the right to interoperate with most software.
- tzs 8y ago
  > If we had such an instrument, Linux would not have been possible, because it's compatible with the Unix APIs. OSX would not have been possible, for the same reasons. Technically, OS X would be possible, because it is not merely Unix compatible. It is a Unix [1]. [1] https://www.opengroup.org/openbrand/register/brand3648.htm https://www.opengroup.org/openbrand/register/brand3648.htm
  - monocasa 8y ago
    They only own Unix the trademark. Unix the copyright is a much more muddy concept that'd probably lead to another trial between Novell and SCO. If SCO won they'd totally go after all the Linux and BSD variants too.
sangnoir 8y ago
> we sometimes forget how hard it once was for developers to build apps across a wide range of different platforms. I take it you never had the misfortune of developing for J2ME? The blog is laundering history - by severely understating the horror of how it was before: CLDC/MIDP combined with model-specific vendor extensions (E250 would have different packages from other models by the same manufacturer), add non-standardized screen resolution resulted in your apps compatibility matrix having to be in 4-dimensions, at the very least.

ori_b 8y ago

> what instrument do we need to prevent the same from happening to other products too? ...We don't need such an instrument, because the outcome you mentioned is desirable. If we had such an instrument, Linux would not have been possible, because it's compatible with the Unix APIs. OSX would not have been possible, for the same reasons.

temp-dude-87844 8y ago
The difference between a blob storage system that implements an "S3-compatible" API, and AWS S3, is that no one is mistaking the other offering for S3. Dozens of libraries that implement the S3 API as a client, and offerings that implement it in the server aren't under pressure to diverge between fake S3 and real S3, because the API is feature-complete, and doesn't change in meaningful ways. There may be monetary harm to S3 from the competitor cloning their API and competing with them on price, but there is no reputational harm to S3. It would be revisionist to claim that there was no reputational harm done to official Java by Android's lookalike Java -- irrespective of any mismanagement by Oracle of the Java platform. How does one prevent that?
- scarhill 8y ago
  Copyright law has nothing to do with "reputational harm," assuming Java in fact suffered any.
- toyg 8y ago
  “Reputational harm” comes from trademark infringement, not copyright. And no, you cannot prevent this sort of scenario without losing the right to interoperate with most software.
tzs 8y ago
> If we had such an instrument, Linux would not have been possible, because it's compatible with the Unix APIs. OSX would not have been possible, for the same reasons. Technically, OS X would be possible, because it is not merely Unix compatible. It is a Unix [1]. [1] https://www.opengroup.org/openbrand/register/brand3648.htm https://www.opengroup.org/openbrand/register/brand3648.htm
- monocasa 8y ago
  They only own Unix the trademark. Unix the copyright is a much more muddy concept that'd probably lead to another trial between Novell and SCO. If SCO won they'd totally go after all the Linux and BSD variants too.

sangnoir 8y ago

> we sometimes forget how hard it once was for developers to build apps across a wide range of different platforms. I take it you never had the misfortune of developing for J2ME? The blog is laundering history - by severely understating the horror of how it was before: CLDC/MIDP combined with model-specific vendor extensions (E250 would have different packages from other models by the same manufacturer), add non-standardized screen resolution resulted in your apps compatibility matrix having to be in 4-dimensions, at the very least.