3 ms·

You're drawing lines in places that best serve your position, rather than considering the whole landscape. "Whole" in the sense of "the whole is more than the

You're drawing lines in places that best serve your position, rather than considering the whole landscape. "Whole" in the sense of "the whole is more than the sum of its parts" is not generally understood to imply the maximal possible scope in any given context. It's simply meant to meant to talk about how the identify an aggregation (of no particular scale) relates to the identities of its individual components. Similarly, the API/not-API distinction is one that has to be made in contexts beyond just the relationship of function signatures to function implementations. Foo was declared as a public class, but was it meant for public consumption? Or is it intended for internal use, and was only declared public because, for practical reasons, it couldn't be declared package-private? Moreover, there are certainly rational distinctions that could be drawn, but that does not mean that they are legally relevant. The issue at hand really doesn't have anything at all to do with how programmers understand things. The law is not what we think is right, the law is what is written in the books.

AnthonyMouse 6y ago
> "Whole" in the sense of "the whole is more than the sum of its parts" is not generally understood to imply the maximal possible scope in any given context. It's simply meant to meant to talk about how the identify an aggregation (of no particular scale) relates to the identities of its individual components. Which is how I'm using it. An API that consists of two functions and one that consists of a billion functions have completely different scales but each whole unit has an API portion and an implementation portion. And the API portion is the recipe. It's a purely factual description of what the implementation is expected to do. > Similarly, the API/not-API distinction is one that has to be made in contexts beyond just the relationship of function signatures to function implementations. Foo was declared as a public class, but was it meant for public consumption? Or is it intended for internal use, and was only declared public because, for practical reasons, it couldn't be declared package-private? That doesn't affect whether the API parts of it are API parts, only whether the API is regarded as internal or not, which shouldn't be relevant to copyright. Internal APIs shouldn't be copyrightable either. > The issue at hand really doesn't have anything at all to do with how programmers understand things. It better, or you're in real trouble, because then all you have are meaningless zeros and ones.
- imtringued 6y ago
  An API is an invisible thing. It's not in the code. It has absolutely nothing to do with code. You can create an API without any code at all. Therefore copyright does nothing because there are ways of copying an API that do not violate copyright. Compare it to x86. It's just an "API" as well. Someone can write a specification or reference listing all opcodes and even though that reference is licensed under MIT or GPL you are still not allowed to make your own x86 processor because there is an IP tool specifically designed for this case. It's called patents. Just because you are not violating Intel's copyright doesn't mean you aren't violating Intel's patents. Google probably didn't violate copyright and probably didn't violate any patents. So it is pretty much clear cut. Oracle failed to patent its API and therefore Google is allowed to use it.
  - mumblemumble 6y ago
    > you are still not allowed to make your own x86 processor AMD, Cyrix, Transmeta I'm 99% certain that, if Intel had legal grounds to keep them out of the market, they would have done so. I'm 100% uncertain what's different between that case and this one.

AnthonyMouse 6y ago

> "Whole" in the sense of "the whole is more than the sum of its parts" is not generally understood to imply the maximal possible scope in any given context. It's simply meant to meant to talk about how the identify an aggregation (of no particular scale) relates to the identities of its individual components. Which is how I'm using it. An API that consists of two functions and one that consists of a billion functions have completely different scales but each whole unit has an API portion and an implementation portion. And the API portion is the recipe. It's a purely factual description of what the implementation is expected to do. > Similarly, the API/not-API distinction is one that has to be made in contexts beyond just the relationship of function signatures to function implementations. Foo was declared as a public class, but was it meant for public consumption? Or is it intended for internal use, and was only declared public because, for practical reasons, it couldn't be declared package-private? That doesn't affect whether the API parts of it are API parts, only whether the API is regarded as internal or not, which shouldn't be relevant to copyright. Internal APIs shouldn't be copyrightable either. > The issue at hand really doesn't have anything at all to do with how programmers understand things. It better, or you're in real trouble, because then all you have are meaningless zeros and ones.

imtringued 6y ago
An API is an invisible thing. It's not in the code. It has absolutely nothing to do with code. You can create an API without any code at all. Therefore copyright does nothing because there are ways of copying an API that do not violate copyright. Compare it to x86. It's just an "API" as well. Someone can write a specification or reference listing all opcodes and even though that reference is licensed under MIT or GPL you are still not allowed to make your own x86 processor because there is an IP tool specifically designed for this case. It's called patents. Just because you are not violating Intel's copyright doesn't mean you aren't violating Intel's patents. Google probably didn't violate copyright and probably didn't violate any patents. So it is pretty much clear cut. Oracle failed to patent its API and therefore Google is allowed to use it.
- mumblemumble 6y ago
  > you are still not allowed to make your own x86 processor AMD, Cyrix, Transmeta I'm 99% certain that, if Intel had legal grounds to keep them out of the market, they would have done so. I'm 100% uncertain what's different between that case and this one.