3 ms·

This situation is different from ffmpeg. Kernels do not link to your program in the way that libraries do. When using a library, even a dynamically linked one

by zerohp 16y ago

This situation is different from ffmpeg. Kernels do not link to your program in the way that libraries do. When using a library, even a dynamically linked one, the memory image of your program is a combined work. As the CPU is evaluating your program, it does not see the library or treat it differently than any other functions in your program. System calls can be thought of like RPC. The two programs (yours and the kernel) communicate but do not link together in a single memory image.

anon1385 16y ago
Yes, as I said the issue are slightly different. My question is: what legal basis does the developer of a GPL library have to sue somebody who released a program linked with that library. If the two only come together to form a combined work on the users machine, at the users command, then how does the GPL apply to me, the distributor of the the non-GPL program? I am not distributing a combined or derivative work. At most I am using the headers and distributing the symbol names, which are not covered by copyright. When I make no copies, how does copyright law affect me? If the headers were covered by copyright, that would have provided a way for a developer to prevent use of their GPL library by non-GPL programs.
- zerohp 16y ago
  There are different opinions on this, see: http://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works http://en.wikipedia.org/wiki/GNU_General_Public_License#Link...
- caf 16y ago
  Your argument applies in the case where you do not distribute the GPL'd library - as zerohp points out, opinions differ on this case, and it hinges on whether your compiled program would be considered a "derivative work". However, if you distribute the GPL'd library, then it's a lot more clear-cut. "Derivative work" doesn't enter into it anymore - to distribute the GPL'd library itself you must have a license to do so. If the license you're relying on there is the GPL, you must abide by its terms, including those about linking.

by zerohp 16y ago

anon1385 16y ago

Yes, as I said the issue are slightly different. My question is: what legal basis does the developer of a GPL library have to sue somebody who released a program linked with that library. If the two only come together to form a combined work on the users machine, at the users command, then how does the GPL apply to me, the distributor of the the non-GPL program? I am not distributing a combined or derivative work. At most I am using the headers and distributing the symbol names, which are not covered by copyright. When I make no copies, how does copyright law affect me? If the headers were covered by copyright, that would have provided a way for a developer to prevent use of their GPL library by non-GPL programs.

zerohp 16y ago
There are different opinions on this, see: http://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works http://en.wikipedia.org/wiki/GNU_General_Public_License#Link...
caf 16y ago
Your argument applies in the case where you do not distribute the GPL'd library - as zerohp points out, opinions differ on this case, and it hinges on whether your compiled program would be considered a "derivative work". However, if you distribute the GPL'd library, then it's a lot more clear-cut. "Derivative work" doesn't enter into it anymore - to distribute the GPL'd library itself you must have a license to do so. If the license you're relying on there is the GPL, you must abide by its terms, including those about linking.