I wasn't aware that glib was being used for all multi-threaded platforms. For linux, this is almost a no-brainer, but you still have to throw the license argument out the window.
You could use c++11 threads/mutexes instead, however, you'll probably run into the same problems on many platforms with dubious c++11 support. Finally, is it a rational goal to work on every platform imaginable? You'll spend more time/resources/money fixing code for each platform and may end up inventing yet-another-buggy-os-abstraction-framework when all is said and done. Does iotivity have a defined number of target platforms? On Tue, Apr 14, 2015 at 1:32 PM, Lankswert, Patrick <patrick.lankswert at intel.com> wrote: > 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 >> >>
