| |||||||||||||
Similar in spirit?Similar in spirit?Posted Oct 6, 2006 21:46 UTC (Fri) by nim-nim (subscriber, #34454)In reply to: Similar in spirit? by pimlott Parent article: Similar in spirit?
Your scenario is not credible.
0. Your use of a checksum muddies the water somewhat, because it implies a 1<->1 relationship between authorization and software version. But a fixed checksum list would be of little use, so the list itself must be updateable, and the checksum of the update list is unknown beforehand, which means you have a master key somewhere which can approve any checksum or list, which takes us back to square one.
1. The media player company is not distributing its binary in the hope that, maybe, a media distributor will pick it up, approve it, and it will end up in the device. They have contracts with all these entities if only to get paid. If they take the money without ensuring the licensing obligations are respected, they'll be condemned.
2. Even assuming it does release a binary without any counterpart or contact with the other companies, I believe that by ensuring it can made its way on the device they are participating it its distribution, and have to honor the licensing obligations. Certainly should they approve a binary containing sequences "lifted" from an Hollywood media they wouldn't expect not to be sued.
This is a general weakness of many of the examples provided so far. You all assume that because the GPL "payment" is not monetary, or due to hobbyists, it's somehow optional or weak and you only need to make the situation complex enough before people give up. The law does not work this way.
Before you post any other scenario, take the time to replace "GPLed software" with "Hollywood film" and "GPL licensing obligations" with "Hollywood film licensing obligations". If your house of cards wouldn't protect you when distributing an "Hollywood film", do you actually believe using it for a "GPL software" will work any better before the judge?
Also, do remember that no judge will rule that since you're broke, you didn't have to pay at the shop. He'll rule that since you're broke, you shouldn't have taken what you couldn't afford (and send you to jail). Likewise, being in no position to honour GPL licensing obligations does not give you a free pass at GPLed software. Especially if you've painted yourself in this corner knowingly.
(Log in to post comments)
Similar in spirit? Posted Oct 6, 2006 22:31 UTC (Fri) by pimlott (guest, #1535) [Link] I agree that the weak point in my scenario lies in the relationships between the parties. If you can show that the media player maker is colluding with the device manufacturer or the media distributors to keep users from exercising their rights, you might be able to use the GPLv3 against them. But I am not as sanguine about this as you: I still fear that courts would not consider my scenario (or some variation) collusion. DRM is still an experiment, and we should keep an open (that is, cynical) mind about all of the imaginitive ways in which the media industry will try to use it.On your point 0: the checksum list is maintained by the media distributor, so there is no need for a master key. Also, you seem to have made some interpretation I didn't intend about what's in the media player binary. At least, I don't know what "sequences 'lifted' from an Hollywood media" refers to. What I had in mind is simply that the media player only plays files signed by the media distributor's public key and enforces use restrictions specified in the files. If I offered such a binary (along with its sources) on my web site, having no relationship with any device manufacturer or media distributor, just to be ornery, surely I wouldn't be violating any license.
Similar in spirit? Posted Oct 7, 2006 12:38 UTC (Sat) by nim-nim (subscriber, #34454) [Link] > On your point 0: the checksum list is maintained by the media> distributor, so there is no need for a master key.
And how do the device knows it can accept a new checksum list? If it can not at all or if it can accept anyone your system is pretty useless
> Also, you seem to have made some interpretation I didn't intend about
Let me rephrase it then:
1. Let's say Disney decides to participate in a campaign against evil_of_the_day and makes a great mickey cartoon freely distributable provided it's alway bundled with the latest localised update of education_pamphlet_against_evil_of_the_day
2. one of your nebulous entities authorizes the video for a device sold all over the world, but does not bother with the education_pamphlet_against_evil_of_the_day, or all the localized versions, or ignores updates
3. another of your nebulous entities makes the authorized binary available advertising it can be played in media player
Questions:
Similar in spirit? Posted Oct 9, 2006 3:38 UTC (Mon) by pimlott (guest, #1535) [Link] And how do the device knows it can accept a new checksum list?The device doesn't need the checksum. The device merely reports the checksum to the media distributor, which validates it against its own (self-maintained) list. Let me rephrase it then:[snip] I think I understand your scenario, but I truly think the outcome is sensitive (as in my scenario) to the details of the relationships between the entities, and their intentions. If the entity in (3) is advertising the authorized binary for use in many media players, maybe they can say, "hey, it's not our fault that the device in (2) refuses to view the pamphlet--every other device views it". To repeat, I agree that there may be grounds for finding a GPLv3 violation in some cases like I described; however I don't agree that it is clear-cut for all cases.
Similar in spirit? Posted Oct 9, 2006 15:33 UTC (Mon) by kleptog (subscriber, #1183) [Link] The device doesn't need the checksum. The device merely reports the checksum to the media distributor, which validates it against its own (self-maintained) list.Well, that's obviously not going to work. Then I can simply set the code to return the expected checksum while actually running something else. For a remote entity to verify you're actually running a particular binary is hard. The act of sending the checksum becomes the weak link, because some upstream router can just change it. So instead, the device has to fetch a list of valid checksums and have some TPM of its own to verify the checksum against the list. It's the verifying of an authentic checksum list that is the crucial part, and where of use of encryption keys comes from.
Similar in spirit? Posted Oct 9, 2006 16:10 UTC (Mon) by pimlott (guest, #1535) [Link] Then I can simply set the code to return the expected checksum while actually running something else.As I said earlier in this thread, the device (with its proprietary operating system) "supports trusted remote querying of the running software". The query protocol naturally ensures the authenticity, integrity, and confidentiality of the communication. You or an upstream router can't tamper with it. The media distributer can be sure that it is talking to the unmodified operating system and getting trustworthy checksums.
|
|||||||||||||