Hi, Thanks. I think it's best not to consider the derivitive works angle as it could also be argued that the EFL were derived from Enlightenment work in part, and that is BSD too.
Either way it sounds like my understanding was correct - the LGPL is there intentionally and will override the BSD license if you want to link statically? One assumes this also means that all Tizen native apps are limited to dynamic linking to avoid the need for developers to provide alternative object code downloads? Thanks, Andrew On Mon, 30 Jul 2018 at 02:35 Simon Lees <sfl...@suse.de> wrote: > Hi all, > > I also remember the eina lgpl being intentional, one of the reasons is > that it might be possible to argue that to the rest of the efl > libraries, eina / efl (also lgpl) are more then just libraries that the > rest of efl uses and therefore the rest of the efl libraries should be > treated as derivative works. This will likely get slightly more complex > when we as upstream start merging libraries. > > Probably the safest way legally would be to treat all of the efl as lgpl > and provide objects in such a way that you can relink any part of the > efl. But I am not a lawyer and its probably one of those ambiguities > where without it going to court we will never actually know so most > companies legal teams will advise them to take the safest possible > interpretation atleast in my experience. > > On 30/07/18 05:56, Andrew Williams wrote: > > Hi Stephen, > > > > I was probably over-simplifying but in the context where static-linking > is > > required then the LGPL forces certain behaviours which the BSD does not. > > My understanding is that this applies to anyone linking statically to any > > part of EFL as they (mostly) all depend on Eina? > > > > Reading from > https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic If > > I write a framework which is statically linked which includes the Eina > > static link then the application developer must ship alternative object > for > > for re-linking. Additionally the app publishers would need to provide the > > source code of Eina that was linked to to comply with LGPL. > > > > Do others have a different understanding of the situation? > > Thanks, > > Andrew > > > > On Thu, 26 Jul 2018 at 13:56 Stephen Houston <smhousto...@gmail.com> > wrote: > > > >> This was a huge argument when Eina came into EFL. IIRC the profusion > guys > >> that wrote Eina were adamant on it being LGPL and even looked into the > >> possibility of trying to make the rest of EFL LGPL. Of course getting > all > >> the author permissions to do so would be impossible so that was nixed. > So > >> the state of things license wise is what it is today. As far as the > >> implications of that, I haven't studied it much. Can you provide the > exact > >> language that makes you believe this to be true? > >> > >> On Thu, Jul 26, 2018, 6:58 AM Andrew Williams <a...@andywilliams.me> > >> wrote: > >> > >>> Hi, > >>> > >>> I was checking out the situation regarding licensing and read the > current > >>> state in https://github.com/Enlightenment/efl/blob/master/README. As > far > >>> as > >>> I can tell the library at the bottom of our dependency tree, Eina, is > >> LGPL > >>> whereas most others are BSD - which includes the main Efl library. > >>> > >>> As far as I can see this means that the BSD Efl lib will restrict to > LGPL > >>> automatically if statically linked. > >>> Is that the intention? > >>> > >>> I was hoping to use static linking for a project but I don't want to > pass > >>> this restriction up stream. Is there anything I can do and/or have I > >>> misunderstood the situation at all? > >>> > >>> Thanks, > >>> Andrew > >>> -- > >>> http://andywilliams.me > >>> http://ajwillia.ms > >>> > >>> > >> > ------------------------------------------------------------------------------ > >>> Check out the vibrant tech community on one of the world's most > >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot > >>> _______________________________________________ > >>> enlightenment-devel mailing list > >>> enlightenment-devel@lists.sourceforge.net > >>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >>> > >> > >> > ------------------------------------------------------------------------------ > >> Check out the vibrant tech community on one of the world's most > >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot > >> _______________________________________________ > >> enlightenment-devel mailing list > >> enlightenment-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >> > > -- > > Simon Lees (Simotek) http://simotek.net > > Emergency Update Team keybase.io/simotek > SUSE Linux Adelaide Australia, UTC+10:30 > GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- http://andywilliams.me http://ajwillia.ms ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
