5 ms·

If you change the API design in any way, it no longer fulfills its purpose - interoperating with other software that uses that API. Hence, API design is functio

by jbri 14y ago

If you change the API design in any way, it no longer fulfills its purpose - interoperating with other software that uses that API. Hence, API design is functional. However, you can change the design of a piece of software (for example, a user interface) while having it still be able to fulfill its purpose. So in the general case, software design is not necessarily strictly functional.

mehdim 14y ago
Some thoughts between facts, compilation and original work of authorship http://en.wikibooks.org/wiki/US_Copyright_Law/Copyrightable_Works http://en.wikibooks.org/wiki/US_Copyright_Law/Copyrightable_... Does a orignal list of URLs is copyrightable? If you follow the copyritht , yes. But an other URL compilation of the same API which would be a kind of "list" (alphabetical for example) would not... In all cases, if original URLs lists are copyrightable, Google results too are under copyright, because they are sorted by pagerank, which is an orginal way to sort links...
josephlord 14y ago
I up voted both you an AnthonyMouse for good clarifying comments that move the debate forward. Do you think it is then legitimate to partially copy an API making sufficient changes for it to be largely incompatible (certainly not a drop in replacement)? In this scenario the functional element is lost in the copy but not the creative element.
- AnthonyMouse 14y ago
  I assume you're referring to what Google did, i.e. implementing a subset of the API but not the whole thing. But in that case I wouldn't agree that the functional element is lost. It continues to exist exactly to the extent that they copied the API -- the functions they copied are compatible. Any code using those functions will compile against both. (Incidentally, it feels like a very strange argument for Oracle to say that the problem with what Google did is that they didn't copy enough.) I suppose you could argue that it's theoretically possible to copy the creative elements from an API while specifically setting out to break all compatibility, but it's hard to say what that would even look like. You can't break compatibility without changing the function signatures, but if you change substantially all of the function signatures then it's arguably a completely independent API. More importantly, it seems like this would be more of a theoretical problem than one seen in practice -- the only practical reason to copy an API is to achieve partial or complete compatibility. Can you provide any example of an API being copied for reasons other than achieving compatibility?
  - josephlord 14y ago
    What Google did is an interesting example but at least jbri's comment referred to breaking functionality if you changed it at all so it needed to be copied. Oracle did make the point that Google didn't copy enough for compatibility and Write Once Run Anywhere effectively forking their entire ecosystem/platform without a license. It has killed Java on mobile (although maybe it would have happened anyway and maybe it is a good thing with Oracle running the show). I think that if the participants in the case hadn't been the most hated and loved companies in tech many people might have had a different view of the case. There are a number of other reasons for copying an API than compatibility. 1) Its an efficient (lazy?) way to get to a well designed API without you having to do multiple rounds of iterative design as users hammer on it over several years. 2) Existing documentation can be used. [Documentation, tutorials StackOverflow answers]. 3) Users are already familiar with it. It seems to me that Google did a pretty vicious embrace, extend, extinguish on mobile Java and they may still be the better custodians of the platform but I'm not sure the behaviour is actually acceptable in general. They took maximum benefit from Sun's efforts to create a platform and a community and give the absolute minimum back. Just imagine if it was Microsoft (or even Apple) in the Google roll and old Sun (rather than Oracle) in the Oracle roll - would you still feel the same about the case? Now does this mean I want to be locked into a provider unable to find an alternative implementer of a required library - absolutely not. But that is a factor to consider when adopting a platform/library as a cost to be weighed against the benefits. I always like an exit option or accept significant risk if I don't have one. Obviously API developers could offer permissive licenses to the API even if the library itself is closed source as a way to reassure customers and gain business. I'm not sure law is required OR desirable in this area.
    - AnthonyMouse 14y ago
      >There are a number of other reasons for copying an API than compatibility. All three of the ones you listed are just advantages of compatibility. You don't get any of them exactly to the extent that you aren't compatible. >Just imagine if it was Microsoft (or even Apple) in the Google roll and old Sun (rather than Oracle) in the Oracle roll - would you still feel the same about the case? Sure. Because the problem you're implying would occur is completely different to the question of copyright over APIs. People object to Microsoft's EEE because it's anticompetitive -- if it's to be illegal then it should be as an antitrust violation, not a copyright violation. Which is why many people don't object to what Google has done -- they're not using it as lock in. It's open source and you can port their VM to whatever platform you like and run all the same user code. The only reason you can't run all the Android apps on an iPhone is that Apple doesn't allow it. I believe RIM actually offered it as a feature for about five minutes before they realized they also used Oracle Java(TM) and were too busy going out of business to be fighting with Oracle over license terms. Moreover, it's bad policy to allow copying when the implementation is perfectly compatible but not when it isn't. It says to the small developer that they can't just patch Kerberos to do the thing they need to talk to Microsoft software, they have to reimplement all of Active Directory. And if the implementation adds anything useful then it's not compliant and they're infringing copyright. Ditto if there are any bugs or the reimplementation lacks bugs present in the original. API forks are not inherently evil. Making them copyright violations makes them inherently prohibited. Better to prohibit the things that actually are evil, like EEE for anticompetitive purposes.

by jbri 14y ago

mehdim 14y ago

Some thoughts between facts, compilation and original work of authorship http://en.wikibooks.org/wiki/US_Copyright_Law/Copyrightable_Works http://en.wikibooks.org/wiki/US_Copyright_Law/Copyrightable_... Does a orignal list of URLs is copyrightable? If you follow the copyritht , yes. But an other URL compilation of the same API which would be a kind of "list" (alphabetical for example) would not... In all cases, if original URLs lists are copyrightable, Google results too are under copyright, because they are sorted by pagerank, which is an orginal way to sort links...

josephlord 14y ago

I up voted both you an AnthonyMouse for good clarifying comments that move the debate forward. Do you think it is then legitimate to partially copy an API making sufficient changes for it to be largely incompatible (certainly not a drop in replacement)? In this scenario the functional element is lost in the copy but not the creative element.

AnthonyMouse 14y ago
I assume you're referring to what Google did, i.e. implementing a subset of the API but not the whole thing. But in that case I wouldn't agree that the functional element is lost. It continues to exist exactly to the extent that they copied the API -- the functions they copied are compatible. Any code using those functions will compile against both. (Incidentally, it feels like a very strange argument for Oracle to say that the problem with what Google did is that they didn't copy enough.) I suppose you could argue that it's theoretically possible to copy the creative elements from an API while specifically setting out to break all compatibility, but it's hard to say what that would even look like. You can't break compatibility without changing the function signatures, but if you change substantially all of the function signatures then it's arguably a completely independent API. More importantly, it seems like this would be more of a theoretical problem than one seen in practice -- the only practical reason to copy an API is to achieve partial or complete compatibility. Can you provide any example of an API being copied for reasons other than achieving compatibility?
- josephlord 14y ago
  What Google did is an interesting example but at least jbri's comment referred to breaking functionality if you changed it at all so it needed to be copied. Oracle did make the point that Google didn't copy enough for compatibility and Write Once Run Anywhere effectively forking their entire ecosystem/platform without a license. It has killed Java on mobile (although maybe it would have happened anyway and maybe it is a good thing with Oracle running the show). I think that if the participants in the case hadn't been the most hated and loved companies in tech many people might have had a different view of the case. There are a number of other reasons for copying an API than compatibility. 1) Its an efficient (lazy?) way to get to a well designed API without you having to do multiple rounds of iterative design as users hammer on it over several years. 2) Existing documentation can be used. [Documentation, tutorials StackOverflow answers]. 3) Users are already familiar with it. It seems to me that Google did a pretty vicious embrace, extend, extinguish on mobile Java and they may still be the better custodians of the platform but I'm not sure the behaviour is actually acceptable in general. They took maximum benefit from Sun's efforts to create a platform and a community and give the absolute minimum back. Just imagine if it was Microsoft (or even Apple) in the Google roll and old Sun (rather than Oracle) in the Oracle roll - would you still feel the same about the case? Now does this mean I want to be locked into a provider unable to find an alternative implementer of a required library - absolutely not. But that is a factor to consider when adopting a platform/library as a cost to be weighed against the benefits. I always like an exit option or accept significant risk if I don't have one. Obviously API developers could offer permissive licenses to the API even if the library itself is closed source as a way to reassure customers and gain business. I'm not sure law is required OR desirable in this area.
  - AnthonyMouse 14y ago
    >There are a number of other reasons for copying an API than compatibility. All three of the ones you listed are just advantages of compatibility. You don't get any of them exactly to the extent that you aren't compatible. >Just imagine if it was Microsoft (or even Apple) in the Google roll and old Sun (rather than Oracle) in the Oracle roll - would you still feel the same about the case? Sure. Because the problem you're implying would occur is completely different to the question of copyright over APIs. People object to Microsoft's EEE because it's anticompetitive -- if it's to be illegal then it should be as an antitrust violation, not a copyright violation. Which is why many people don't object to what Google has done -- they're not using it as lock in. It's open source and you can port their VM to whatever platform you like and run all the same user code. The only reason you can't run all the Android apps on an iPhone is that Apple doesn't allow it. I believe RIM actually offered it as a feature for about five minutes before they realized they also used Oracle Java(TM) and were too busy going out of business to be fighting with Oracle over license terms. Moreover, it's bad policy to allow copying when the implementation is perfectly compatible but not when it isn't. It says to the small developer that they can't just patch Kerberos to do the thing they need to talk to Microsoft software, they have to reimplement all of Active Directory. And if the implementation adds anything useful then it's not compliant and they're infringing copyright. Ditto if there are any bugs or the reimplementation lacks bugs present in the original. API forks are not inherently evil. Making them copyright violations makes them inherently prohibited. Better to prohibit the things that actually are evil, like EEE for anticompetitive purposes.