Re: [mp3encoder] possible lame LGPL violation
[EMAIL PROTECTED] wrote: Quoting Takehiro Tominaga <[EMAIL PROTECTED]>: Any one that uses windows can use EncSpot to get a clue about the encoder used? if it's LAME than they probably didn't change the code so mutch that EncSpot still could recognize LAME tags and the encoder version, even mpglib. The problem is solved. The encoder is indeed Lame, and proper credit will be mentionned in the next release. -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] possible lame LGPL violation
Quoting Takehiro Tominaga <[EMAIL PROTECTED]>: Any one that uses windows can use EncSpot to get a clue about the encoder used? if it's LAME than they probably didn't change the code so mutch that EncSpot still could recognize LAME tags and the encoder version, even mpglib. Sorry i can't make the test ... Filipe > Hi, > > I think the app is probabry violating LGPL of mpglib, but I wonder > it violates that of LAME... very suspectable, but I cannot assert. > > Anyone used the software and check the output mp3 file ? > I think we can say "violate or not" from it. > > > From: Spire Spire <[EMAIL PROTECTED]> > Subject: [mp3encoder] possible lame LGPL violation > Date: Sat, 6 Dec 2003 17:32:43 -0800 (PST) > > > I was able to find the byte sequences from the static > > const unsigned char rv_tbl[] array from > > lame/libmp3lame/fft.c in their exe (Flicker.exe > > 1.0.0.1). (using Cygwin od/grep/strings tools) > > The values are simple bit-reversed numbers. > They are common for all the FFT/FHT code and I think it is not > sufficient evidence. > > > The static const unsigned char slen[] in > > III_get_scale_factors_1() in lame/mpglib/layer3.c also > > appears. > : > > And static const short t24HB[] in > > lame/libmp3lame/tables.c > > They are also common for all MP3 encoders/decoders. > > > Also some string constants from > > lame/mpglib/interface.c and lame/mpglib/layer3.c: > > > > C:\Program Files\ImageMatics>strings Flicker.exe |grep mpg > > > > mpglib: wordpointer trashed. size=%i (%i) bytes=%i > > mpg123: Can't rewind stream by %d bits! > > WOW, mpglib is LGPL and they are sufficient evidence. > > > And from lame/mpglib/interface.c: > > > > C:\Program Files\ImageMatics>strings Flicker.exe |grep bitstream > > > > bitstream problem: resyncing... > > HEHE, maybe this is from LAME, but these words are common for > many application. > > > And I found the below string in the binary, > > "fatal error. MAXFRAMESIZE not large enough." > > This is in the lame/libmp3lame/bitstream.c, but they are also common > strings, I afraid. > -- > Takehiro TOMINAGA // may the source be with you! > ___ > mp3encoder mailing list > [EMAIL PROTECTED] > http://minnie.tuhs.org/mailman/listinfo/mp3encoder > > - This mail sent through IMP: http://horde.org/imp/ ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] possible lame LGPL violation
Gabriel Bouvigne wrote: I am writing them a mail asking for clarification about this. Issue solved, next version will include a mention regarding Lame in the about box. -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] possible lame LGPL violation
Am Mo, den 08.12.2003 schrieb Gabriel Bouvigne um 16:18: > Nils Faerber wrote: > > Umm... I might be wrong (and if, please excuse) but isn't LGPL exactly > > for the purpose of being able to link against LGPL'ed works and not > > violating the LGPL license, be it statically or dynamically? > Exactly, but you also have to explicitely mention which lgpl libraries > your are using. Ah OK, that might be true. > > Nonetheless I think that Lame itself is in violation of the GPL and LGPL > > since GPL and LGPL explicetly forbid patented technologies under the > > terms of the LGPL or GPL. And since there is no doubt in the fact that > > the MP3 technology is patented I even think that applying the GPL or > > LGPL to Lame is not possible at all - at least in a unaltered version. > We had an argumentation regarding this point with Stallman and the only > conclusion that was drawn was that he did not care about it. Really? That's strange since he used to be so pedantic about it. > Perhaps we should add an addendum to our license, but until now it seems > to fit quite well. That might be a good idea, yes. > The same patent point would also apply to Mpglib, Mad, the Linux kernel,... Indeed, and many other claimed to be free projects like mplayer and mostly all multimedia thingys :( The multimedia field seems liek a mine-field - you have to be very careful about any step because you are very probable to hit a patented spot :(( Concerning the Linux kernel it already has a specialised license that tries to cope with such problems. > Regards, CU nils faerber -- kernel concepts Tel: +49-271-771091-12 Dreisbachstr. 24 Fax: +49-271-771091-19 D-57250 Netphen D1 : +49-170-2729106 -- ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] possible lame LGPL violation
On Mon, 08 Dec 2003 15:48:51 +0100 Nils Faerber <[EMAIL PROTECTED]> wrote: > Please understand me right - I am the least person to fight for patents > or against the Gnu license, but I see a major problem here. Because > since there is (at least to my knowledge) a violation of Lame concerning > the Gnu license another one could possibly argue that if Lame violates > the license then the license does not apply at all and the code becomes > literally freeware without license - worst case scenario. AFAIK: software without a license isn't automatically freeware. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] possible lame LGPL violation
Nils Faerber wrote: Umm... I might be wrong (and if, please excuse) but isn't LGPL exactly for the purpose of being able to link against LGPL'ed works and not violating the LGPL license, be it statically or dynamically? Exactly, but you also have to explicitely mention which lgpl libraries your are using. Nonetheless I think that Lame itself is in violation of the GPL and LGPL since GPL and LGPL explicetly forbid patented technologies under the terms of the LGPL or GPL. And since there is no doubt in the fact that the MP3 technology is patented I even think that applying the GPL or LGPL to Lame is not possible at all - at least in a unaltered version. We had an argumentation regarding this point with Stallman and the only conclusion that was drawn was that he did not care about it. Perhaps we should add an addendum to our license, but until now it seems to fit quite well. The same patent point would also apply to Mpglib, Mad, the Linux kernel,... Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] possible lame LGPL violation
Am Mo, den 08.12.2003 schrieb Gabriel Bouvigne um 13:00: > > I think the app is probabry violating LGPL of mpglib, but I wonder > > it violates that of LAME... very suspectable, but I cannot assert. > > I am writing them a mail asking for clarification about this. Umm... I might be wrong (and if, please excuse) but isn't LGPL exactly for the purpose of being able to link against LGPL'ed works and not violating the LGPL license, be it statically or dynamically? Else all statically linked Linux binaries (against static version of GLIBC which is LGPL) for example would also violate the LGPL... and I doubt this. Nonetheless I think that Lame itself is in violation of the GPL and LGPL since GPL and LGPL explicetly forbid patented technologies under the terms of the LGPL or GPL. And since there is no doubt in the fact that the MP3 technology is patented I even think that applying the GPL or LGPL to Lame is not possible at all - at least in a unaltered version. We would have to change the license to be like the Gnu license but without reference to it and without the paragraph that forbids patented code. Please understand me right - I am the least person to fight for patents or against the Gnu license, but I see a major problem here. Because since there is (at least to my knowledge) a violation of Lame concerning the Gnu license another one could possibly argue that if Lame violates the license then the license does not apply at all and the code becomes literally freeware without license - worst case scenario. So before contacting companies about possible Lame license infringements I would double check if the license that we think applies to Lame does indeed apply the way we think... Regards nils faerber -- kernel concepts Tel: +49-271-771091-12 Dreisbachstr. 24 Fax: +49-271-771091-19 D-57250 Netphen D1 : +49-170-2729106 -- ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] possible lame LGPL violation
I think the app is probabry violating LGPL of mpglib, but I wonder it violates that of LAME... very suspectable, but I cannot assert. I am writing them a mail asking for clarification about this. -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] possible lame LGPL violation
> > I was able to find the byte sequences from the static > > const unsigned char rv_tbl[] array from > > lame/libmp3lame/fft.c in their exe (Flicker.exe > > 1.0.0.1). (using Cygwin od/grep/strings tools) > > The values are simple bit-reversed numbers. > They are common for all the FFT/FHT code and I think > it is not > sufficient evidence. I also found byte sequences from libmp3lame/i386/choose_table.nas. >From tableDEF: C:\Program Files\ImageMatics>od -tx4 -w24 Flicker.exe | grep "00010003 0001 0005000 0005 00070006 0007" 3573510 00010003 0001 00050005 0005 00070006 0007 And from choose_table_H: C:\Program Files\ImageMatics>od -tx2 -w16 Flicker.exe | grep "1810 1811 1812 1813 1914 1a14 1b15 1c15" 3601660 1810 1811 1812 1813 1914 1a14 1b15 1c15 I don't know if these are common sequences or more lame specific. __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] possible lame LGPL violation
Hi, I think the app is probabry violating LGPL of mpglib, but I wonder it violates that of LAME... very suspectable, but I cannot assert. Anyone used the software and check the output mp3 file ? I think we can say "violate or not" from it. From: Spire Spire <[EMAIL PROTECTED]> Subject: [mp3encoder] possible lame LGPL violation Date: Sat, 6 Dec 2003 17:32:43 -0800 (PST) > I was able to find the byte sequences from the static > const unsigned char rv_tbl[] array from > lame/libmp3lame/fft.c in their exe (Flicker.exe > 1.0.0.1). (using Cygwin od/grep/strings tools) The values are simple bit-reversed numbers. They are common for all the FFT/FHT code and I think it is not sufficient evidence. > The static const unsigned char slen[] in > III_get_scale_factors_1() in lame/mpglib/layer3.c also > appears. : > And static const short t24HB[] in > lame/libmp3lame/tables.c They are also common for all MP3 encoders/decoders. > Also some string constants from > lame/mpglib/interface.c and lame/mpglib/layer3.c: > > C:\Program Files\ImageMatics>strings Flicker.exe |grep mpg > > mpglib: wordpointer trashed. size=%i (%i) bytes=%i > mpg123: Can't rewind stream by %d bits! WOW, mpglib is LGPL and they are sufficient evidence. > And from lame/mpglib/interface.c: > > C:\Program Files\ImageMatics>strings Flicker.exe |grep bitstream > > bitstream problem: resyncing... HEHE, maybe this is from LAME, but these words are common for many application. And I found the below string in the binary, "fatal error. MAXFRAMESIZE not large enough." This is in the lame/libmp3lame/bitstream.c, but they are also common strings, I afraid. -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
[mp3encoder] possible lame LGPL violation
The commercial closed-source application "ImageMatics StillMotion Creator PE" appears to be statically linking with lame in violation of the LGPL. http://www.imagematics.com/PE/Product/PE_Product_Page.htm http://www.imagematics.com/Pcr2/ismc_pe.exe I was able to find the byte sequences from the static const unsigned char rv_tbl[] array from lame/libmp3lame/fft.c in their exe (Flicker.exe 1.0.0.1). (using Cygwin od/grep/strings tools) C:\Program Files\ImageMatics>od -txC Flicker.exe | grep '00 80 40 c0 20 a0 60 e0 10 90 50 d0 30 b0 70 f0' 3317060 00 80 40 c0 20 a0 60 e0 10 90 50 d0 30 b0 70 f0 The static const unsigned char slen[] in III_get_scale_factors_1() in lame/mpglib/layer3.c also appears. C:\Program Files\ImageMatics>od -txC Flicker.exe | grep '00 01 02 03 00 01 02 03 01 02' 3136020 00 01 02 03 00 01 02 03 01 02 03 01 02 03 02 03 And static const short t24HB[] in lame/libmp3lame/tables.c C:\Program Files\ImageMatics>od -tu2 Flicker.exe | grep '15134680' 3146020 5 3 1 3151346 80 Also some string constants from lame/mpglib/interface.c and lame/mpglib/layer3.c: C:\Program Files\ImageMatics>strings Flicker.exe |grep mpg mpglib: wordpointer trashed. size=%i (%i) bytes=%i mpg123: Can't rewind stream by %d bits! And from lame/mpglib/interface.c: C:\Program Files\ImageMatics>strings Flicker.exe |grep bitstream bitstream problem: resyncing... According to the FSF, "The copyright holder is the one who is legally authorized to take action to enforce the license." http://www.fsf.org/copyleft/gpl-violation.html __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
