Is Sony in violation of the LGPL? - Part II
Hey,
I'm sure you've been waiting for updates that prove what we're talking about. Here it comes. I want to talk about the file ECDPlayerControl.ocx which the fanstastic muzzy found yesterday while I had nothing better to do than to listen to my pillow. It uses LAME code (and code from at least one other LGPL library).
At virtual offset 0x100607D0 you can find a function that's called GetVbrTag in the LAME source code (it can be found in the file VbrTag.c). Here's some code straight from the LAME source code (it's only the first part of the function, I don't want this post to get too long):
I also want to mention that the entire id3lib library (also LGPL software) is in the file too. Thankfully id3lib is written in C++ and not in C and therefore finding matches is significantly faster as the original function names are part of the binary files (thanks for the debug build too). Just click this link to see some of the id3lib functions in the file.
I want to summarize what we have and raise a few questions at this point:
- The LGPL is not mentioned on the CD.
- That means no copyright notice as the LGPL demands either.
- Does an OCX qualify as a linked library? Probably. But I am not able to re-create the OCX file because it contains at least two LGPL libraries and additional (probably proprietary) code. Is this necessary to be LGPL-compliant? (see the end of the article).
- Are the files part of this LGPL-licensed software by Sony? Does that have any effect on the legality of the OCX? The first two points would still stand.
All this legalese is killing me, I can only report on the code. I think we've reached a certain point where it's time to take a break. We've definitely found LGPL code in the software. Now it's time for the license gurus to find out if that constitutes a license violation. Until this is cleared up I think I'm going to do something else.
Edit: There are differences in opinion about what constitutes a LGPL infringement. Wikipedia says "Essentially, it must be possible for the software to be linked with a newer version of the LGPL-covered program. The most commonly used method for doing so is to use "a suitable shared library mechanism for linking". Alternatively, static linking is allowed if either source code or linkable object files are provided."
Does that mean everybody must be able to recreate the OCX file? Or what does that mean?
I'm sure you've been waiting for updates that prove what we're talking about. Here it comes. I want to talk about the file ECDPlayerControl.ocx which the fanstastic muzzy found yesterday while I had nothing better to do than to listen to my pillow. It uses LAME code (and code from at least one other LGPL library).
At virtual offset 0x100607D0 you can find a function that's called GetVbrTag in the LAME source code (it can be found in the file VbrTag.c). Here's some code straight from the LAME source code (it's only the first part of the function, I don't want this post to get too long):
int GetVbrTag(VBRTAGDATA *pTagData, unsigned char buf) { int i, head_flags; int h_bitrate,h_id, h_mode, h_sr_index; int enc_delay,enc_padding; / get Vbr header data / pTagData->flags = 0; / get selected MPEG header data / h_id = (buf[1] >> 3) & 1; h_sr_index = (buf[2] >> 2) & 3; h_mode = (buf[3] >> 6) & 3; h_bitrate = ((buf[2]>>4)&0xf); h_bitrate = bitrate_table[h_id][h_bitrate]; / check for FFE syncword */ if ((buf[1]>>4)==0xE) pTagData->samprate = samplerate_table[2][h_sr_index]; else pTagData->samprate = samplerate_table[h_id][h_sr_index]; ...Now compare this to the disassembly. You can easily spot "pTagData->flags = 0", the three shifts, the array access and the if-comparison (although the code was a bit optimized by the compiler). To make it easier, here's the flow-chart diagram of the function too.
.text:100607D0 GetVbrTag proc near ; CODE XREF: sub_10059240+77p .text:100607D0 .text:100607D0 arg_0 = dword ptr 4 .text:100607D0 arg_4 = dword ptr 8 .text:100607D0 .text:100607D0 mov ecx, [esp+arg_4] .text:100607D4 push ebx .text:100607D5 push ebp .text:100607D6 push esi .text:100607D7 xor eax, eax .text:100607D9 push edi .text:100607DA mov edi, [esp+10h+arg_0] .text:100607DE mov dword ptr [edi+8], 0 .text:100607E5 mov dl, [ecx+1] .text:100607E8 movzx ebx, byte ptr [ecx+3] .text:100607EC mov al, dl .text:100607EE and dl, 0F0h .text:100607F1 shr ebx, 6 .text:100607F4 shr eax, 3 .text:100607F7 and eax, 1 .text:100607FA mov ebp, eax .text:100607FC movzx eax, byte ptr [ecx+2] .text:10060800 mov esi, eax .text:10060802 mov [esp+10h+arg_0], ebp .text:10060806 shr eax, 4 .text:10060809 shl ebp, 4 .text:1006080C add eax, ebp .text:1006080E mov eax, ds:bitrate_table[eax*4] .text:10060815 mov ebp, [esp+10h+arg_0] .text:10060819 shr esi, 2 .text:1006081C and esi, 3 .text:1006081F cmp dl, 0E0h .text:10060822 mov [esp+10h+arg_4], eax .text:10060826 jnz short loc_10060831 .text:10060828 mov edx, ds:samplerate_table2[esi*4] .text:1006082F jmp short loc_1006083BI think you agree with me that this is a clear case.
I also want to mention that the entire id3lib library (also LGPL software) is in the file too. Thankfully id3lib is written in C++ and not in C and therefore finding matches is significantly faster as the original function names are part of the binary files (thanks for the debug build too). Just click this link to see some of the id3lib functions in the file.
I want to summarize what we have and raise a few questions at this point:
- The LGPL is not mentioned on the CD.
- That means no copyright notice as the LGPL demands either.
- Does an OCX qualify as a linked library? Probably. But I am not able to re-create the OCX file because it contains at least two LGPL libraries and additional (probably proprietary) code. Is this necessary to be LGPL-compliant? (see the end of the article).
- Are the files part of this LGPL-licensed software by Sony? Does that have any effect on the legality of the OCX? The first two points would still stand.
All this legalese is killing me, I can only report on the code. I think we've reached a certain point where it's time to take a break. We've definitely found LGPL code in the software. Now it's time for the license gurus to find out if that constitutes a license violation. Until this is cleared up I think I'm going to do something else.
Edit: There are differences in opinion about what constitutes a LGPL infringement. Wikipedia says "Essentially, it must be possible for the software to be linked with a newer version of the LGPL-covered program. The most commonly used method for doing so is to use "a suitable shared library mechanism for linking". Alternatively, static linking is allowed if either source code or linkable object files are provided."
Does that mean everybody must be able to recreate the OCX file? Or what does that mean?
Trackbacks
Programming stuff on : Is Sony in violation of the LGPL?
Show preview
Update: Click here
I'm sure you've already heard about the Sony rootkit that was first revealed by Mark Russinovich of Sysinternals. After the Finnish hacker Matti Nikki (aka muzzy) found some revealing strings in one of the files (go.exe) that are par
Ansel's Brain on : Analysis of alleged Sony/F4i LGPL breaches
Show preview
The following is a simple flow-chart of which actions by First4internet (F4i) would be in breach of the LGPL. This is in relation to various claims floating around the internet that the notorious Sony/F4i DRM system contains bits of code licensed unde...
Dinis Cruz on : Sony ActiveX massive vulnerabilites, CDs recall and 'Where were the AntiVirus?'
Show preview
As is well explained here Sony’s Web-Based Uninstaller Opens a Big Security Hole; Sony to Recall Discs...
Nils' Geek World on : Sony Infringing GPL License, Recalls CD
Show preview
The Sony Rootkit scandal knows no bounds. After suspending the use of the of the questionable “drm” software, Sony has now recalled the CDs still in circulation:
[W]e are instituting a program that will allow consumers to exchange any C...
Bloggin' Al on : Sony Saga Continues
Show preview
So who is violating copyright?
...
Studentene i Nord-Trøndelag on : Sony har brutt copyright regler
Show preview
Sony har tydeligvis brutt copyrightregler som beskytter open source programmet LAME.
LAME er et program for å komprimere MP3 filer. Sony har tydeligvis stjålet kode fra dette programmet for å bruke i sine egne programmer, som de selger med fortjeneste. D
Houlahoulahoulala! on : SonyBMG 2 - The Empire is stricken again
Unfortunately, the contents of this trackback can not be displayed.Hex blog on : Sony DRM
Show preview
The last week several LGPL violations were found in Sony's DRM implementation. Here is a proof of one violation. Here is a dedicated page with many other findings. By the way the license breach could be found using the simplest...
Comments
Display comments as Linear | Threaded
Zandr on :
So that's providing source for the LGPL stuff, and enough object files to link it all together.
This is why smart users of LGPL code in proprietary apps link dynamically to intact libraries. If you do that, there's no obligation to provide your proprietary code in any form, source, object, or otherwise. You just need to provide a copyright notice and the LGPL source.
sp on :
It would have probably been OK if drm.exe used lame_enc.ocx.
The problem in my opinion is however that the actual ECDPlayerControl.ocx contains a whole lot more code than just LAME code (the file containts ~5500 functions). From the point of the drm.exe file that uses the OCX everything might be fine (dynamically linked). The non-LAME code in the OCX file is however statically linked to the LAME code and that might cause a LGPL problem.
There's of course all the minor LGPL infringements nobody bothered to list anywhere AFAIK: No LGPL note on the CD, no copyright notices, ...
Let me end this comment with a straight question: Do I, the end-user, need to be able to recreate the file containing LGPL code (ECDPlayerControl.ocx)? If I do need to be able to do this would the CD need to contain the sources of all LGPL libraries used in the file and at least linkable object files for the proprietary code that's probably in the OCX too?
Scott Wheeler on :
I was once maintainer of id3lib, which incidentally is used in a lot of places (I've noticed its function signatures in RealPlayer, for example) but because a quite old version was in the public domain it's not immediately clear that it's a violation (as that's presumably the version used in those places). Couple you post a symbol dump somewhere so that I can determine if it's the LGPL'ed version rather than the old public domain version?
sp on :
John Clifford on :
Anonymous on :
Sony has done some fscked-up things, but if they never got the source from F4I, then any infringement committed by Sony is inadvertent at best.
If you payed a shwackload of money for a distribution license, and it turned out that the people you licensed it lied to you about it, how would you feel if people started attacking you for it?
Sony needs to be nailed to the wall for distributing this crap, but First4Internet needs to be nailed to the wall for writing it, AND for violating the LGPL.
sp on :
You're absolutely right. In yesterday's post I talked about Sony because the case gained worldwide attention as the Sony DRM case. First4Internet was basically unknown until a few days ago.
Today I wanted to clear that up but forgot it in the heat of the moment. From now on I'll make sure to mention First4Internet instead of Sony where appropriate. It's entirely possible that Sony was screwed over by F4I too.
Intangir on :
sonies DRM wasnt written by first4internet... was it? i hadnt heard them mentioned till after the uninstaller security hole
sony has gotten caught big time, they released software to 'protect their rights' which trampled on everyone elses, and they unethically illegally insecurely incompitently blatently abused their own customers in the process.
sp on :
Cornelius J Rat on :
Nathan Myers on :
Claim whatever time it took to fix up your system. Claim damages for your LGPL code, if you have any. Claim the time it takes to bring the case to court, including your lawyer's fees.
[p.s. I'm no lawyer, this is not legal advice.]
NG Byrd on :
Document, document, and document everything you do to correct the rootkit on your PC. If you hire a geek to fix it get them to agree to testify or provide a written statement. If you fix it yourself remember that your time is money. Google for small claims in your state so you do things right. IANAL (I am not a lawyer).
If you are a coder and suspect that your code copyrights have be violated, then by all means get a lawyer and file in full superior court. Again, IANAL.
Ansel on :
sp on :
Dan on :
=================================
6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications.
=================================
The EULA, I'm pretty sure, forbids reverse engineering.
sp on :
As I found LGPL library data (or actual code) in all four files I looked at, I do not see myself and my reverse engineering work in breach of the F4I EULA. It's the F4I EULA that's invalid because it contradicts what the LGPL demands, which explicitly allows reverse engineering.
Dan on :
Mat on :
None on :
Anonymous on :
Yes, exactly. The complete sources of the library need to be available either being shipped together with the binary or delivered on demand without additional hassles. Neither with GPL nor with LGPL it's possible to omit source files needed to make the binary which uses L/GPL'ed code.
Frank on :
Anonymous on :
Marc on :
What would be the odds that strings from that library would end up in their files but the identical code is just a coincidence?
I'm thinking "yeah, and monkeys might fly out of my butt" odds.
Barry on :
sp on :
JD on :
Come on, you know they would seize your computers in a heartbeat, do it to them. Now!
James Hightower on :
Cornelius J Rat on :
Anonononymous on :
However if this is a debug build like you say, that explains why you are seeing symbols
KL on :
how stupid can they be?
violate a number of copywrites and then ship and sell millions of debug builds telling everyone what they did.
my guess is, by all the code research, that F4I actually just copies together all the code from many sources.
and the second guess is, they have been to stupid to build a release version, because of linker settings
how poor
Anonymous on :
Some years ago I've coded an MP3 player and it uses the exact same code to check for ID3V2 tags. And it was done solely by following the official specification.
You should look for something better. There were some posts which found an rot13 copyright message. That's much more powerful.
Joe Blow on :
Anyone have Sony stock? Now is time to get the stuff unloaded, while you still can
Anonymous on :