[webkit-dev] Using WebKit (or KHTML/KJS) and LGPL violation

[Rob Burns]

Dear Brian,

I understand what you're saying. However, I think there Tivo (we  
don't know enough about the iPhone) took specific steps to "push" the  
GPL license. Obviously, none of these licenses have been tested in  
court, but what Tivo did is a completely different issue than the  
question of whether one could hypothetically embed these libraries in  
a device. Requiring code signing is an issue perpendicular to  
embedding (since it could take place on a desktop computer too). For  
someone simply considering embedding without adding obstacles to  
users that violate the LGPL license, section 6 shouldn't get in the way.

In my own judgement Tivo has overstepped the bounds. My hunch is that  
iPhone will be more versatile than developers imagine (that's just a  
hunch I have no special information).

take care,
Rob




On Mar 8, 2007, at 3:20 PM, Brian Campbell wrote:

> On Mar 8, 2007, at 3:05 PM, Rob Burns wrote:
>
>> Dear TG Noh:
>>
>> My sense is that lawyers would have trouble reading the LGPL  
>> license literally: mostly because they do not understand the  
>> technical issues behind this stuff. If the lawyers you spoke to  
>> think that Safari fully complies with the LGPL then in what way  
>> does Safari running on an iPhone not satisfy the LGPL? Is it  
>> because it is running on an OS loaded from a flash drive rather  
>> than a hard drive? Is it because users would not be able to easily  
>> load a different browser in its place. It's hard to imagine what  
>> these lawyers could be thinking, but my guess is that they just  
>> don't fully understand the technology.
>
> I think the issue at hand (which is fueled in large part by  
> speculation at this point) is that the iPhone has been described as  
> a "closed" system; as in, people will not be able to transfer their  
> own binaries to it and run them. I would assume that would mean  
> that they aren't able to transfer their own dynamic libraries and/ 
> or recompiled versions of Safari, either. This sounds to me like it  
> would mean that no LGPL'd code could run on it, because such  
> restrictions violate section 6 of the LGPL. On the Mac, there is no  
> issue, because WebKit is a dynamically linked library that you can  
> change at will; this is how the WebKit nightlies work, and how you  
> can run your own modified version of WebKit under Safari.
>
> As I said, this is mostly speculative at this point because we have  
> no specific information on what sorts of code Apple will allow you  
> to run on the iPhone, what kinds of modifications will be allowed,  
> and so on. However, from what I've heard, there are some very  
> concerning issues about LGPL violation. Everything I've heard says  
> that the platform will be closed, which implies to me that you will  
> not be able to run any of your own binaries on it, including  
> replacing LGPL'd libraries.
>
> It's possible that a Tivo style loophole will apply here (sure, you  
> can run your modified version of the program with the library  
> replaced, but not on our hardware), but I think this would come  
> down to what "modification of the work for the customer's own use"  
> means. I would argue that the only meaningful "use" of the version  
> of Safari (and other WebKit based apps) for the iPhone is running  
> it on the iPhone, which would mean that being a completely closed  
> system would violate the LGPL, but this is only my opinion, not  
> legal advice.
>
> I haven't been able to find references to issues like this in the  
> past, but I'm sure it must have come up. On the Tivo, all of the  
> discussion has centered around their use of DRM to prevent unsigned  
> kernels from being run, which the GPL doesn't prevent because it  
> doesn't specify that you must be able to use your modified kernel  
> on the same hardware. In this case, however, the LGPL section 6  
> specifically does mention use (as well as reverse engineering), and  
> it's the LGPL section 6 that is the operative portion that allows  
> these libraries & their derivative works to be distributed. Can  
> anyone point out any previous discussion of this sort of issue;  
> running programs that depend on LGPL'd libraries on closed platforms?