| |||||||||||||
|
| |||||||||||||
Bruce Perens: State of Open SourceBruce Perens: State of Open SourcePosted Apr 7, 2006 4:03 UTC (Fri) by dlang (✭ supporter ✭, #313)In reply to: Bruce Perens: State of Open Source by BrucePerens Parent article: Bruce Perens: State of Open Source
I wasn't the origional poster, but I think that Linus is right on this (at least based on the draft distributed so far).
it's not what the FSF INTENDS the effect to be, but it's what the letter of the license requires.
as an extreme, exagerated example.
it would be easy for me to build a box that only ran software signed by RedHat (and downloads the software from the redhat servers so I don't have ti distribute any GPL software at all). At this point redhat would be in violation of the GPLv3 becouse the box requires things be signed by their key and they are not distributing their key. I don't need to have the redhat secret key to make this box.
I don't see a way to allow this sort of distribution without opening up other loopholes that would allow companies to conspire to meet the same requirements as the exception.
I will add for the record that I have been an owner of a Tivo for many years, and hacked mine (including modifying the BIOS) within a week or so of purchasing it. I fully understand what the FSF is trying to do with these provisions (and mostly agree with it), but I think that their methods are doomed to failure due to the fact that the hardware manufacturer is not always going to be the software manufacturer, so useing copyright law to restrict what the hardware manufacturer does just doesn't work.
David Lang
(Log in to post comments)
hypothetical case vs. GPLv3 Posted Apr 7, 2006 4:30 UTC (Fri) by stevenj (guest, #421) [Link] As a common-sense matter, nothing you do independently as a third-party (short of announcing a patent that covers the work) can make Redhat suddenly be in violation of the GPL. And, indeed, the draft text of the GPLv3 seems to present no problems in your hypothetical case: Complete Corresponding Source Code also includes any encryption or authorization codes necessary to install and/or execute the source code of the work, perhaps modified by you, in the recommended or principal context of use, such that its functioning in all circumstances is identical to that of the work, except as altered by your modifications. Since use in your signed-only hardware, assuming you are entirely independent of Redhat, is hardly going to be the "recommended or principal context of use" as promoted by Redhat, they aren't going to be required to give you their keys. So, no one would be in violation, which isn't a problem since this isn't the sort of situation the GPLv3 is intended to prevent. On the other hand, if you are someone like Tivo and distribute modified GPLed software designed specifically to work with your hardware, then you can't lock up the keys required to run the software on your machine. It's a good thing the FSF has expert legal counsel to help them with the wording, right?
Oh, my darling flamefest :-) Posted Apr 9, 2006 19:43 UTC (Sun) by hummassa (subscriber, #307) [Link] It just proves that a pay-only site can have trolls, too...Well, back to the point: "It's a good thing the FSF has expert legal counsel to help them with the wording, right?" If this is true, then why can't Eben Moglen strike the horrible wording "derivative works under copyright law, that is to say..." in section #0 ?? this is really horrid, and it's in the GPLv3 draft, also.
Oh, my darling flamefest :-) Posted Apr 10, 2006 0:32 UTC (Mon) by BrucePerens (subscriber, #2510) [Link] Can you please write up your concern? Copy it to bruce at perens.com and moglen at columbia.edu .Thanks Bruce
Oh, my darling flamefest :-) Posted Apr 10, 2006 6:18 UTC (Mon) by sepreece (subscriber, #19270) [Link] This particular issue (that the text of the current draft "explains" what "derivative work" means in a way that doesn't match the law very well) has been noted in a number of comments on the GPLv3 site, so I think Eben Moglen should be aware of it.
Oh, my darling flamefest :-) Posted Apr 10, 2006 6:26 UTC (Mon) by BrucePerens (subscriber, #2510) [Link] Oh, then if you are really concerned, you might want to ask what his plans are regarding that language.I went to his BOF in Boston last week, and met with him in NY on Friday. It was clear to me from both occassions that lots of text would change. Bruce
Oh, my darling flamefest :-) Posted May 16, 2006 15:29 UTC (Tue) by hummassa (subscriber, #307) [Link] Hello Bruce; I have sent the following e-mail to Eben Moglen, cc: you, andI'm registering it here, as well as commenting on the GPLv3 draft:
Hello Professor Moglen.
I am a Systems Developer in Minas Gerais' State Assembly, Brasil. Our
I have also had a two-year legal training, and a two-year experience as a
I am writing this, as suggested by Bruce Perens, to call to your attention
0. Definitions.
The ambiguous language I refer to is the complex sentence that begins in
I have entered some comments in the draft wiki, and my suggestions are
(1) eliminate the "that is to say ... unmodified" ([3] .. [5]) part
(2) substitute [3] .. [6] for: << a derivative work under copyright law,
I hope this issue is cleared in the new version of the GPL, because this
I thank you very much for all the great work you have done to further the
Humberto Massa
"Linus is right"? Posted Apr 7, 2006 4:35 UTC (Fri) by stevenj (guest, #421) [Link] By the way, it's a bit strange for you to say that Linus is "right" and then come up with anobjection that has nothing whatsoever to do with what Linus has argued (as far as I can tell). Try not to use Linus' name to back up your own arguments.
Bruce Perens: State of Open Source Posted Apr 7, 2006 4:50 UTC (Fri) by BrucePerens (subscriber, #2510) [Link] it's not what the FSF INTENDS the effect to be, but it's what the letter of the license requires.But the nature of Linus' complaint wasn't this is bad wording. So, do you feel that Linus mis-interpreted FSF's intent? Bruce
Bruce Perens: State of Open Source Posted Apr 7, 2006 16:08 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link] Bruce,as I see it there were two issues in Linus' initial post.
1. the GPLv3 can force people to reveal secret keys in situations that violate common sense.
2. disagreeing with the goal of the FSF in trying to ban tivo-like devices.
the huge outcry has been that Linus is an idiot who can't read and the GPLv3 doesn't do anything like #1. having read through it I don't think that Linus is wrong. I think that the wording that the FSF has selected can have exactly that effect.
for the other poster above who said that in my example redhat wouldn't have my box as the 'primary inteneded use' of the software so it wouldn't apply, if that's all it takes it's pretty easy for a company to have an official 'primary intended use' for something that doesn't involve a locked down box, but that also gets used on a locked down box and at least argue plausably that they are not violating things. This is why I say that either the GPLv3 could require the revealing of secret keys in obviously inappropriate conditions or there are loopholes large enough to make it meaningless if a company wants to beat it.
now when you start discussing #2 things get quite a bit trickier. I personally don't have a problem with a company shipping a locked-down box becouse it is just too easy for a determined person to break anything they do (I don't consider having to replace or reprogram a prom unreasonable). witness the x-box mod-chips as an example of the market at work to produce hardware patches that anyone can install.
the problem comes when such hardware modifications are made illegal (which is happening with the xbox mod chips), but I don't think that software copyright law is the appropriate tool to deal with this problem (and I do believe that this is a major problem)
David Lang
loopholes Posted Apr 7, 2006 17:50 UTC (Fri) by stevenj (guest, #421) [Link] for the other poster above who said that in my example redhat wouldn't have my box as the 'primary inteneded use' of the software so it wouldn't apply, if that's all it takes it's pretty easy for a company to have an official 'primary intended use' for something that doesn't involve a locked down box, but that also gets used on a locked down box and at least argue plausably that they are not violating things. I didn't say "primary intended use". I used the words in the (draft) GPLv3: "recommended or principal context of use". And so should you. Your claim is not very plausible. If you ship a locked-down box bundled with GPL-derived software that has been modified to add DRM, then it seems very hard to argue with a straight face that you are not "recommending" that users employ the software you give them with the hardware you sell them. Yes, you could try to imagine a hypothetical DRM hardware maker who doesn't include software with their device, but rather requires you to download it from some third party who has nothing to do with DRM, but that is quite a stretch. First, forcing hardware manufacturers to not bundle the software customers need to use the hardware is imposing quite a penalty on them. Second, it seems unlikely that if you want to enforce DRM you're going to rely on the cooperation of a third party who has no financial interest in enforcing DRM on your hardware. By all means, bring this up with the GPLv3 committees (and for the same reason, it's probably not worth arguing more about it here). However, I'm inclined to give some credence to the ability of a law professor who has spent years enforcing the GPL, and thereby inclined to doubt any random fellow who claims there are "obviously" huge loopholes.
loopholes Posted Apr 8, 2006 1:33 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link] you misunderstood what I said
I said that I ship a DRM'd hardware box with NO GPL software. I have the propriatary loader on that box set to go out to a public webserver, download GPL software that's signed and install it only if the signature is valid.
at this point I have not distributed any software so no provisions of the GPl apply to me. but they would apply to the people who ship the software.
and if you depend on the "recommended or principal context of use" phrasing then recognise that it's very possible to use this as a loophole (and how large this loophole can be). trying to define the "recommended or principal context of use" is a process that can very easily be muddied. all it takes is to have one company that distributes a package that can be used for multiple things, some of which are legit by anyone's standards, some of which are of the tivo catagory. at that point it's really hard to argue sucessfully that company B's use of their software is their "recommended or principal context of use".
loopholes Posted Apr 8, 2006 15:42 UTC (Sat) by stevenj (guest, #421) [Link] Um, I addressed this very point in my third paragraph. Your hypothetical example is circumventing the GPLv3 for the sake of circumventing it, and doesn't seem practical for DRM or for hardware vendors.
Bruce Perens: State of Open Source Posted Apr 8, 2006 16:40 UTC (Sat) by BrucePerens (subscriber, #2510) [Link] David, I think the current GPL text can force people to not use secret keys at all for certain situations, like preventing the kernel from executing. It does not necessarily prevent DRM from being implemented for media, especially in a user-mode program or a piece of hardware accessed by a user-mode program.Thanks Bruce
Bruce Perens: State of Open Source Posted Apr 8, 2006 20:32 UTC (Sat) by Ross (subscriber, #4065) [Link] "it's not what the FSF INTENDS the effect to be, but it's what the letter of the license requires."
If that was the point, then why didn't he work with the FSF to change the wording to match their intent? It seems that it is the perfect time to do that -- when they are seeking input. Instead he said that it wouldn't work and he wasn't going to use it. That really comes across as disagreeing with the intent, or not trusting that the intent was as stated by the FSF.
Bruce Perens: State of Open Source Posted Apr 10, 2006 6:33 UTC (Mon) by sepreece (subscriber, #19270) [Link] I think that Linus does, in fact, disagree with the intent of the current draft, not just the wording. Some of the interviews reported since the initial flap have him saying pretty directly that he doesn't think Tivo-ization should be against the rules.
I think this illustrates very nicely the danger in licensing things using the "or any later version" language. The FSF says the new version is in the same spirit as the original, but quite a few people have said (on the GPLv3 site, in comments in discussion sites, and in personal conversations I have been privy to) that the actual impact of the license in this particular area is significantly different from the previous version and that they prefer the GPLv2 version to the additional restrictions of the current GPLv3 draft. Using the "or any later version" language means giving up the right to react to such changes in future versions.
Bruce Perens: State of Open Source Posted Apr 10, 2006 6:43 UTC (Mon) by BrucePerens (subscriber, #2510) [Link] But using the "later version" language makes it easy to fix the problem if your license text has a legal problem that needs to be corrected. And it does that without your having to do odious things like require copyright assignment or get a separate right to relicense from every contributor.If you're going to use that "later version" language, the FSF is one of the organizations that would be easiest to trust. It's a legal non-profit with a leader who literally dedicates his life to Free Software, something I won't do, and a damn good lawyer. I've actually been opposing expert to Moglen in a case, he's really good. Too bad the case sealed and you won't read about it. Yes, Richard is hard to get along with. But everything he forecast in the eighties is coming true around us today. Maybe he'll be right again. Bruce
Bruce Perens: State of Open Source Posted Apr 10, 2006 18:44 UTC (Mon) by sepreece (subscriber, #19270) [Link] I'm not sure that you can get a functionally useful "repair" through the "or later version" clause, because it never takes away the "GPLvX or" part. That is, that language allows a downstream recipient to apply the terms of any license included, so the repair could not override the version that had the problem.
On the other hand, that same fact vitiates the concern I expressed, since licensing something as GPLv2 or later always allows the more liberal terms of GPLv2 to be used as well as the more restrictive terms of a later version (assuming some later version is more restrictive, as the first draft of GPLv2 is). I had failed to think that through.
So, using the "or later version" language would be a problem if you objected to some later version making the terms more liberal, but not if you objected to some later version making the terms more restrictive.
|
|
||||||||||||