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 <
mcitadel@...> 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-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact
listmaster@...
signature.asc (853 bytes) 