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):
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_1006083B
I 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?