Using WebKit (or KHTML/KJS) and LGPL violation

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Using WebKit (or KHTML/KJS) and LGPL violation

Noh Taegil

This maybe not an exact place to ask this question but, I'm still  
confused and would be very happy to get any advice at all.

One of our customer's IP/Legal team informed us that putting LGPL  
library in a closed system which prohibits any form of reverse-
engineering, or which is lack of ability to install library, is a  
direct violation of LGPL. And they also told us that, they don't  
understand how Apple would use LGPL library in their (to be) closed-
system. (namely , iPhone)

----

I'm working in a small software company that helps a mobile phone  
vendor (lets call them company S) We developed and shipped DRM, MMS,  
and OMA(wap) browser for them. We have failed to make a decent web  
browser, and that's where WebCore came in.

Recently I could almost convinced my boss and the company S into  
using WebCore as default web engine for their new mobile platform. We  
could actually made a working demo on their system, and they agreed  
to open the modified source code themselves, but they frowned at LGPL  
section 6 :



My (possible) business model using WebKit, was something like this ;

1) Let's maintain a WebCore Windows Mobile port : On Windows mobile,  
still you only have NetFront3 or Opera. They cost quite some amount  
for individual users (something over $20 to register) . Let them use  
top notch browser freely. Put "notice" clearly that we are quite  
expert on porting browsers on "things".

2) Wait for more embedded device vendors to "aware" us. Made a good  
abstraction layer, port webcore and a decent UI on any device they  
want. (IPTV, PMP, portable DVD players, etc)  Get some service fee  
and customize the browser for them. If they need WAP2.0, terrific.  
Sell our old browser with it.  Get Maintenance contract with them.

3) Drop our own Web Browser development, it's going nowhere.

----

I though this scenario could be quite valid; Nokia N series devices  
are already a successful example. But it seems that this goes very  
close to the LGPL violation boundary. Company S told us that, When  
reading literally, even Nokia isn't satisfying LGPL.

Nokia N series device do not have any LGPL license text for users.  
Normal users won't be able to aware about the LGPL library or  
license. (possible violation 1. selling H/W with LGPL Library is a  
"distributing"). And there is no way for users to change and run S60  
Browser. (although they can run the reference UI) And the reverse  
engineering is prohibited as usual. (Possible violation 2. No method  
for modify LGPL'ed library and run the work based on the library)

----

My questions is simple. Is that really LGPL violations? Safari  
Browser is satisfying all LGPL "duties" (It shows credits, LGPL  
license, and you can rebuild webcore and run safari with it. Done.)  
But how safari on iPhone will satisfy LGPL?
Company S's lawyer read LGPL "literally". But lawyers always do. What  
is the limit of using webCore(KHTML, or any LGPL library) on embedded  
devices?

Any comment from S60 guys? I'm pretty sure that Nokia IP/Legal team  
gave them "clear" sign, so It is there. That's why I am so confused  
right now.

TG Noh
[hidden email]


_______________________________________________
webkit-dev mailing list
[hidden email]
http://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|

Re: Using WebKit (or KHTML/KJS) and LGPL violation

Rob Burns-3
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.

The iPhone serves as a nice example (especially if there's agreement  
that the Safari on other OS X devices complies with LGPL). I would  
ask these lawyers what they think are the key differences between  
Safari on iPhone and Safarii on a MacBook, (for example); or Safari  
on a MacBook with a flash drive. Do they assume that Safari on the  
iPhone would not provide a mechanism to read the LGPL license/credits?

I would say that even if one reads section 6 as meaning that the LGPL  
makes the terms more stringent for embedded systems than for non-
embedded systems (i.e., that if you embed you have to open the source  
to a linking executable and not just provide a dynamic linking  
mechanism), then it strikes me that an embedded system could instead  
comply with section 6 in a different manner (with subsection b). An  
embedded WebCore could  provide a mechanism (through the embedded  
devices syncing mechanism for example) to swap the WebCore library  
with a recompiled WebCore library. In this way you've satisfied  
section 6B. Now, not many users are going to take advantage of such a  
feature. But you probably want to be able to easily do that for your  
own development needs anyway.

Keep in mind that the LGPL applies to WebCore (and users/developers/
executables who link to it), but not to WebKit. In other words, LGPL  
does not direct its licensees to limit the behavior of their sub  
licensees. So if you link against WebKit, then your executable is  
subject to the terms of WebKit's BSD license (not to WebCore's LGPL  
license). WebKit already complies with WebCore's LGPL license section  
6 by make the source code available (it offers four of five section  
six mechanisms ā€” a, b, c, dā€” when it was only required to provide 1).

