Re: [E-devel] [RFC] Evas module move to Eina module API
On Tue, Jun 9, 2009 at 11:29 PM, Lars Munchl...@segv.dk wrote: On Mon, Jun 08, 2009 at 02:52:20PM +0200, Cedric BAIL wrote: Hi, Attached is a patch that move all evas module to eina module. The move introduce one new feature, the possibility to build module inside libevas directly leading the way to an all in one binary for an efl application. This is indeed a very nice feature (which also makes it possible to port efl to ecos and rtems :-) but static linking efl can be a little tricky license wise, given that some libraries (e.g EINA) are LGPL without any exceptions. Sorry for being slightly off topic and maybe even beating a dead horse, but have the authors of EINA and other LGPL based libraries in efl considered adding a static linking exceptions to the LGPL license, like FLTK, mini-xml and many other LGPL based libraries has? The wording could be something like: Static linking of applications to the XYZ library does not constitute a derivative work and does not require the author to provide source code for the application, use the shared XYZ libraries, or link their applications against a user-supplied version of library XYZ. I would like to state that this is only relevant for system without dynamic linking and it make sense in my opinion. So what do people think of : Static linking of applications to eina library does not constitute a derivative work on system that does not provide dynamic linking and does not require the author to provide source code for the application, use the shared eina libraries or link their applications against a user-supplied version of library eina. This change to the licence could also be added to elementary. (not sure if inline functions, macros and templates needs to be covered as well in the above, but you get my point) They are already covered by the LGPL and doesn't make an application using a LGPL library GPL. Anyway, please consider the above suggestion as this new feature opens up for porting efl to some interesting and more embedded operating systems and adding this exception will IMHO not violate the spirit of the LGPL. If this change sounds good to every one on this ML, I will contact all 12 authors of eina and check with them if they agree on this change. Regards, -- Cedric BAIL -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] Evas module move to Eina module API
On Wednesday, 10 June 2009, at 14:06:52 (+0200), Cedric BAIL wrote: Static linking of applications to the XYZ library does not constitute a derivative work and does not require the author to provide source code for the application, use the shared XYZ libraries, or link their applications against a user-supplied version of library XYZ. I would like to state that this is only relevant for system without dynamic linking and it make sense in my opinion. So what do people think of : Static linking of applications to eina library does not constitute a derivative work on system that does not provide dynamic linking and does not require the author to provide source code for the application, use the shared eina libraries or link their applications against a user-supplied version of library eina. The originally-suggested text says the same thing and is grammatically correct. It's probably unwise to have grammatically dubious text in a legal statement. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ m...@kainx.org Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- Act like you expect to get into the end zone.-- Joe Paterno -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] Evas module move to Eina module API
On Wed, Jun 10, 2009 at 02:06:52PM +0200, Cedric BAIL wrote: On Tue, Jun 9, 2009 at 11:29 PM, Lars Munchl...@segv.dk wrote: On Mon, Jun 08, 2009 at 02:52:20PM +0200, Cedric BAIL wrote: Hi, Attached is a patch that move all evas module to eina module. The move introduce one new feature, the possibility to build module inside libevas directly leading the way to an all in one binary for an efl application. This is indeed a very nice feature (which also makes it possible to port efl to ecos and rtems :-) but static linking efl can be a little tricky license wise, given that some libraries (e.g EINA) are LGPL without any exceptions. Sorry for being slightly off topic and maybe even beating a dead horse, but have the authors of EINA and other LGPL based libraries in efl considered adding a static linking exceptions to the LGPL license, like FLTK, mini-xml and many other LGPL based libraries has? The wording could be something like: Static linking of applications to the XYZ library does not constitute a derivative work and does not require the author to provide source code for the application, use the shared XYZ libraries, or link their applications against a user-supplied version of library XYZ. I would like to state that this is only relevant for system without dynamic linking and it make sense in my opinion. So what do people think of : Static linking of applications to eina library does not constitute a derivative work on system that does not provide dynamic linking and does not require the author to provide source code for the application, use the shared eina libraries or link their applications against a user-supplied version of library eina. Just curious: why don't you want to allow static linking on systems that supports dynamic linking? I can see many uses of a static all-in-one binary on for example linux. An example could be a static linked exquisite used in an initrd. This change to the licence could also be added to elementary. (not sure if inline functions, macros and templates needs to be covered as well in the above, but you get my point) They are already covered by the LGPL and doesn't make an application using a LGPL library GPL. Anyway, please consider the above suggestion as this new feature opens up for porting efl to some interesting and more embedded operating systems and adding this exception will IMHO not violate the spirit of the LGPL. If this change sounds good to every one on this ML, I will contact all 12 authors of eina and check with them if they agree on this change. Thanks a lot for doing that :-) Lars Munch -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] Evas module move to Eina module API
On Mon, Jun 08, 2009 at 02:52:20PM +0200, Cedric BAIL wrote: Hi, Attached is a patch that move all evas module to eina module. The move introduce one new feature, the possibility to build module inside libevas directly leading the way to an all in one binary for an efl application. This is indeed a very nice feature (which also makes it possible to port efl to ecos and rtems :-) but static linking efl can be a little tricky license wise, given that some libraries (e.g EINA) are LGPL without any exceptions. Sorry for being slightly off topic and maybe even beating a dead horse, but have the authors of EINA and other LGPL based libraries in efl considered adding a static linking exceptions to the LGPL license, like FLTK, mini-xml and many other LGPL based libraries has? The wording could be something like: Static linking of applications to the XYZ library does not constitute a derivative work and does not require the author to provide source code for the application, use the shared XYZ libraries, or link their applications against a user-supplied version of library XYZ. (not sure if inline functions, macros and templates needs to be covered as well in the above, but you get my point) Anyway, please consider the above suggestion as this new feature opens up for porting efl to some interesting and more embedded operating systems and adding this exception will IMHO not violate the spirit of the LGPL. Best regards Lars Munch -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
