[Ffmpeg-devel] moving non-SIMD parts of libswscale to LGPL

Michel Bardiaux mbardiaux
Wed Nov 15 11:46:03 CET 2006


Michael Niedermayer wrote:
> Hi
> 
> On Mon, Nov 13, 2006 at 03:59:52PM +0100, Michel Bardiaux wrote:
>> Reimar D?ffinger wrote:
>>> Hello,
>>> On Mon, Nov 13, 2006 at 12:35:42PM +0100, Michel Bardiaux wrote:
>>>> Diego Biurrun wrote:
>>>>> On Mon, Nov 13, 2006 at 11:39:19AM +0100, Michel Bardiaux wrote:
>>>>>> What are the plans for the SIMD parts?
>>>>> Leave them as GPL.
>>> >From the first day there was talk of swscale, I was afraid it would end 
>>>> like this. With the removal of img_resample and that licensing, the LGPL 
>>>> version becomes a second-class implementation.
>>> It does not change the current situation at all, so I don't see a reason
>>> to be much annoyed over it.
>> Only if the pure-C swscale is faster than img_resample with the MMX 
>> optimisations.
>>
>>>> There is not much I can do, but I dont have to like it.
>>> There is a lot you can do, like writing LGPL SIMD or trying to convince
>>> the authors to allow relicensing as LGPL. 
>> Difficult to do both: to contact the authors, one has to dig in the 
>> sources, but to rewrite a LGPL version of the SIMD code, better keep a 
>> 'clean room' approach. But the latter is likely to be impossible, so 
>> there is no solution.
> 
> what f* SIMD code are you talking about anyway
> there are ~2 pages of mmx code in libavcodec/imgresample.c from which
> one is under if(0)
> and the code is crap, most mmx insructions work with one single sample

Apparently there is a lot of code in ffmpeg that is crap, but nowhere 
documented so. You only reveal the fact when you need it to flame some 
patch or other post you dont agree with.

> actually i wouldnt be surprised if the c code in imgresample.c where faster

Possible. I havent tried yet.

> 
> 
> [...]
>>> and towards the
>>> authors, you can't expect others to argue for something that is not
>>> their goal...
>> If someone's goal is to force a mutation of the license to GPL, that is 
>> not acceptable.
> 
> as diego said acceptable by whom?
> if we choose to change the license to GPL then so be it, actually any
> single person can fork ffmpeg and change it to GPL and continue development
> on that GPL version, 

Oh, I'm quite aware of the theory. But it covers *distribution*, not 
*development* aspects.

Let's assume someone here tables a proposal to change everything to GPL. 
What will happen? What will the decision process be?

Who gets to keep the unqualified name 'ffmpeg'? The www.ffmpeg.org domain?

> iam quoting the LGPL for you below
> 
>   3. You may opt to apply the terms of the ordinary GNU General Public
> License instead of this License to a given copy of the Library.  To do
> this, you must alter all the notices that refer to this License, so
> that they refer to the ordinary GNU General Public License, version 2,
> instead of to this License.  (If a newer version than version 2 of the
> ordinary GNU General Public License has appeared, then you can specify
> that version instead if you wish.)  Do not make any other change in
> these notices.
> 
>   Once this change is made in a given copy, it is irreversible for
> that copy, so the ordinary GNU General Public License applies to all
> subsequent copies and derivative works made from that copy.
> 
> [...]


-- 
Michel Bardiaux
R&D Director
T +32 [0] 2 790 29 41
F +32 [0] 2 790 29 02
E mailto:mbardiaux at mediaxim.be

Mediaxim NV/SA
Vorstlaan 191 Boulevard du Souverain
Brussel 1160 Bruxelles
http://www.mediaxim.com/




More information about the ffmpeg-devel mailing list