Whenever you're talking to someone who claims to have THE literal  
reading of something, they're probably not going to be easily  
convinced that there are other readings. However, I think your  
conceived business model sounds like it could definitely work with  
WebKit (provided you don't face the same lawyers at every turn). I  
for one would love to see WebKit embedded on more devices (like my  
dishwasher for example:-). But seriously, how about WebKit on a  
printer so that I can get WYSIWYG printing by sending an URL to my  
printer instead of an entire rendered document. Plus that would  
motivate better paged media features in WebCore/WebKit.

Anyway, I hope that give you some ammunition for the lawyers. I'd  
love to hear what they have to say to these technical issues.

Take care,
Rob


On Mar 8, 2007, at 8:34 AM, Noh Taegil wrote:

>
> This maybe not an exact place to ask this question but, I'm still  
> confused and would be very happy to get any advice at all.
>
> One of our customer's IP/Legal team informed us that putting LGPL  
> library in a closed system which prohibits any form of reverse-
> engineering, or which is lack of ability to install library, is a  
> direct violation of LGPL. And they also told us that, they don't  
> understand how Apple would use LGPL library in their (to be) closed-
> system. (namely , iPhone)
>
> ----
>
> I'm working in a small software company that helps a mobile phone  
> vendor (lets call them company S) We developed and shipped DRM,  
> MMS, and OMA(wap) browser for them. We have failed to make a decent  
> web browser, and that's where WebCore came in.
>
> Recently I could almost convinced my boss and the company S into  
> using WebCore as default web engine for their new mobile platform.  
> We could actually made a working demo on their system, and they  
> agreed to open the modified source code themselves, but they  
> frowned at LGPL section 6 :
>
>
>
> My (possible) business model using WebKit, was something like this ;
>
> 1) Let's maintain a WebCore Windows Mobile port : On Windows  
> mobile, still you only have NetFront3 or Opera. They cost quite  
> some amount for individual users (something over $20 to register) .  
> Let them use top notch browser freely. Put "notice" clearly that we  
> are quite expert on porting browsers on "things".
>
> 2) Wait for more embedded device vendors to "aware" us. Made a good  
> abstraction layer, port webcore and a decent UI on any device they  
> want. (IPTV, PMP, portable DVD players, etc)  Get some service fee  
> and customize the browser for them. If they need WAP2.0, terrific.  
> Sell our old browser with it.  Get Maintenance contract with them.
>
> 3) Drop our own Web Browser development, it's going nowhere.
>
> ----
>
> I though this scenario could be quite valid; Nokia N series devices  
> are already a successful example. But it seems that this goes very  
> close to the LGPL violation boundary. Company S told us that, When  
> reading literally, even Nokia isn't satisfying LGPL.
>
> Nokia N series device do not have any LGPL license text for users.  
> Normal users won't be able to aware about the LGPL library or  
> license. (possible violation 1. selling H/W with LGPL Library is a  
> "distributing"). And there is no way for users to change and run  
> S60 Browser. (although they can run the reference UI) And the  
> reverse engineering is prohibited as usual. (Possible violation 2.  
> No method for modify LGPL'ed library and run the work based on the  
> library)
>
> ----
>
> My questions is simple. Is that really LGPL violations? Safari  
> Browser is satisfying all LGPL "duties" (It shows credits, LGPL  
> license, and you can rebuild webcore and run safari with it. Done.)  
> But how safari on iPhone will satisfy LGPL?
> Company S's lawyer read LGPL "literally". But lawyers always do.  
> What is the limit of using webCore(KHTML, or any LGPL library) on  
> embedded devices?
>
> Any comment from S60 guys? I'm pretty sure that Nokia IP/Legal team  
> gave them "clear" sign, so It is there. That's why I am so confused  
> right now.
>
> TG Noh
> [hidden email]
>
>
> _______________________________________________
> webkit-dev mailing list
> [hidden email]
> http://lists.webkit.org/mailman/listinfo/webkit-dev

_______________________________________________
webkit-dev mailing list
[hidden email]
http://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|

Re: Using WebKit (or KHTML/KJS) and LGPL violation

Brian Campbell-6
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?
_______________________________________________
webkit-dev mailing list
[hidden email]
http://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|

Re: Using WebKit (or KHTML/KJS) and LGPL violation

Rob Burns-3
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?

_______________________________________________
webkit-dev mailing list
[hidden email]
http://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|

Re: Using WebKit (or KHTML/KJS) and LGPL violation

Darin Adler
On Mar 8, 2007, at 6:34 AM, Noh Taegil wrote:

> This maybe not an exact place to ask this question

I'd prefer it if we steered clear of discussion of legal issues like  
these on this mailing list.

While the information may be handy for some, there are other people  
who can't participate at all in a mailing list where these sorts of  
topics are discussed.

     -- Darin

_______________________________________________
webkit-dev mailing list
[hidden email]
http://lists.webkit.org/mailman/listinfo/webkit-dev