Hello, On Sat, 9 Jun 2018, at 22:19, Jan Ekström wrote: > I think the general idea was that since LGPL lets you link an LGPL > library in a proprietary piece of software (given that you follow the > spirit and language of LGPL by letting people build the same version > and making it possible for the built version to be loaded up in the > proprietary application), it probably works the other way as well. If
Well, I'm not sure at all that is sufficient. The "check if you can replace yourself the library" is a good check, when you are incorporating a LGPL code inside a non-LGPL code. I totally agree. But the other way around is quite complex, and not obvious at all. Especially, since the LGPL says: "These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. " which covers the first case, but does not cover the second one... IIRC, the fdk-aac issues were mostly about the patents part, which limited the usage and the advertising clause. And, tbh, as fdk-aac can limit the rights of the recipients as it mentions "only for purposes that are authorized by appropriate patent licenses", this is an additional limitation of rights that were granted, which is forbidden by the LGPL section 10. "You may not impose any further restrictions on the recipients' exercise of the rights granted herein." Therefore a libavcodec+fdk-aac library cannot be redistributed freely, or similarly as it was shared to you, and that makes it, IMHO, totally non-free. Best, -- Jean-Baptiste Kempf - President +33 672 704 734 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
