Hi, Patrick Ohly wrote: > Second, as mentioned in #7777 and elsewhere [4], there is a license > conflict between OpenSSL and GPL. Does opening OpenSSL via dlopen() at > runtime really work around this conflict? I'm not a lawyer, but given > that the way how linking is achieved is typically not specified in > detail in licenses, I doubt that using dlopen() instead of ld.so really > works around the license issue.
I am definitely not a lawyer, but I have previously worked for a company who routinely included functionality at runtime if we detected the presence of certain GPL incompatible shared objects. We did receive legal advice that this was not incompatible with the GPL, since we (the application authors) were not shipping the non-GPL & GPL code together. Presumably the same applies to Qt, unless Qt unconditionally depends on OpenSSL. Some related data points: Fluendo also heavily researched this question (for obvious reasons) and have a question about it in their licensing FAQ: http://www.gstreamer.net/data/doc/gstreamer/head/faq/html/chapter-legal.html#legal-gpl-program Jacob Kaplan once wrote a series of unanswered GPL related questions exploring the grey areas around the GPL - this question is related to his questions 1 and 4: http://jacobian.org/writing/gpl-questions/ The question came up on Stack Overflow a while back too: http://stackoverflow.com/questions/2069200/designing-a-gpl-library-with-weak-dependencies-on-proprietary-libs-best-approach Hope all this helps! Cheers, Dave. -- maemo.org docsmaster Email: [email protected] Jabber: [email protected] _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
