(05-30-2015, 10:04 PM)delroth Wrote: [ -> ]tueidj: system provided libraries are an exception to the GPL. In general it's widely accepted that stuff like msvcrt or d3d are system provided, and there is a wide range of precedent for that. Random Android libraries that we want to use in Dolphin are not in the same situation (note, however, that the same situation would apply to us using the standard Android SDK/NDK, from my understanding of the situation).
In the future this license change will also allow us to integrate with OSVR, which is licensed under Apache 2.0.
You're not supposed to link with anything that
isn't part of the NDK since they are private APIs subject to change in the future. If that is what's happening with Dolphin then that is what should have been remedied, rather than changing the licence.
It seems like even though there was this big undertaking to change the licence, and now a long blog post article about it, nobody knows of any dependency that was causing a licence conflict?
(05-30-2015, 10:31 PM)Armada Wrote: [ -> ]From what I understand the GPL exempts you from having to provide the source code for those libraries, but you are still not allowed to link to those libraries if the licenses on them would affect your rights given under the GPL.
In other words, the System Library Exception exempts those libraries from the "infection" of GPL, but it does not allow those system libraries to infect the GPL.
That makes no sense in this case since the apache license doesn't require derivative works (i.e. the programs linking to the apache licensed libraries) to also use the same license. If it did, every program for android would be required to use it...
(05-31-2015, 08:25 AM)tueidj Wrote: [ -> ]That makes no sense in this case since the apache license doesn't require derivative works (i.e. the programs linking to the apache licensed libraries) to also use the same license. If it did, every program for android would be required to use it...
Neither does GPL, but the licenses should not conflict on the rights and restrictions being placed on the application. There's a big misunderstanding that GPL "infects" the application forcing it to use GPL. It's just that the easiest way to comply to the GPL is to actually license under the GPL.
(05-31-2015, 08:25 AM)tueidj Wrote: [ -> ]You're not supposed to link with anything that isn't part of the NDK since they are private APIs subject to change in the future. If that is what's happening with Dolphin then that is what should have been remedied, rather than changing the licence.
It seems like even though there was this big undertaking to change the licence, and now a long blog post article about it, nobody knows of any dependency that was causing a licence conflict?
Linking is not something that just happens natively, GPL actually defines as a guideline that anything that shares the same address space as the application could be considered linked against it.
(05-31-2015, 08:35 AM)Armada Wrote: [ -> ]Neither does GPL, but the licenses should not conflict on the rights and restrictions being placed on the application. There's a big misunderstanding that GPL "infects" the application forcing it to use GPL. It's just that the easiest way to comply to the GPL is to actually license under the GPL.
What? The GPL most definitely does require that derivative works use the same licence.
"the licenses should not conflict on the rights and restrictions being placed on the application" Apache doesn't do this, so where is the problem with linking with Apache-licensed system libraries?
Quote:Linking is not something that just happens natively, GPL actually defines as a guideline that anything that shares the same address space as the application could be considered linked against it.
That's an illogical definition, from the kernel's point of view (or anything else that runs in ring 0) that would include every program in memory. From the program's point of view it would include everything from hardware drivers to custom shell hooks. Such things can have little to no influence on your program and should certainly not be essential for it to function.
You choose what to explicitly link your program with, and that is all you should be concerned about. Anything beyond that point is not under your control, the only sensible way you could attempt to comply with any extra restrictions that might arise is to use a fully permissive licence.
(05-31-2015, 09:15 AM)tueidj Wrote: [ -> ]What? The GPL most definitely does require that derivative works use the same licence.
"the licenses should not conflict on the rights and restrictions being placed on the application" Apache doesn't do this, so where is the problem with linking with Apache-licensed system libraries?
It requires derivative works to use the same license, it does not require applications linking to it to use the same license. Apache does conflict with the terms in the GPLv2, this is a well known fact.
(05-31-2015, 09:15 AM)tueidj Wrote: [ -> ]That's an illogical definition, from the kernel's point of view (or anything else that runs in ring 0) that would include every program in memory. From the program's point of view it would include everything from hardware drivers to custom shell hooks. Such things can have little to no influence on your program and should certainly not be essential for it to function.
You choose what to explicitly link your program with, and that is all you should be concerned about. Anything beyond that point is not under your control, the only sensible way you could attempt to comply with any extra restrictions that might arise is to use a fully permissive licence.
That's not true, in a modern operating system every application has its own virtual address space.
The thing is you are allowed, as a user, to violate the license. You are just not allowed to redistribute the application with a license violation in place. In other words, anything your binary explicitly links to (Visual C++, DirectX and any third-party libraries) needs to comply with the license, but anything the user adds in is his business.
The best indication that you're explicitly linking to a library is that you're using its API, you need to make sure you have no license conflict with any API you're using. This includes the Android API which is licensed under Apache.
(05-31-2015, 09:27 AM)Armada Wrote: [ -> ]It requires derivative works to use the same license, it does not require applications linking to it to use the same license. Apache does conflict with the terms in the GPLv2, this is a well known fact.
Apache
does not require derivative works to use the same licence, only the non-modified portions. In the case of linking the non-modified portion would be the library itself while the program is free to use whatever licence it wishes.
Even if you disagree with this interpretation, you do agree that applications linking are not required to use the same licence. But at the same time you're claiming that Dolphin cannot link to the Apache licensed android system libraries because that would somehow "infect" Dolphin. How is it possible for both cases to be true?
Quote:That's not true, in a modern operating system every application has its own virtual address space.
Who said anything about a "modern operating system"? The licence does not dictate anything about the required underlying architecture, which is why referring to "address space" makes no sense and has no relevance.
Quote:The best indication that you're explicitly linking to a library is that you're using its API, you need to make sure you have no license conflict with any API you're using. This includes the Android API which is licensed under Apache.
And now we've come full circle to the original topic - why are the windows APIs considered exempt under the system libraries clause, but the android APIs are not?
(05-31-2015, 09:57 AM)tueidj Wrote: [ -> ]And now we've come full circle to the original topic - why are the windows APIs considered exempt under the system libraries clause, but the android APIs are not?
Android APIs are also exempt, we don't have to be able to provide source code for them, just like the Windows APIs, but that's all the System Library exception exempts you from. If any of the terms of any of the licenses that apply to the program are incompatible with the terms in the GPL it's a license violation.
The discussion is going full circle because you interpret the System Library Exception as exempting you from the terms those libraries are licensed under, that's not possible no matter what the terms are in the GPL.
(05-31-2015, 09:57 AM)tueidj Wrote: [ -> ]Who said anything about a "modern operating system"? The licence does not dictate anything about the required underlying architecture, which is why referring to "address space" makes no sense and has no relevance.
Which is why it's a guideline and not an actual term of the GPL.
(05-31-2015, 10:12 AM)Armada Wrote: [ -> ]The discussion is going full circle because you interpret the System Library Exception as exempting you from the terms those libraries are licensed under, that's not possible no matter what the terms are in the GPL.
Ok, explain to me
in plain english how "the terms those libraries are licensed under" affect Dolphin, considering both the system library exemption clause and the fact that the Apache licence does not place any restrictions on applications that link to any libraries using it.
If the terms in the GPL are really irrelevant to what Dolphin is required to comply with, that just proves that it was a complete waste of time changing Dolphin's licence.
(05-31-2015, 10:26 AM)tueidj Wrote: [ -> ] (05-31-2015, 10:12 AM)Armada Wrote: [ -> ]The discussion is going full circle because you interpret the System Library Exception as exempting you from the terms those libraries are licensed under, that's not possible no matter what the terms are in the GPL.
Ok, explain to me in plain english how "the terms those libraries are licensed under" affect Dolphin, considering both the system library exemption clause and the fact that the Apache license does not place any restrictions on applications that link to any libraries using it.
https://www.apache.org/licenses/GPL-compatibility.html
http://www.gnu.org/philosophy/license-list.html#apache2
Again, just because you are exempt from providing source code, does not mean you are exempt from the license incompatibility. Besides, we aren't only ever going to use System Libraries licensed under Apache.
But what exactly is your point? Are you trying to argue that the GPLv2 and the Apache license are compatible despite what the FSF thinks about it? Seems like a fruitless effort to try to save us work after the fact.
(05-31-2015, 10:32 AM)Armada Wrote: [ -> ]https://www.apache.org/licenses/GPL-compatibility.html
Not relevant if you
read what the license actually covers:
Quote:"Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.
Quote:But what exactly is your point? Are you trying to argue that the GPL and the Apache license are compatible despite what the FSF thinks about it? Seems like a fruitless effort to try to save us work after the fact.
My point is that saying the relicensing was required for the android port to avoid conflict is completely false. You've made a factually inaccurate blog post explicitly to bring attention to it, encouraging people to think that the android eco-system is unfriendly towards GPLv2 projects as well as listing all the obstacles you encountered in order to overcome a roadblock that never existed in the first place. It's borderline click-bait considering the blog runs ads...
(05-31-2015, 10:53 AM)tueidj Wrote: [ -> ]My point is that saying the relicensing was required for the android port to avoid conflict is completely false. You've made a factually inaccurate blog post explicitly to bring attention to it, encouraging people to think that the android eco-system is unfriendly towards GPLv2 projects as well as listing all the obstacles you encountered in order to overcome a roadblock that never existed in the first place. It's borderline click-bait considering the blog runs ads...
FSF doesn't seem to agree, if it's not compatible you simply can't include it in your project.