Kevron, IANAL, LPGL v2 on this issue has not been legally challenged for embedded environments. The LGPL v2 is a little ambiguous on the binary substitution requirements. LGPL v3 was created to close the ambiguity. Many like to point to Android and iOS use of webkit, but neglect to mention that it is LGPL and BSD licensed. From what I can see, if we need to support a platform that does not support dynamic linking, the LGPL will be a problem.
Are you aware of well-supported glib implementations that is available for iOS, Win32, WinRT or RTOSes like Contiki, uCOS, etc. What is more work, porting glib to the next OS/RTOS or implementing a thread and mutex wrapper for each OS? Pat > -----Original Message----- > From: Rees, Kevron [mailto:kevron.m.rees at intel.com] > Sent: Tuesday, April 14, 2015 3:56 PM > To: Lankswert, Patrick > Cc: iotivity-dev at lists.iotivity.org > Subject: Re: [dev] glib > > Also, I'm not sure "1" is actually a problem. This is not GPL 3 that > requires the > device to be hackable where you could replace a lgpl library. Literally > hundreds of devices ship with LGPL code. > > On Tue, Apr 14, 2015 at 12:51 PM, Rees, Kevron <kevron.m.rees at intel.com> > wrote: > > You should be using glib for mainloop functionality as well (avoids > > having to use threads at all), but it should be pluggable (able to be > > replaced with Qt or other mainloops systems as desired). > > > > > > > > On Tue, Apr 14, 2015 at 11:45 AM, Lankswert, Patrick > > <patrick.lankswert at intel.com> wrote: > >> To all, > >> > >> The introduction of glib has complicated the stack in a number of > >> ways from licensing to OS support and beyond. > >> > >> In the future, do not draw in additional libraries into Iotivity > >> without vetting it in this forum. > >> > >> I plan to remove the glib dependency from iotivity for several reasons: > >> 1) IANAL, but the license has viral requirements including the fact > >> that a dynamically linked LGPL library must be replaceable which is a > >> problem for RTOSes and linux-based devices TVs and Access Points. > >> 2) Glib support on iOS (not directly supported), OSX and Windows > >> (requires > >> MSYS) is problematic > >> 3) It is my understanding that we are only using glib for threads and > mutex. > >> This is a lot to pull into iotivity for only two features. > >> > >> Before I make this official, I would like to understand any reason > >> that glib should be kept. Are we using glib for anything other than > >> threads and mutexes? > >> > >> Pat > >> > >> Patrick Lankswert > >> > >> Intel Corporation > >> Platform Engineering Group (PEG) / Communications and Devices Group > >> (CDG) Engineering Manager Louisville, KY, USA > >> > >> > >> _______________________________________________ > >> iotivity-dev mailing list > >> iotivity-dev at lists.iotivity.org > >> https://lists.iotivity.org/mailman/listinfo/iotivity-dev > >> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7198 bytes Desc: not available URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150414/a9ad429e/attachment.p7s>
