Not just talking about remote vid game handhelds. So yeah, basically just CD players and mp3 CD players. The buffers don't do anything but delay the inevitable when you need them on a bumpy road. Although, that situation would probably actually be a bit better on a handheld video game system since it will probably not be reading from the CD the whole time (except to prebuffer video/audio/meshes/sprites/textures/maps/libraries,etc.).
I personally don't find this attractive at all. Using optical storage in any kind of mobile device is too irritating for me to put up with again. And the real reason Sony does so well in the video game market is because it hypes early and it hypes often. Nintendo should really try to learn a lesson from this.
Ignorance historically doesn't hold up in court. Many manufacturers are ignorant of problems embedded in their products, and are sued because of failures, etc. This should be treated no differently.
I am sure at one point or another SCO had to have looked at some of the Linux kernel code. Do they just not care about their investments? Also, these "illegal acts" were done in the open, in the eye of the public. They would have to be blind and stupid to have not audited the linux kernel source, when they owned produce their own version of unix. If there is SCO code in the kernel I think its because SCO was playing a game of seed the code into linux, and wait for the market share to sue. But I seriously doubt they have anything there to begin with. Anyways, how can they possibly prove that they created the code. Digital forgeries are quite easy. And if the code was interjected into Linux by IBM, then IBM is liable, not every single user of Linux (of course, dumbass America likes to believe otherwise in these kinds of issues, see Unisys's old LZW patent for a case in point).
So everyone distributing/obtaining linux is guilty of unknowingly distributing/obtaining what SCO, potentially, unknowingly contributed. If the judgement comes out in SCO's favor, then how can the current users be any more guilty than SCO itself. Both parties were potentially misinformed, and the users themselves were misinformed by SCO saying that the code included with their kernel was GPLd. I see no end-user liability in this at all. It took SCO way too long to retract this declaration that is excplicitly stated at the top of every kernel source file, and this action/retraction just so happens to coincide with when they are in financial dire straights. Hmmmmmm.....
I agree with what you say in 1, but by distributing Linux SCO would have had to at least acknowledge that they were distributing GPLd code. And therefore they affirmed to every single user of their Linux distro that all the kernel code was distributed with the GPL license, and as such they presented themselves as legally obligated GPLd code donors (again, assuming their code is in it to begin with). Linux users cannot be held accountable because SCO has bad code auditing practices in place. Now as far as the actual code injection performed by IBM, I think there could possibly be a breach of contract case against them (I haven't seen the contract so I can't say that for sure).
I would really hate any company to read this, and think that SCO has any legal ground vs. the linux community whatsoever, so I will repost my message, from yesterday, here to clarify SCO's idiocy:
Here, is where I think SCOs major flaw in their argument is, the GPL circa Jan 28, 1999 explicitly states in its preamble: To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.
Refer to way back machine: http://web.archive.org/web/19990128195748/www.gnu. org/copyleft/gpl.html
And seeing as how SCO has been distributing Linux which had their code in the kernel. They have thusly, knowingly or not, distributed their rights, to the GPLd code in question, to the public. Because, of the statement above. Or if you want to hear it straight from GNU's statement: ... Moreover, there are straightforward legal reasons why SCO's assertions concerning claims against the kernel or other free software are likely to fail. As to its trade secret claims, which are the only claims actually made in the lawsuit against IBM, there remains the simple fact that SCO has for years distributed copies of the kernel, Linux, as part of GNU/Linux free software systems. Those systems were distributed by SCO in full compliance with GPL, and therefore included complete source code. So SCO itself has continuously published, as part of its regular business, the material which it claims includes its trade secrets. There is simply no legal basis on which SCO can claim trade secret liability in others for material it widely and commercially published itself under a license that specifically permitted unrestricted copying and distribution. ...
Here, is where I think SCOs major flaw in their argument is, the GPL circa Jan 28, 1999 explicitly states in its preamble: To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.
Refer to way back machine: http://web.archive.org/web/19990128195748/www.gnu. org/copyleft/gpl.html
And seeing as how SCO has been distributing Linux which had their code in the kernel. They have thusly, knowingly or not, distributed their rights, to the GPLd code in question, to the public. Because, of the statement above. Or if you want to hear it straight from GNU's statement: ... Moreover, there are straightforward legal reasons why SCO's assertions concerning claims against the kernel or other free software are likely to fail. As to its trade secret claims, which are the only claims actually made in the lawsuit against IBM, there remains the simple fact that SCO has for years distributed copies of the kernel, Linux, as part of GNU/Linux free software systems. Those systems were distributed by SCO in full compliance with GPL, and therefore included complete source code. So SCO itself has continuously published, as part of its regular business, the material which it claims includes its trade secrets. There is simply no legal basis on which SCO can claim trade secret liability in others for material it widely and commercially published itself under a license that specifically permitted unrestricted copying and distribution. ...
You cannot import classes from GPL'd stuff. That will automatically make your class GPL'd (and subsequently importing from those new ones will do the same). No amount of layering your imports will stop GPL propogation. Her is the process for making use of GPL'd libraries in your non-GPL'd software: 1. Recognize the need for a GPL'd library 2. Write generic interfaces for the type of external functionality you need in your classes, and write code for your new classes to interact with those generic interfaces. 3. Create wrapper classes for the GPL'd code implementing those generic interfaces, and distribute as a seperate GPL'd plugin. Done. Whats so hard about that people? I am currently writing some remote authentication code using a GPL'd SASL library. No problems, its a seperate GPL'd plugin library which implements the interfaces my classes need. At no point in my non-GPL'd code do I import it, so at no point do I have to relicense. Oooh, hard. BTW, the rest of my code is Apache licensed, I'm not just trying to rip off the open source world:-P.
Heres how you avoid the viral GPL situation. The process:
1. Recognize the need for a GPL'd library
2. Write generic interfaces for the type of external functionality you need in your classes, and write code for your new classes to interact with those generic interfaces.
3. Create wrapper classes for the GPL'd code implementing those generic interfaces, and distribute as a seperate GPL'd plugin.
Done. Whats so hard about that people? I am currently writing some remote authentication code using a GPL'd SASL library. No problems, its a seperate GPL'd plugin library which implements the interfaces my classes need. At no point in my non-GPL'd code do I import it, so at no point do I have to relicense. Oooh, hard. BTW, the rest of my code is Apache licensed, I'm not just trying to rip off the open source world:-P.
The guy who posted this story does not remember his physics very well. This thing uses extremely high voltages not current. The current is actually quite small.
The problem with protecting a generic connection with SSL is that the password is actually passed over the connection. This means if the SSL is ever comprimised it would be fairly simple to crack the password. Use of Strong Authentication mechanisms such as SRP eliminates this problem.
Now your dealing with the nature of all property. What constitutes possesion of something? In our case the government, why? Because its a big bully and we have no chance arguing with it.
So, you're the one thats been hacking into my applications. How did you get past the AES wrapped SRP authorization on top of TLS sockets. Oh wait, its because I logged in over telnet that one time isn't it? Or maybe its because of that SSH CRC32 patch I forgot to apply back in 2001. Damn.
The assumption of unowned Intellectual Property is called (brace yourself): an idea. When it is associated with a person it is my idea or Jim's idea. If its useful then its a useful idea. OK, go ahead and start work on getting this magical wonder word introduced into the dictionary. I'll talk all the lawyers into changing all the IP law.
Slashdot Mirror
Not just talking about remote vid game handhelds. So yeah, basically just CD players and mp3 CD players. The buffers don't do anything but delay the inevitable when you need them on a bumpy road. Although, that situation would probably actually be a bit better on a handheld video game system since it will probably not be reading from the CD the whole time (except to prebuffer video/audio/meshes/sprites/textures/maps/libraries ,etc.).
I personally don't find this attractive at all. Using optical storage in any kind of mobile device is too irritating for me to put up with again. And the real reason Sony does so well in the video game market is because it hypes early and it hypes often. Nintendo should really try to learn a lesson from this.
No, its quite illegal actually, as shit would most definetely be classified as hazardous waste. You would need a permit to ship it.
I believe 3d realms actually coined "when its done".
Ignorance historically doesn't hold up in court. Many manufacturers are ignorant of problems embedded in their products, and are sued because of failures, etc. This should be treated no differently.
I am sure at one point or another SCO had to have looked at some of the Linux kernel code. Do they just not care about their investments? Also, these "illegal acts" were done in the open, in the eye of the public. They would have to be blind and stupid to have not audited the linux kernel source, when they owned produce their own version of unix. If there is SCO code in the kernel I think its because SCO was playing a game of seed the code into linux, and wait for the market share to sue. But I seriously doubt they have anything there to begin with. Anyways, how can they possibly prove that they created the code. Digital forgeries are quite easy. And if the code was interjected into Linux by IBM, then IBM is liable, not every single user of Linux (of course, dumbass America likes to believe otherwise in these kinds of issues, see Unisys's old LZW patent for a case in point).
So everyone distributing/obtaining linux is guilty of unknowingly distributing/obtaining what SCO, potentially, unknowingly contributed. If the judgement comes out in SCO's favor, then how can the current users be any more guilty than SCO itself. Both parties were potentially misinformed, and the users themselves were misinformed by SCO saying that the code included with their kernel was GPLd. I see no end-user liability in this at all. It took SCO way too long to retract this declaration that is excplicitly stated at the top of every kernel source file, and this action/retraction just so happens to coincide with when they are in financial dire straights. Hmmmmmm.....
I agree with what you say in 1, but by distributing Linux SCO would have had to at least acknowledge that they were distributing GPLd code. And therefore they affirmed to every single user of their Linux distro that all the kernel code was distributed with the GPL license, and as such they presented themselves as legally obligated GPLd code donors (again, assuming their code is in it to begin with). Linux users cannot be held accountable because SCO has bad code auditing practices in place. Now as far as the actual code injection performed by IBM, I think there could possibly be a breach of contract case against them (I haven't seen the contract so I can't say that for sure).
I would really hate any company to read this, and think that SCO has any legal ground vs. the linux community whatsoever, so I will repost my message, from yesterday, here to clarify SCO's idiocy:
. org/copyleft/gpl.html
...
Here, is where I think SCOs major flaw in their argument is, the GPL circa Jan 28, 1999 explicitly states in its preamble:
To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.
Refer to way back machine: http://web.archive.org/web/19990128195748/www.gnu
And seeing as how SCO has been distributing Linux which had their code in the kernel. They have thusly, knowingly or not, distributed their rights, to the GPLd code in question, to the public. Because, of the statement above. Or if you want to hear it straight from GNU's statement:
Moreover, there are straightforward legal reasons why SCO's assertions concerning claims against the kernel or other free software are likely to fail. As to its trade secret claims, which are the only claims actually made in the lawsuit against IBM, there remains the simple fact that SCO has for years distributed copies of the kernel, Linux, as part of GNU/Linux free software systems. Those systems were distributed by SCO in full compliance with GPL, and therefore included complete source code. So SCO itself has continuously published, as part of its regular business, the material which it claims includes its trade secrets. There is simply no legal basis on which SCO can claim trade secret liability in others for material it widely and commercially published itself under a license that specifically permitted unrestricted copying and distribution.
...
Here, is where I think SCOs major flaw in their argument is, the GPL circa Jan 28, 1999 explicitly states in its preamble:
. org/copyleft/gpl.html
...
To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.
Refer to way back machine: http://web.archive.org/web/19990128195748/www.gnu
And seeing as how SCO has been distributing Linux which had their code in the kernel. They have thusly, knowingly or not, distributed their rights, to the GPLd code in question, to the public. Because, of the statement above. Or if you want to hear it straight from GNU's statement:
Moreover, there are straightforward legal reasons why SCO's assertions concerning claims against the kernel or other free software are likely to fail. As to its trade secret claims, which are the only claims actually made in the lawsuit against IBM, there remains the simple fact that SCO has for years distributed copies of the kernel, Linux, as part of GNU/Linux free software systems. Those systems were distributed by SCO in full compliance with GPL, and therefore included complete source code. So SCO itself has continuously published, as part of its regular business, the material which it claims includes its trade secrets. There is simply no legal basis on which SCO can claim trade secret liability in others for material it widely and commercially published itself under a license that specifically permitted unrestricted copying and distribution.
...
The only reason they are consolidating those servers is because they can't afford the Windows 2003 Advanced Server licenses to upgrade them. :-P
You cannot import classes from GPL'd stuff. That will automatically make your class GPL'd (and subsequently importing from those new ones will do the same). No amount of layering your imports will stop GPL propogation. Her is the process for making use of GPL'd libraries in your non-GPL'd software: :-P.
1. Recognize the need for a GPL'd library
2. Write generic interfaces for the type of external functionality you need in your classes, and write code for your new classes to interact with those generic interfaces.
3. Create wrapper classes for the GPL'd code implementing those generic interfaces, and distribute as a seperate GPL'd plugin.
Done. Whats so hard about that people? I am currently writing some remote authentication code using a GPL'd SASL library. No problems, its a seperate GPL'd plugin library which implements the interfaces my classes need. At no point in my non-GPL'd code do I import it, so at no point do I have to relicense. Oooh, hard. BTW, the rest of my code is Apache licensed, I'm not just trying to rip off the open source world
Heres how you avoid the viral GPL situation. The process: :-P.
1. Recognize the need for a GPL'd library
2. Write generic interfaces for the type of external functionality you need in your classes, and write code for your new classes to interact with those generic interfaces.
3. Create wrapper classes for the GPL'd code implementing those generic interfaces, and distribute as a seperate GPL'd plugin.
Done. Whats so hard about that people? I am currently writing some remote authentication code using a GPL'd SASL library. No problems, its a seperate GPL'd plugin library which implements the interfaces my classes need. At no point in my non-GPL'd code do I import it, so at no point do I have to relicense. Oooh, hard. BTW, the rest of my code is Apache licensed, I'm not just trying to rip off the open source world
Yeah I called that one fairy cartman
Jeez, just use Ant and be done with it, already.
The guy who posted this story does not remember his physics very well. This thing uses extremely high voltages not current. The current is actually quite small.
No AD is compatible with MIT Kerberos version 5 clients. Conversely, windows cannot authenticate to an MIT KDC.
Of course there is an SRP on SASL authentication mechanism so SMTP can use it with fairly few extensions.
The problem with protecting a generic connection with SSL is that the password is actually passed over the connection. This means if the SSL is ever comprimised it would be fairly simple to crack the password. Use of Strong Authentication mechanisms such as SRP eliminates this problem.
Now your dealing with the nature of all property. What constitutes possesion of something? In our case the government, why? Because its a big bully and we have no chance arguing with it.
Because remember a cheaper production process = increased profits. They would be stupid to ignore it.
No they won't do that. They are smart. They will buy up the company and throttle production to control the price like they've always done.
So, you're the one thats been hacking into my applications. How did you get past the AES wrapped SRP authorization on top of TLS sockets. Oh wait, its because I logged in over telnet that one time isn't it? Or maybe its because of that SSH CRC32 patch I forgot to apply back in 2001. Damn.
The assumption of unowned Intellectual Property is called (brace yourself): an idea. When it is associated with a person it is my idea or Jim's idea. If its useful then its a useful idea. OK, go ahead and start work on getting this magical wonder word introduced into the dictionary. I'll talk all the lawyers into changing all the IP law.
I usually like to put a backdoor in my software with the password being my dead son's name. Good times.