3 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 mo

> 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
  > APIs are concrete work. So in the case of an API re-implemented without copying any code, what concrete work is taken? If not the code, then what thing? > APIs are things as much as code is. I can print out code and read it. I can't print out an API and read it. (I can print out documentation of an API, which is copyrightable, but I cannot print out the API itself). > No. sort as an API is both fundamental and preexisting. What makes sort fundamental but other things...not fundamental? Historically copyright has been pretty straightforward: if there's a physical thing (like a written work, in the case of code) you can copyright it. Now you're adding weird rules like "well some apis are obvious and fundamental but others aren't". Who dictates that? > 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. The problem here is that it means that people can, for example, api-squat. Which is terrible. Imagine the ML craze of recent years, but with Google or Facebook or whomever copyrighting the tensorflow API so that other libraries couldn't be tensorflow compatible without licensing to Google. Sure, companies could just not use Tensorflow, but it was like a half a decade ahead of the competition, and had the backing of basically the largest Machine Learning practitioner in the world. An Open Source version could maybe compete, but probably not. > Again, developers have more power in a world where Oracle wins, and less power in a world where Google wins. Some individual developers have more power, but the development community has less freedom. > The fundamental question here is who owns the code. No, the fundamental question here is if an API is copyrightable. Oracle very clearly owns the code. The question is if the concept of how to do something is a copyrightable work in the same way that actually doing a thing is. A map is not the same as a taxi, and you're saying that the protections we give taxis should also extend to maps all of a sudden. > 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. But you don't seem to consider that Amazon probably already has an answer to API-licensing. > they can create licenses that restrict the ability for massive companies to reimplement their open source code as a proprietary service. No, what you're saying is that companies can restrict the ability for competitors in the same space by building arbitrary lock-in. Companies can already use licensing to prevent competitors from stealing their work, but what you're suggesting is that a competitor can prevent others from entering the space. Consider the opposite situation: Spanner and CockroachDB. If Google decided to license its API, cockroachDB couldn't exist, or at least couldn't compete. Your ideas cut both ways, they don't magically fix things for the little guy.

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
> APIs are concrete work. So in the case of an API re-implemented without copying any code, what concrete work is taken? If not the code, then what thing? > APIs are things as much as code is. I can print out code and read it. I can't print out an API and read it. (I can print out documentation of an API, which is copyrightable, but I cannot print out the API itself). > No. sort as an API is both fundamental and preexisting. What makes sort fundamental but other things...not fundamental? Historically copyright has been pretty straightforward: if there's a physical thing (like a written work, in the case of code) you can copyright it. Now you're adding weird rules like "well some apis are obvious and fundamental but others aren't". Who dictates that? > 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. The problem here is that it means that people can, for example, api-squat. Which is terrible. Imagine the ML craze of recent years, but with Google or Facebook or whomever copyrighting the tensorflow API so that other libraries couldn't be tensorflow compatible without licensing to Google. Sure, companies could just not use Tensorflow, but it was like a half a decade ahead of the competition, and had the backing of basically the largest Machine Learning practitioner in the world. An Open Source version could maybe compete, but probably not. > Again, developers have more power in a world where Oracle wins, and less power in a world where Google wins. Some individual developers have more power, but the development community has less freedom. > The fundamental question here is who owns the code. No, the fundamental question here is if an API is copyrightable. Oracle very clearly owns the code. The question is if the concept of how to do something is a copyrightable work in the same way that actually doing a thing is. A map is not the same as a taxi, and you're saying that the protections we give taxis should also extend to maps all of a sudden. > 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. But you don't seem to consider that Amazon probably already has an answer to API-licensing. > they can create licenses that restrict the ability for massive companies to reimplement their open source code as a proprietary service. No, what you're saying is that companies can restrict the ability for competitors in the same space by building arbitrary lock-in. Companies can already use licensing to prevent competitors from stealing their work, but what you're suggesting is that a competitor can prevent others from entering the space. Consider the opposite situation: Spanner and CockroachDB. If Google decided to license its API, cockroachDB couldn't exist, or at least couldn't compete. Your ideas cut both ways, they don't magically fix things for the little guy.