11–17 of 17 posts
Oracle bought Sun's assets and they have every right to what they are doing. But a failed business effort to make additional fees is not, in my opinion, a risk to "free" software.
Google did not take Java code. It wrote it's own software with exactly same API. Any API that is "in the open" is free to be emulated. Especially Open Source ones! What this mean for open source software is that if I write a GPL library, and someone can't use GPL software and writes it's own implementation to be a drop-in replacement, it's free to do so. Which I believe is OK with everyone, except Oracle corporate re…
What's the FSF's position on this, I wonder. The whole premise of the GPL as opposed to the LGPL is that even dynamic linking creates a derived work.
If someone creates a completely drop-in replacement for readline (I don't know if libedit and kin are drop-in or not) and releases it under a BSD license, there's no way to distinguish my app linking against one vs the other, I'm simply making use of the API in the abstract.
This isn't exactly the same as the Java case, but the copyright status of APIs per-se sure seems to have implication for the GPL's teeth.
Earlier quoted context omitted.
When a court finds API implementation to be fair use, there is an impact on free software, and that impact is basically positive. The idea of API's being copyrightable threatens the status of free software projects which implement ("clone") previously proprietary API's.
> When a court finds API implementation to be fair use, there is an impact on free software, and that impact is basically positive. It certainly is positive for the ability to create new free software. It is negative for the ability to control other people's actions through copyleft licenses, since the same ability to create new free software also allows creating new permissive licensed or commercial software rather…
It certainly is positive for the ability to create new free software. It is negative for the ability to control other people's actions through copyleft licenses, since the same ability to create new free software also allows creating new permissive licensed or commercial software rather than adhering to the copyleft terms.
It feels like the OSS ecosystem has always concluded that creating drop-in replacements using API's are 'fair use'.
Earlier quoted context omitted.
> When a court finds API implementation to be fair use, there is an impact on free software, and that impact is basically positive. It certainly is positive for the ability to create new free software. It is negative for the ability to control other people's actions through copyleft licenses, since the same ability to create new free software also allows creating new permissive licensed or commercial software rather…
It certainly is positive for the ability to create new free software. It is negative for the ability to control other people's actions through copyleft licenses, since the same ability to create new free software also allows creating new permissive licensed or commercial software rather than adhering to the copyleft terms. Agreed. As a point of practicality I can't think of anyone whose created 'commercial' open sour…
Maybe there are some narrower cases involving proprietary Linux kernel modules (which many people have suggested could be improper derived works that constitute copyright infringement of the kernel); there this result might make the infringement argument more difficult.
But as people here have pointed out, almost nobody ever attempts to limit implementation or use of APIs as a "work based on the program" for GPL purposes, almost nobody assumes that would be successful, and almost all uses of the GPL are based on limiting the literal copying of code from one program into another.
Google did not take Java code. It wrote it's own software with exactly same API. Any API that is "in the open" is free to be emulated. Especially Open Source ones! What this mean for open source software is that if I write a GPL library, and someone can't use GPL software and writes it's own implementation to be a drop-in replacement, it's free to do so. Which I believe is OK with everyone, except Oracle corporate re…
> Which I believe is OK with everyone What's the FSF's position on this, I wonder. The whole premise of the GPL as opposed to the LGPL is that even dynamic linking creates a derived work. If someone creates a completely drop-in replacement for readline (I don't know if libedit and kin are drop-in or not) and releases it under a BSD license, there's no way to distinguish my app linking against one vs the other, I'm si…
Okey, in this fantasy world, do we still have the concept of derivative work? I would say Yes. Would thus GPL still apply? Yes. Is there an API? No.
GPL is not based on the technology of linking. As a software license, it used the concept of derivative work, distribution and other concept in copyright law to define the scope. LGPL in contrast do specify linking technology, but that is only an additional permission which would need to be modify if it were to function with new linking technologies.
If you created a drop-in replacement for readline, the argument that the complete work is readline + some code get weaker. However, if the police finds some emails on your drive that states your intention to combine readline + some code, and then go to copy readline by reimplemented the software in a identical (copy'ish) way, then you might very well be infringing on the right of the readline authors. It depend what a judge/jury think your intentions was.
Earlier quoted context omitted.
> Which I believe is OK with everyone What's the FSF's position on this, I wonder. The whole premise of the GPL as opposed to the LGPL is that even dynamic linking creates a derived work. If someone creates a completely drop-in replacement for readline (I don't know if libedit and kin are drop-in or not) and releases it under a BSD license, there's no way to distinguish my app linking against one vs the other, I'm si…
Lets imagine that we create a third way to link software. There is static linking, dynamic linking, and now we got this imagined third thing called adaptive linking. In this made up linker, it magically combines the different parts and uses neural networks (ie, more magic) to figure out how to make the two parts communicate without a API. Okey, in this fantasy world, do we still have the concept of derivative work? I…
I agree that GPL doesn't get it's "teeth" unless linking creates a derivative work. The FSF (and Linus) for that matter have Opinions about what does,though, so I'm curious how and whether this ruling changes those.
I don't know whether to be thankful or not that there's still a circuit split in the US over what constitutes a derivative work in the software realm.
Google did not take Java code. It wrote it's own software with exactly same API. Any API that is "in the open" is free to be emulated. Especially Open Source ones! What this mean for open source software is that if I write a GPL library, and someone can't use GPL software and writes it's own implementation to be a drop-in replacement, it's free to do so. Which I believe is OK with everyone, except Oracle corporate re…
> Which I believe is OK with everyone What's the FSF's position on this, I wonder. The whole premise of the GPL as opposed to the LGPL is that even dynamic linking creates a derived work. If someone creates a completely drop-in replacement for readline (I don't know if libedit and kin are drop-in or not) and releases it under a BSD license, there's no way to distinguish my app linking against one vs the other, I'm si…
see http://lkml.indiana.edu/hypermail/linux/kernel/0301.1/0362.h...