[FFmpeg-devel] [PATCH] LICENSE: remove incorrect statements that leaked in from libav

Michael Niedermayer michaelni at gmx.at
Wed Aug 15 19:08:28 CEST 2012


On Tue, Aug 14, 2012 at 09:25:21AM +0200, Reimar Döffinger wrote:
> 
> 
> On 14 Aug 2012, at 09:04, Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> 
> > On 14 Aug 2012, at 00:38, Michael Niedermayer <michaelni at gmx.at> wrote:
> >> On Mon, Aug 13, 2012 at 08:34:17PM +0200, Reimar Döffinger wrote:
> >>> On Mon, Aug 13, 2012 at 08:15:09PM +0200, Reimar Döffinger wrote:
> >>>> On Mon, Aug 13, 2012 at 07:07:04PM +0200, Michael Niedermayer wrote:
> >>>>> This is based on the ubuntu technical committee understanding of
> >>>>> the libfaac license:
> >>>>> https://lists.ubuntu.com/archives/technical-board/2011-February/000703.html
> >>>>> 
> >>>>> That is
> >>>>> 1. libfaac is not LGPL itself as a whole
> >>>>> 2. libfaac is not GPL compatible (additional restrictions violate GPL)
> >>>>> 3. libfaac is distributable (ubuntu distributes it)
> >>>>> 4. libfaac contains LGPL code itself (stated in libfaac README and other places)
> >>>>> from above axioms one can conclude libfaac must be linkable with LGPL code
> >>>>> because where it not, it itself could not be distributed
> >>>> 
> >>>> 4) could be based on assuming that libfaac authors would automatically
> >>>> give you rights beyond what the LGPL does, thus allowing it to be
> >>>> combined with non-LGPL compatible code.
> >>>> As to the incompatibility there is in section 6 of LGPL v2.1:
> >>>>> provided that the terms permit
> >>>>> modification of the work for the customer's own use and reverse
> >>>>> engineering for debugging such modifications.
> >>>> 
> >>>> The libfaac license under discussion does _not_ permit you to make
> >>>> modifications, since any modification that would make the code not
> >>>> standards-compatible would mean that you loose your license to it.
> >>>> That is ignoring the fact that if you are pedantic since no software,
> >>>> and certainly also libfaac, is bug free the code probably never was
> >>>> standards compliant and thus nobody ever had a license to distribute
> >>>> it ever, even stand-alone.
> >>> 
> >>> I know that the disclaimer rather belongs on top, but I should say
> >>> that's of course my (pedantic) reading of it, and lawyers and courts
> >>> may have different opinions.
> >>> If you mind the description, personally I would go for "we think it is
> >>> possible it might be unredistributable, but we don't know. It is up to
> >>> you to either not redistribute the result, consult a lawyer or just take
> >>> the risk (Ubuntu seems to have chosen the last one <link>)"
> >> 
> >> can you elaborate on the problem you see in my suggested change of the
> >> text ? (iam asking so i can suggest a better text)
> > 
> > Nothing really in particular except that it is very vague and IMHO seems to be even less help for deciding what to do than mine.
> 
> And I should have said: feel free to go ahead with your version, I just really disagreed with your way of arguing that there is no problem.

new patch posted

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120815/6dc8ea69/attachment.asc>


More information about the ffmpeg-devel mailing list