"brand names of those two wholly American lifestyle products"
For some reason, you are trying to substitute Uzi and Nissan for "wholly American lifestyle products" which yields the completely illogical conclusion that Uzi is a brand name of an Uzi, and Nissan is a brand name of a Nissan.
The products are cars and guns. The brand names are Nissan and Uzi.
Why don't you type http://www.nissan.com/ in a browser and find out?
Mr. Nissan owns a computer business that makes use of his name, Nissan Computer Corporation. It is a perfectly legitimate use of his name and of the nissan.com domain.
This case seems slightly similar, even if it does have a different twist. One important point is that I only read about a C&D letter being sent; I saw nothing about a lawsuit being filed... yet.
HTML, and this should not be breaking news to you, is a markup language. It is meant for display. What other uses do you think people should have for it?
Also, HTML was not designed to be stateless, HTTP was. And, since it seems you have not heard, there is a mechanism in HTTP for maintaining state. It is called cookies. See RFC 2109, HTTP State Management Mechanism.
Well, your items 1 and 4 seem identical to me, and this is also something that depends on the design much more than the language.
My application designs always separate presentation from logic, but that's because I choose to. It might not be worth the extra complication for simpler solutions. After all, being able to embed PHP in HTML is part of why it has been so successful. However, this is just a feature of the language, not an enforced characteristic. For some reason, this seems to be a big misconception for many people.
You can have functions that generate the presentation in your format of choice (HTML, XML, etc.), static files that you include, or whatever. I've written code in most every Web scripting language (though very little with ASP), and I never felt more or less restricted in this regard with any of them. No language automatically designs your application for you.
Oh, and PHP has always had native database support for several databases. This is actually one of the complaints against it, as people like to write code that fits an abstraction layer instead, allowing them to switch databases. However, find some performance studies, and look at how well PHP performs with query-intensive applications.
Your other points are all valid, though I for one have never understood the praise for OO.
Re:Perl was ruled out WHY???
on
Yahoo Moving to PHP
·
· Score: 2, Insightful
More secure?
See, this is where I cannot help but assume that you are inexperienced. If you think a language can make your applications more secure, then you have a fundamental misunderstanding about developing Web applications.
As for maintaining large applications, I can tell you that with proper software architecture employed, PHP is going to be plenty easy to maintain. When you look at the big picture, you need an application that new employees can contribute to after the shortest amount of training possible. Can you honestly tell me that Perl has an advantage here?
A better analogy is whether it is illegal for someone to call me if I have an unpublished number.
Whether someone finds me in a phone book, gets my number directly from me, gets my number from a friend, or guesses my number, the actual phone call is the same.
These anlogies about open doors are misleading, because it is intuitive to think that one should not simply walk into a stranger's house, even if the door is open.
However, if the open door were to a store in a mall, you would probably not think anything was wrong with just walking right in or even telling others about what you saw inside (or where the store is located). Just because the store wasn't listed in the mall directory doesn't make it illegal.
I have read the law, the depositions, the transscripts of the hearings, Kaplan's ruling, etc.
It seems to me that you should read the ruling, among other things. Try some of the documents listed here:
http://cryptome.org/cryptout.htm#DVD-DeCSS
While you claim to comprehend the letter of the law, you seem to have some misunderstandings about the spirit of the law as interpreted by Kaplan. It is the spirit of the law that creates precedents that are arguably as strong as the law itself. The danger of such precedents is the major factor in the EFF and 2600's decision to drop the appeal.
You seem to be taking an extremely strict interpretation of a rather vague clause in the DMCA. Perhaps if people like Kaplan did the same, it wouldn't have created such a predicament. Your statement, "the idea of whether something is "useful" for gaining access to a copyrighted work is irrelevant as far as the DMCA is concerned," illustrates this. This is not entirely irrelevant to a judge.
Given this testament of your opinion, do you honestly think the MPAA would have had such an easy time against the New York Times, who posted a similar story also containing a link to DeCSS? Of course not. The fact that 2600 is "The Hacker Quarterly" combined with the stigma surrounding the word hacker contributed largely to the success of the MPAA's case. Did you read anything about that in the DMCA? I didn't think so.
The following book is also a good resource for these issues:
http://www.digital-copyright.com/
Finally, pertaining to Sklyarov's case, did you hear about anyone arresting him at the airport? How about in his hotel the night before? Did he just sneak to the conference and not get "caught" until after his speech?
Sure, he was prosecuted for trafficking in a circumvention device. And, I suppose 2600 was prosecuted for illegally copying DVDs, right?
Don't let "the prosecution" confuse you. That's their job. They are going to take the strongest approach to win their case, and it's rarely going to be the truth. This isn't unique to DeCSS cases. While I am not suggesting we all subscribe to conspiracy theories, I don't think it's a good idea to be completely naive either. You seem to disagree.
Though your statements are mostly correct, you seem to be missing the point.
It is not the author of the information that needs to use the tool to gain unauthorized access to a copyrighted work. Do you think they had to prove that Dmitry Sklyarov accessed copyrighted information through the use of the tool he helped create? No. Did they prove that 2600 used DeCSS at all? No.
If it is possible that someone else could use the information you publish or the tools you create to gain unauthorized access to a copyrighted work, you are in potential danger of prosecution. Yes, prosecution is not guaranteed, and in this case it seems remote, but why should anyone have to take that risk? These people chose not to take that risk and used the opportunity to point out one absurdity of US law.
The statement that security information cannot be interpreted as a means of circumvention is more than a bit naive. 2600 posted a link to software that someone else had written that someone else could have possibly used to gain unauthorized access to content on a DVD they purchased. They got sued under the DMCA, and it was a strong enough case to win. Describing a security flaw in order to justify the necessity of an associated patch is also nearly identical to the talk Dmitry gave that landed him in prison.
Comparing DeCSS to this situation is tricky. In the DeCSS case, source code was ruled to not be speech. The source code to DeCSS was deemed to be useful for circumventing CSS in order to gain access to a copyrighted work. English descriptions of the code were not useful for circumventing CSS, though they could arguably be used to achieve the same result.
With detailed security information and the associated patch, we can draw a parallel to DeCSS source and the English descriptions, respectively. Though this seems counter-intuitive, this correlation represents the risk that is being avoided in this situation. The patch itself fixes a security vulnerability and is not useful for gaining access to a copyrighted work. So, even though it is code like DeCSS, the primary purpose of each contrast sharply. However, whereas descriptions of DeCSS were much less useful for gaining access to a copyrighted work, descriptions of a security patch are much more useful than the patch itself.
So, for software intended to break security, one could argue that the tool is more useful than descriptions of it to achieve that goal. For software intended to patch security, however, it is quite the opposite. The description of the tool is what can potentially be used to break security, thus this is the piece shielded from American eyes.
While this is logical to people like you an I who have functioning brains, it is not true according to the legal system for the same reason why source code was not treated as speech in the first place.
In short, they can't make DeCSS illegal by declaring that source code is not considered speech (and therefore not protected by the first amendment) and also make patches in the form of source code illegal by declaring that source code *is* considered speech.
Slashdot Mirror
It's a small point, but it says:
"brand names of those two wholly American lifestyle products"
For some reason, you are trying to substitute Uzi and Nissan for "wholly American lifestyle products" which yields the completely illogical conclusion that Uzi is a brand name of an Uzi, and Nissan is a brand name of a Nissan.
The products are cars and guns. The brand names are Nissan and Uzi.
This has nothing to do with a domain name. I'm not sure what Web site you found, but it has nothing to do with what we are talking about here.
Why don't you type http://www.nissan.com/ in a browser and find out?
... yet.
Mr. Nissan owns a computer business that makes use of his name, Nissan Computer Corporation. It is a perfectly legitimate use of his name and of the nissan.com domain.
This case seems slightly similar, even if it does have a different twist. One important point is that I only read about a C&D letter being sent; I saw nothing about a lawsuit being filed
Actually, they don't even claim that it is compatible but rather that it was designed to be compatible.
It's sort of like how I design my programs to work.
"What? It has a bug? That's impossible! I designed it to be bug-free!"
What in the world are you talking about?
HTML, and this should not be breaking news to you, is a markup language. It is meant for display. What other uses do you think people should have for it?
Also, HTML was not designed to be stateless, HTTP was. And, since it seems you have not heard, there is a mechanism in HTTP for maintaining state. It is called cookies. See RFC 2109, HTTP State Management Mechanism.
For that matter, look at SourceForge itself.
Well, your items 1 and 4 seem identical to me, and this is also something that depends on the design much more than the language.
My application designs always separate presentation from logic, but that's because I choose to. It might not be worth the extra complication for simpler solutions. After all, being able to embed PHP in HTML is part of why it has been so successful. However, this is just a feature of the language, not an enforced characteristic. For some reason, this seems to be a big misconception for many people.
You can have functions that generate the presentation in your format of choice (HTML, XML, etc.), static files that you include, or whatever. I've written code in most every Web scripting language (though very little with ASP), and I never felt more or less restricted in this regard with any of them. No language automatically designs your application for you.
Oh, and PHP has always had native database support for several databases. This is actually one of the complaints against it, as people like to write code that fits an abstraction layer instead, allowing them to switch databases. However, find some performance studies, and look at how well PHP performs with query-intensive applications.
Your other points are all valid, though I for one have never understood the praise for OO.
More secure?
See, this is where I cannot help but assume that you are inexperienced. If you think a language can make your applications more secure, then you have a fundamental misunderstanding about developing Web applications.
As for maintaining large applications, I can tell you that with proper software architecture employed, PHP is going to be plenty easy to maintain. When you look at the big picture, you need an application that new employees can contribute to after the shortest amount of training possible. Can you honestly tell me that Perl has an advantage here?
A better analogy is whether it is illegal for someone to call me if I have an unpublished number.
Whether someone finds me in a phone book, gets my number directly from me, gets my number from a friend, or guesses my number, the actual phone call is the same.
These anlogies about open doors are misleading, because it is intuitive to think that one should not simply walk into a stranger's house, even if the door is open.
However, if the open door were to a store in a mall, you would probably not think anything was wrong with just walking right in or even telling others about what you saw inside (or where the store is located). Just because the store wasn't listed in the mall directory doesn't make it illegal.
I have read the law, the depositions, the transscripts of the hearings, Kaplan's ruling, etc.
It seems to me that you should read the ruling, among other things. Try some of the documents listed here:
http://cryptome.org/cryptout.htm#DVD-DeCSS
While you claim to comprehend the letter of the law, you seem to have some misunderstandings about the spirit of the law as interpreted by Kaplan. It is the spirit of the law that creates precedents that are arguably as strong as the law itself. The danger of such precedents is the major factor in the EFF and 2600's decision to drop the appeal.
You seem to be taking an extremely strict interpretation of a rather vague clause in the DMCA. Perhaps if people like Kaplan did the same, it wouldn't have created such a predicament. Your statement, "the idea of whether something is "useful" for gaining access to a copyrighted work is irrelevant as far as the DMCA is concerned," illustrates this. This is not entirely irrelevant to a judge.
Given this testament of your opinion, do you honestly think the MPAA would have had such an easy time against the New York Times, who posted a similar story also containing a link to DeCSS? Of course not. The fact that 2600 is "The Hacker Quarterly" combined with the stigma surrounding the word hacker contributed largely to the success of the MPAA's case. Did you read anything about that in the DMCA? I didn't think so.
The following book is also a good resource for these issues:
http://www.digital-copyright.com/
Finally, pertaining to Sklyarov's case, did you hear about anyone arresting him at the airport? How about in his hotel the night before? Did he just sneak to the conference and not get "caught" until after his speech?
Sure, he was prosecuted for trafficking in a circumvention device. And, I suppose 2600 was prosecuted for illegally copying DVDs, right?
Don't let "the prosecution" confuse you. That's their job. They are going to take the strongest approach to win their case, and it's rarely going to be the truth. This isn't unique to DeCSS cases. While I am not suggesting we all subscribe to conspiracy theories, I don't think it's a good idea to be completely naive either. You seem to disagree.
Though your statements are mostly correct, you seem to be missing the point.
It is not the author of the information that needs to use the tool to gain unauthorized access to a copyrighted work. Do you think they had to prove that Dmitry Sklyarov accessed copyrighted information through the use of the tool he helped create? No. Did they prove that 2600 used DeCSS at all? No.
If it is possible that someone else could use the information you publish or the tools you create to gain unauthorized access to a copyrighted work, you are in potential danger of prosecution. Yes, prosecution is not guaranteed, and in this case it seems remote, but why should anyone have to take that risk? These people chose not to take that risk and used the opportunity to point out one absurdity of US law.
The statement that security information cannot be interpreted as a means of circumvention is more than a bit naive. 2600 posted a link to software that someone else had written that someone else could have possibly used to gain unauthorized access to content on a DVD they purchased. They got sued under the DMCA, and it was a strong enough case to win. Describing a security flaw in order to justify the necessity of an associated patch is also nearly identical to the talk Dmitry gave that landed him in prison.
Comparing DeCSS to this situation is tricky. In the DeCSS case, source code was ruled to not be speech. The source code to DeCSS was deemed to be useful for circumventing CSS in order to gain access to a copyrighted work. English descriptions of the code were not useful for circumventing CSS, though they could arguably be used to achieve the same result.
With detailed security information and the associated patch, we can draw a parallel to DeCSS source and the English descriptions, respectively. Though this seems counter-intuitive, this correlation represents the risk that is being avoided in this situation. The patch itself fixes a security vulnerability and is not useful for gaining access to a copyrighted work. So, even though it is code like DeCSS, the primary purpose of each contrast sharply. However, whereas descriptions of DeCSS were much less useful for gaining access to a copyrighted work, descriptions of a security patch are much more useful than the patch itself.
So, for software intended to break security, one could argue that the tool is more useful than descriptions of it to achieve that goal. For software intended to patch security, however, it is quite the opposite. The description of the tool is what can potentially be used to break security, thus this is the piece shielded from American eyes.
While this is logical to people like you an I who have functioning brains, it is not true according to the legal system for the same reason why source code was not treated as speech in the first place.
In short, they can't make DeCSS illegal by declaring that source code is not considered speech (and therefore not protected by the first amendment) and also make patches in the form of source code illegal by declaring that source code *is* considered speech.