On Tue, Jul 7, 2015 at 4:04 PM, Richard Purdie <[email protected]> wrote: > On Tue, 2015-07-07 at 14:03 -0700, Andre McCurdy wrote: >> On Tue, Jul 7, 2015 at 1:30 PM, Burton, Ross <[email protected]> wrote: >> > On 7 July 2015 at 21:09, akuster808 <[email protected]> wrote: >> >> >> >> which recipe? 2.7.1 / 3.1 or both? >> >> >> >> - armin >> >> ( sucks at this licensing stuff) >> > >> > >> > So: 2.7.1 is "LGPL" (v2). >> > >> > 3.1.1 is GPLv2+ or LGPLv3+. >> > >> > An "interesting" choice to say the least. Because the v2 bit is not L, I'm >> > wondering if we will need to keep both versions. But a 3.1.1 recipe with >> > GPLv2+ *or* LGPLv3+ would be a good start. >> >> I'd vote YES to keeping the LGPLv2 version available. >> >> GPL libraries are normally off limits for closed source apps, so the >> new licensing options would be a problem for anyone with a proprietary >> application using nettle in a distro which can't use [L]GPLv3. (I'm in >> that category...). > > Surely if you can't use [L]GPLv3, you want the 3.1.1 version which is > GPLv2 (or other things)?
There are two separate issues. Both GPLv3 and LGPLv3 block 'Tivoization', which rules out [L]GPLv3 for anyone needing to create signed firmware images which can not be modified by the end user. http://www.gnu.org/licenses/rms-why-gplv3.en.html Quite separate from that, linking an application with a GPL library (any version of the GPL) requires that the application be released under a GPL or GPL compatible license, so GPL libraries are generally considered to be incompatible with closed source applications. (Dynamically linking with an LGPL library is generally OK since the LGPL license doesn't transfer to the application). http://www.gnu.org/licenses/gpl-faq.en.html#IfLibraryIsGPL http://www.gnu.org/licenses/gpl-faq.en.html#GPLStaticVsDynamic So for someone with a proprietary application which links dynamically with nettle in a distro which can't use [L]GPLv3, the older version of nettle with an LGPLv2 license would be the only option. > Cheers, > > Richard > > > -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
