6 ms·

>If companies can copyright an API and block competitors from implementing it, that would be very detrimental to the industry as a whole, for the sake of a few

by curt15 8y ago

>If companies can copyright an API and block competitors from implementing it, that would be very detrimental to the industry as a whole, for the sake of a few rent seekers profiting. The practice of writing drop-in replacements for software products is as old as the software industry, even those replacements that diminish the original product's commercial value. E.g gnu/linux vs proprietary unix.

cbhl 8y ago
And imagine how different the world would be if Microsoft Word couldn't just read/write WordPerfect files by reverse-engineering them?
- brianberns 8y ago
  Reverse engineering a file format is different from reimplementing an API.
  - ummonk 8y ago
    In what way?
    - KingMachiavelli 8y ago
      The crux of re-implementing an API is that the name and structure of the replacement has to be the same otherwise it won't work as a drop in replacement. If I reverse engineer a file format I don't have to name any of my code the same as the original or structure it in the same way.
      - ummonk 8y ago
        You need to structure any files you read or write to the exact same way or they won't be compatible with the other software. File formats are directly analogous to APIs.
      - ndnxhs 8y ago
        A file format is just an api that gets saved to the drive. Many file formats are just json/XML files in a renamed zip
        treis 8y ago
        Except that you don't have a copy of a file format in your code. The code you have reads and writes to the format and does not need to be a copy.
        candiodari 8y ago
        True, but there's many parts that you do have to copy into your source code: * magic numbers at the start of the file format * all sorts of enums that you just have to know, names and numbers and the correspondence between them * names of data types and classes are often needed * there are often many "standard" things that will be in both the original source and the duplicate because it's the industry standard (things like bold text in any word format or parallel constraints in cad files). They will mostly match in all programs of the same time And that's just the beginning. You could make an argument that all of those fall under copyright. And they shouldn't. So it really isn't that far from an API.
        treis 8y ago
        If you copyright all those things then you aren't copyrighting the file format. You're copyrighting a bunch of code you wrote to read/write the format. Which (virtually) everyone agrees is something subject to copyright.
        monocasa 8y ago
        If you copyright the magic numbers and xml tag names, how can anyone write a competing implementation?
        treis 8y ago
        You can't copyright something as simple as a number or tag names.
pron 8y ago
Writing drop-in replacements may very well fall under fair use and be allowed, but this is not what happened in this particular case the court ruled on: > It was not ... intended to permit third party interoperability, since Google had made no substantial efforts to use them for the purpose of third party interoperability. (In fact it found that Google had tried to prevent interoperability with other Java and had previously been refused a license by Sun for that reason.) It was not transformative in the sense of a new platform either, since other Java smartphones predated Android. https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc.#Appeals_Court_and_finding_of_non-fair-use https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google...
kadendogthing 8y ago
Google didn't do this to be interoperable. There is no set of software interoperable with Android's Java runtime. Not even the court bought this argument, because not only is it ridiculous on its face, but it's technically not true. Why do people involved in tech keep repeating this?
- sangnoir 8y ago
  > Google didn't do this to be interoperable. This is a bold claim - but I suspect your definition of "interoperable" is stricter than common usage (i.e. executable) > There is no set of software interoperable with Android's Java runtime. Countless 3rd party libraries are interoperable with Android - the few that aren't probably rely on sun.* - I suspect google did do this to be interoperable with 3rd party libraries as well as Java developers' mental model of where to find things.
  - kadendogthing 8y ago
    >This is a bold claim No it's not. Google even conceded this in court.
- int_19h 8y ago
  Regardless of why Google did this, it does offer some interoperability - you can write Java libraries that compile and work on both J2SE and Android. That is valuable.

by curt15 8y ago

cbhl 8y ago

And imagine how different the world would be if Microsoft Word couldn't just read/write WordPerfect files by reverse-engineering them?

brianberns 8y ago
Reverse engineering a file format is different from reimplementing an API.
- ummonk 8y ago
  In what way?
  - KingMachiavelli 8y ago
    The crux of re-implementing an API is that the name and structure of the replacement has to be the same otherwise it won't work as a drop in replacement. If I reverse engineer a file format I don't have to name any of my code the same as the original or structure it in the same way.
    - ummonk 8y ago
      You need to structure any files you read or write to the exact same way or they won't be compatible with the other software. File formats are directly analogous to APIs.
    - ndnxhs 8y ago
      A file format is just an api that gets saved to the drive. Many file formats are just json/XML files in a renamed zip
      - treis 8y ago
        Except that you don't have a copy of a file format in your code. The code you have reads and writes to the format and does not need to be a copy.
        candiodari 8y ago
        True, but there's many parts that you do have to copy into your source code: * magic numbers at the start of the file format * all sorts of enums that you just have to know, names and numbers and the correspondence between them * names of data types and classes are often needed * there are often many "standard" things that will be in both the original source and the duplicate because it's the industry standard (things like bold text in any word format or parallel constraints in cad files). They will mostly match in all programs of the same time And that's just the beginning. You could make an argument that all of those fall under copyright. And they shouldn't. So it really isn't that far from an API.
        treis 8y ago
        If you copyright all those things then you aren't copyrighting the file format. You're copyrighting a bunch of code you wrote to read/write the format. Which (virtually) everyone agrees is something subject to copyright.
        monocasa 8y ago
        If you copyright the magic numbers and xml tag names, how can anyone write a competing implementation?
        treis 8y ago
        You can't copyright something as simple as a number or tag names.

pron 8y ago

Writing drop-in replacements may very well fall under fair use and be allowed, but this is not what happened in this particular case the court ruled on: > It was not ... intended to permit third party interoperability, since Google had made no substantial efforts to use them for the purpose of third party interoperability. (In fact it found that Google had tried to prevent interoperability with other Java and had previously been refused a license by Sun for that reason.) It was not transformative in the sense of a new platform either, since other Java smartphones predated Android. https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc.#Appeals_Court_and_finding_of_non-fair-use https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google...

kadendogthing 8y ago

Google didn't do this to be interoperable. There is no set of software interoperable with Android's Java runtime. Not even the court bought this argument, because not only is it ridiculous on its face, but it's technically not true. Why do people involved in tech keep repeating this?

sangnoir 8y ago
> Google didn't do this to be interoperable. This is a bold claim - but I suspect your definition of "interoperable" is stricter than common usage (i.e. executable) > There is no set of software interoperable with Android's Java runtime. Countless 3rd party libraries are interoperable with Android - the few that aren't probably rely on sun.* - I suspect google did do this to be interoperable with 3rd party libraries as well as Java developers' mental model of where to find things.
- kadendogthing 8y ago
  >This is a bold claim No it's not. Google even conceded this in court.
int_19h 8y ago
Regardless of why Google did this, it does offer some interoperability - you can write Java libraries that compile and work on both J2SE and Android. That is valuable.