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 >>
