8 ms·

Why does it seem what way? Like a violation? For the same reason that it would be a violation of my license if they copy/pasted the code and just made some modi

Why does it seem what way? Like a violation? For the same reason that it would be a violation of my license if they copy/pasted the code and just made some modifications to the implementation, then released it under a proprietary license. > So you mean, they don't even use your source code? They delete the implementation but keep the API. But sure, let's say they deleted 100% of the code just for argument's sake. > that shares zero implementation details of yours be contributed back? My opinion is that APIs are implementation details. I completely fail to see why some people are insisting that APIs are not code. > Another bad side effect of things like this is that potentially things like `Shape` and `sort` become copyrightable APIs. Doubtful. For one thing, they exist across tons of languages - you can't copyright the work of others. > If oracle has copyright on Java APIs, that prevents other people from implementing better/other versions of the Java sort function (maybe it's faster, but unstable), you can't implement that. Not true. Oracle's copyright would not extend outside of their enterprise / separately licensed APIs. If people choose to use those APIs they are accepting Oracle's copyright, which is an obvious mistake that they should avoid. Copyright is not there to protect you from making a bad technical decision If Java's APIs were all copyrighted the obvious choice would be to not use Java. Same reason why companies ban using libraries that are AGPL3.

joshuamorton 7y ago
> Why does it seem what way? Like a violation? For the same reason that it would be a violation of my license if they copy/pasted the code and just made some modifications to the implementation, then released it under a proprietary license. Copyright, historically has only extended to the concrete work in question. Other protections, like patents or trademarks are for concepts. Steamboat Willie is protected by copyright, but generic depictions of Mickey Mouse are trademark protected. If as you claim, someone can delete all the code but still maintain copyright, that's a fundamental change to how copyright works: it now extends to ideas and concepts, not just things. This has deep impacts due to how copyright works vs. those other things. Let's talk about some of the weird outcomes: > I completely fail to see why some people are insisting that APIs are not code. Well, in Haskell, APIs are built from fundamental mathematical properties. Is `sort :: [a] -> [a]` copyrightable? We don't consider mathematical constructs to be covered by patent, so while a specific sorting algorithm might be patentable, the API wouldn't be. But now the API is copyrightable. So the mathematical construct can be copyright protected. That's weird. > Doubtful. For one thing, they exist across tons of languages - you can't copyright the work of others. This fails the Rule Utilitarian test: If we rewound time to the mid 1950s, and set intellectual property law to what you're proposing, someone could have copyrighted `sort`, and `sprintf`, and `malloc` and `cat`. GNU could never have appeared because the APIs that GNU copied would have been copyright protected by the Unix authors. So that's a big issue. What else? > If Java's APIs were all copyrighted the obvious choice would be to not use Java. This is easier said that done, I believe your proposal actually breaks the GPL, because I can fork and add a new API surface to a GPL-licensed piece of software, and then use API-copyright to prevent others from making further changes. So currently GPL software would need to be relicensed under a hypothetical GPLv4 that fixes this loophole.
- staticassertion 7y ago
  > Copyright, historically has only extended to the concrete work in question. APIs are concrete work. > it now extends to ideas and concepts, not just things. APIs are things as much as code is. > Well, in Haskell, APIs are built from fundamental mathematical properties. Is `sort :: [a] -> [a]` copyrightable? No. sort as an API is both fundamental and preexisting. > If we rewound time to the mid 1950s, and set intellectual property law to what you're proposing, someone could have copyrighted `sort`, and `sprintf`, and `malloc` and `cat`. Maybe. But that's fine. Someone would have just written their own APIs and licensed in a way that allowed others to use them - the way all software development has gone for decades. I'm sure there were many proprietary 'malloc' APIs that ended up going nowhere, and one one cares today. The ability for developers to license the code was in fact a major deciding factor in APIs surviving - I'm sure we'd see many APIs today, given copyrightable APIs. > GNU could never have appeared because the APIs that GNU copied would have been copyright protected by the Unix authors. The Unix authors could have granted permission (not saying they would). Just because someone holds the copyright doesn't mean they restrict usage - hence the entire open source ecosystem having developers own their copyright, and how the vast majority release that copyright under a liberal license. Or, as stated above, someone would have released their own APIs and granted their copyright via the license they chose, and those APIs would be what we have today > This is easier said that done, We do it all the time. Companies largely ban some licenses, such as AGPLv3. The same exact thing will happen with proprietary or overly restrictive licenses on APIs. The fundamental question here is who owns the code. IF Oracle wins, the developer owns the code - this is much closer to how code copyright already exists, but extended to APIs. IF Google wins no one can own that code, developers lose control over their own work. > because I can fork and add a new API surface to a GPL-licensed piece of software, and then use API-copyright to prevent others from making further changes. I'm not sure that that's true, but even if it were that doesn't "violate" the GPL, it acts in accordance with the license. The question here is if licenses we apply to our code should extend to our APIs. Again, developers have more power in a world where Oracle wins, and less power in a world where Google wins. Further, I feel that things have changed quite a lot. Everyone has been burned by poorly licensed code that has gone stale, and can no longer be modified. Open source has won this fight already. I am far more concerned about the future, as tech companies grow massive, and consolidate. We already see AWS implementing open source APIs with drop-in replacements. If Google wins you kill any ability for developers to protect themselves against that. If ORacle wins you give open source developers back their greatest weapon (Software licensing), and they can create licenses that restrict the ability for massive companies to reimplement their open source code as a proprietary service.

joshuamorton 7y ago

> Why does it seem what way? Like a violation? For the same reason that it would be a violation of my license if they copy/pasted the code and just made some modifications to the implementation, then released it under a proprietary license. Copyright, historically has only extended to the concrete work in question. Other protections, like patents or trademarks are for concepts. Steamboat Willie is protected by copyright, but generic depictions of Mickey Mouse are trademark protected. If as you claim, someone can delete all the code but still maintain copyright, that's a fundamental change to how copyright works: it now extends to ideas and concepts, not just things. This has deep impacts due to how copyright works vs. those other things. Let's talk about some of the weird outcomes: > I completely fail to see why some people are insisting that APIs are not code. Well, in Haskell, APIs are built from fundamental mathematical properties. Is `sort :: [a] -> [a]` copyrightable? We don't consider mathematical constructs to be covered by patent, so while a specific sorting algorithm might be patentable, the API wouldn't be. But now the API is copyrightable. So the mathematical construct can be copyright protected. That's weird. > Doubtful. For one thing, they exist across tons of languages - you can't copyright the work of others. This fails the Rule Utilitarian test: If we rewound time to the mid 1950s, and set intellectual property law to what you're proposing, someone could have copyrighted `sort`, and `sprintf`, and `malloc` and `cat`. GNU could never have appeared because the APIs that GNU copied would have been copyright protected by the Unix authors. So that's a big issue. What else? > If Java's APIs were all copyrighted the obvious choice would be to not use Java. This is easier said that done, I believe your proposal actually breaks the GPL, because I can fork and add a new API surface to a GPL-licensed piece of software, and then use API-copyright to prevent others from making further changes. So currently GPL software would need to be relicensed under a hypothetical GPLv4 that fixes this loophole.

staticassertion 7y ago
> Copyright, historically has only extended to the concrete work in question. APIs are concrete work. > it now extends to ideas and concepts, not just things. APIs are things as much as code is. > Well, in Haskell, APIs are built from fundamental mathematical properties. Is `sort :: [a] -> [a]` copyrightable? No. sort as an API is both fundamental and preexisting. > If we rewound time to the mid 1950s, and set intellectual property law to what you're proposing, someone could have copyrighted `sort`, and `sprintf`, and `malloc` and `cat`. Maybe. But that's fine. Someone would have just written their own APIs and licensed in a way that allowed others to use them - the way all software development has gone for decades. I'm sure there were many proprietary 'malloc' APIs that ended up going nowhere, and one one cares today. The ability for developers to license the code was in fact a major deciding factor in APIs surviving - I'm sure we'd see many APIs today, given copyrightable APIs. > GNU could never have appeared because the APIs that GNU copied would have been copyright protected by the Unix authors. The Unix authors could have granted permission (not saying they would). Just because someone holds the copyright doesn't mean they restrict usage - hence the entire open source ecosystem having developers own their copyright, and how the vast majority release that copyright under a liberal license. Or, as stated above, someone would have released their own APIs and granted their copyright via the license they chose, and those APIs would be what we have today > This is easier said that done, We do it all the time. Companies largely ban some licenses, such as AGPLv3. The same exact thing will happen with proprietary or overly restrictive licenses on APIs. The fundamental question here is who owns the code. IF Oracle wins, the developer owns the code - this is much closer to how code copyright already exists, but extended to APIs. IF Google wins no one can own that code, developers lose control over their own work. > because I can fork and add a new API surface to a GPL-licensed piece of software, and then use API-copyright to prevent others from making further changes. I'm not sure that that's true, but even if it were that doesn't "violate" the GPL, it acts in accordance with the license. The question here is if licenses we apply to our code should extend to our APIs. Again, developers have more power in a world where Oracle wins, and less power in a world where Google wins. Further, I feel that things have changed quite a lot. Everyone has been burned by poorly licensed code that has gone stale, and can no longer be modified. Open source has won this fight already. I am far more concerned about the future, as tech companies grow massive, and consolidate. We already see AWS implementing open source APIs with drop-in replacements. If Google wins you kill any ability for developers to protect themselves against that. If ORacle wins you give open source developers back their greatest weapon (Software licensing), and they can create licenses that restrict the ability for massive companies to reimplement their open source code as a proprietary service.