Michael K. Edwards wrote:
It's not even interesting to me, and I hope that someone of greater legal competence sets you right and ends the discussion.Hopefully this continues to be interesting to debian-devel readers. The LGPL requires that the creator of a derivative work provide the object code for relinking, and not prohibit relinking and reverse engineering. It does not, however, require that creator to take other necessary steps to make relinking possible, such as providing a JPEG loading tool for the FLASH in an embedded device and the necessary documentation to use it. Perhaps that is why it mentions reverse-engineering - you're expected to be able to figure this out for yourself. More likely the lack of affirmative language regarding that it actually be possible to replace the program is due to a lack of foresight. At a GPL 3 planning meeting almost two years ago, I suggested that GPL 3 include affirmative language that the user must be made able to replace a program in a device if the program is at all replacable. The context of the suggestion was a discussion regarding what we would do about DRM. It was understood that once we replaced a program, the DRM facility would no longer vouch for it. But we could gain control of the overall device, perhaps minus any hardware DRM facility, by replacing the kernel. This suggestion was well received. However I can't say when GPL 3 will happen or what it will contain. However, it doesn't address your belief that certification and support obligations should survive such modifications. That's still covered by the following: Activities other than copying, distribution and modification are not covered by this License; they are outside its scope.Regarding whether or not the GPL is a contract, it is intended to be a unilateral grant of rights and does not require consent nor specific performance. Thus, I have little desire to chase down the volumes of contract cases which you offer. You can read a case on the nature of consent such as Specht v. Netscape, which might convince you that we don't necessarily get sufficient consent on the licenses that we distribute for them to bind as contracts. This seems to be one place where you have a problem. The right to sublicense is specific to the copyright grant offered. It does not connect with other contracts offered, such as offers of support, which are outside of the scope of the license. Regarding whether such things are separate covenants, you should consider that the copyright grants, including the right to sublicense, are made to all parties, while the customer must approach Red Hat with consideration in order to gain the service contract.If you accept the contention that "sublicensing" and/or "distribution" covers the performance of contractual obligations between distributor and recipient, then my statement stands. I am hoping that you can find someone whose opinion you would accept who will bring a swift close to this discussion. Thanks Bruce |
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature