4 ms·

As it happens, this exact argument was put forth by the "at least one application program" that converted to free software: http://clisp.cvs.sourceforge.net/vi

• saurik 13y ago
  The court opinion stressed pretty strongly that Google's usage of the Java API was never actually intended to build an interoperable implementation (stating that Google was unable to point to any specific examples of code that would even be interoperable ;P) but instead to build a non-interoperable platform that was heavily inspired by the work that was put into Java. I think Google could have made a better case for attempting to be interoperable in certain ways (such as with libraries as opposed to "apps"), but apparently they didn't, and in fact came off quite strongly as trying to build their own unrelated-to-Java platform for various technical and business reasons. It still seems to be the case that if you are building a system whose goal is truly to be interoperable (such as libedit is to libreadline) you would not run into problems. For much more detailed commentary and argument (as well as quotes from the opinion), I encourage you to read my comment from that thread: https://news.ycombinator.com/item?id=7723853 https://news.ycombinator.com/item?id=7723853
  • zAy0LfpBZLC8mAC 13y ago
    I don't have a clue what Google's specific goals were, but couldn't an argument be made that compatibility with existing knowledge of developers is also a form of interoperability, and in particular one that needs to be protected from monopolization?
    • saurik 13y ago
      At that point copyright becomes meaningless (though if you are willing to go that far that's great: I don't see anything inherently incorrect about the position "copyright is meaningless"): "I needed my photograph to look like yours because everyone was familiar with yours and I wanted them to feel the same way as they did when they saw yours".
      • zAy0LfpBZLC8mAC 13y ago
        Well, yeah, I don't see much inherently meaningful in copyright either, in particular because drawing boundaries is ... difficult, to say the least. But I think your example still doesn't quite capture what I mean ... even though, well, maybe it does, but let me explain ;-): What I had in mind is in particular that getting familiar with an API requires effort, so it's kindof an investment on the part of the developer. After all, an API is as much a human/machine interface as it is a machine/machine interface. As such, it is problematic to allow anyone to have a monopoly on that investment, essentially a monopoly on the use of those developers' knowledge. And protection of investments is one of the arguments (the argument?) for interoperability exceptions--so, why only for machine/machine interoperability and not also for human/machine interoperability? I guess the "investment" aspect doesn't work that well for your example, but I still can see some value in the argument, in particular if you apply it to DRM (type) systems and culture in general.
        • saurik 13y ago
          For me, part of the difference is whether the interoperability is complete or fuzzy: I don't feel like you can be "only sort of interoperable", and that seems to be the big difference between the human/machine and machine/machine examples (it isn't that the interoperability is a different kind of interoperability, it is that it is a different level of precision in the kind of interoperability). A developer of will notice important differences in Java vs. Android. To explain some more with my photograph comment: the photograph might have taken time and context and thought on behalf of an entire population of viewers to come to some "meaning"; maybe this is more obvious if we take a storyline from a popular television show: before the show people didn't care about the topic of the show, but after the investment, quality, and success of the show now people really like that topics and in particular the story progression that went along with it. People are familiar with that story: to really allow those people to feel good about the new story, maybe it has to be similar to the old one? If you go down this path for a while, you start reading about idea/expression differences as they apply to literary and visual works: high-level plots and themes are not protected, but specific details and timelines are. The idea of organizing code into packages and classes is not, but the specific choice of what classes to put in what packages and what they are named are. FWIW, I personally feel like a lot of the benefit of trying to be "interoperable" with someone's perception of how to program is sufficient to be at that higher "idea" level: when I use C# or Objective-C (which in many ways feel similar to Java and in the case of C# was pretty much designed as a direct replacement for Java) I am highly familiar with them despite not feeling like they are the same: I gain a lot of the benefit of C# and Java having similar ideas, despite the fact that they clearly have different expressions. Now, that said? I continue to appreciate the idea that this is all a stupid distinction: but if you erase this distinction I am not certain where you still draw the line for claiming copyright on anything. Given the idea "investment in expression should be protected" (an admittedly-oversimplified version of "copyright"), I don't think you still have "investment by consumers in content should be inherently reusable by other creators". I could be wrong, however, and would love to hear more ideas.