As this issue is going to need a broader discussion IMO, let's engage debian-legal to join this. Please keep both mailing list in the loop!
For full context for debian-legal: FFmpeg is a compilation of several libraries, we are discussing the libavcodec library in this context. It consists of several decoders, of which some are only wrappers for external libraries. The openamr decoder is such one, that one can use openamr-core, if available at compilation time. FFmpeg is currently distributed under the terms of of GPLv2 or later, openamr-core is licensed under the terms of the Apache 2.0 license. According to upstream's assessment, enabling the openamr decoder renders the resulting libavcodec.so shared object file, and all applications linking against that library as only distributable under the terms of GPLv3 or later. Andres Mejia <mcita...@gmail.com> writes: > opencore-amr has been accepted into the archive and has even entered testing. > The option to enable opencore-amr for ffmpeg has not been activated yet due > to > concerns that ffmpeg would result in having to be distributed under the > GPL-3. > An ffmpeg library under GPL-3 license would mean other projects would have to > be GPL-3 or some GPL-3 compatible license. I fear the analysis which license each package that links against libavcodec has will be very exhaustive. Moreover, what would we do about packages that link against libavcodec and are strictly GPLv2 licensed? ask ftp-master to remove them? That would be very unfortunate, IMO. > So are we going to enable the option to build with opencore-amr > support? If so, what are we going to do about other programs depending > on ffmpeg? AFAIUI, the problem we are talking about here is that the GPLv2 has a clause that prohibits to apply further restrictions on work that go beyond the restrictions that are mentioned in the GPLv2. This however is done with opencore-amr's license (Apache 2.0). The resulting libavcodec.so.52 binary would need to be redistributed under both terms of the Apache 2.0 license and GPLv2, which is impossible. I have taken a brief look at openamr and the way FFmpeg uses it, and think that we can avoid the problem by modifying libavcodec/libopencore-amr.c to load the two opencore-amr libraries at runtime via dlopen() instead of dynamically linking against it. The difference here would be that the libavcodec.so.52 library (on-disk) would be usable stand-alone, i.e. the additional restrictions that the GPLv2 prohibits cannot come into affect when redistributing the libavcodec package. Does this sound acceptable for debian? Other Opinions? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
