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
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
