On Thursday 02 April 2015 09:53:46 Lankswert, Patrick wrote: > Thiago, > > I think that you meant that you can dynamically link to LPGLv2.1 code. It am > pretty sure that static linking binds the user of glib to disclose (open > source) the source that uses glib.
Not exactly. The text of the language says you have to provide a way for anyone receiving your binaries to replace the LGPL content. The easiest way to do that is to do dynamic linking, since then the content isn't embedded inside. For static linking, you're still allowed, but it's up to you to find a way. For example, you could provide all your .o and a Makefile so that the recipient can relink. In general, this isn't enough to satisfy the IPR concerns of people who chose proprietary applications, so they opt not to statically link. > I believe (not know) that there is a substitution requirement where an end > user should be allowed replace an LPGL shared library "in the field" or you > are in violation of the license. And a difference between v2 and v3: v2 requires only that you are able to replace the code and produce a new binary, not that you can install it on the device it was on. V3 requires the latter (the "TiVo clause"). > There is another problem though in that if we aspire to support Windows then > glib support maybe problematic. Do you know if there is a glib > implementation outside of Cygwin or MSys? I do not thingk that this is a > blocker. It just another hurdle to jump when we get there. I *think* glib supports MinGW-style building. But I reiterate what I said before: we should dump it and create our own mutex/thread wrappers. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 173 bytes Desc: This is a digitally signed message part. URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150402/ca1e195d/attachment.sig>
