Why is Google Health special? Does it matter more that outages could affect your Google Health profile? Are you under the belief that emergency departments will scramble to pull up your Google Health profile before starting emergency treatment, and that, if the page were to fail to come up, they'd all sit around, pull at their hair, and keep hitting Reload until you died?
Why does it matter that the outage affects multiple organizations? If you're studying the reliability of an e-mail service (presumably to decide whether or not you want to invest in a local e-mail infrastructure, or use someone else's), shouldn't you care more about the reliability of that service as provided to you? What's the difference between you having X hours of downtime a year, versus you and 1000 other organizations having X hours of downtime a year? How is the latter worse for you?
If you're doing business deals "worth billions", that critically hinge on the availability of e-mail, you can probably afford to buy and maintain a hyper-available e-mail infrastructure. For those of us that participate in the real world, this is not an issue. It's an inconvenience that can be worked around (with POP3 or IMAP, or by taking an early lunch).
It's a troll because if this were true then you would expect your water and sewage pipes to burst as well.
...not if water and sewage pipes have some flexible joints near the point where they connect to the house. Many commercial and large residential structures do indeed interrupt runs of rigid piping with flexible tubing/hoses, to deal with earthquakes and other movements of the structure. I thought it was a perfectly legitimate question.
Houses don't move that much because of piles supporting the house.
Not all foundations are deep foundations that require piles. Even deep foundations are not guaranteed to prevent all movement of the structure, especially during earthquakes.
I see a lot of comments from people emphatically recommending against identifying the owner in the machine name. Since you're talking about workstations, though, I have to disagree. A user's workstation should be wiped and re-imaged when it's reassigned, so the issue of a machine changing hands and keeping the original name should be moot. Upon a machine's first boot-up, it should be assigned a new name.
If you want to track the hardware, use a standard numeric asset tag.
If you love process and standards, a "username-pc" or "username-laptop" standard seems perfectly reasonable to me. Personally, I see no reason why you can't let users choose their own machine names (so long as it's unique and machines are placed in a separate subdomain from your services).
Obviously, the rule for servers should be different, since those outlive their owners, and RFC1178 is a great place to start there. But for workstations? They should come and go (even if the hardware is reused), so who cares?
For companies that are latency-sensitive (like Google), it doesn't make sense to serve a lot of traffic out of Iceland (except to Icelanders, perhaps).
Essentially it's a cross between collaborative documents (e.g. Google Docs), a container for JavaScript gadgets, e-mail, and IM (changes, even in gadget state, occur in real-time). Participants in a wave can be human, or robots hosted elsewhere (e.g. Google App Engine).
This would be trivial to automate. And really, if the fact that it's being downloaded from PACER is authentication enough, then all you really need to do is generate hashes of the documents, and serve them up (for free?) from PACER.
And so what do they intend to do with it? Your business with them is complete. Now the only reason they have to keep it is for the purposes of tracking you and privacy invasion.
Link any future business you do with them to past business?
Just because you can't think of a reason that isn't unlawful does not mean their reasons are unlawful. If you really think you want to take them to court with this as your justification, it's sort of up to you to prove that they have used/are using your SSN unlawfully.
Meaningless. It is not a crime to hold copyright on an illegal image. It's usually illegal to take, distribute, or possess these images. This would have nothing to do with copyright.
exclusive license to BMO, which would allow them to enforce the copyright, even though the actual transfer of ownership had not happened.
I don't believe a license is sufficient. A license is a grant of (copy) rights that you would not otherwise have. It does not allow you to enforce copyright law by restricting what others can do. Only the holder of the copyright can do that.
If you take a great photograph, and license that image to news networks A and B, A can't smack down B for using the same image. You have every right to license it to whomever you wish.
A determined predator will have no difficulties whatsoever signing up to use a social networking site, despite this ban. This only keeps the "honest" registered sex offenders from using these types of sites. These individuals almost certainly pose no threat to your children in the first place, so this ban will have no measurable effect whatsoever on the safety of your children. The only effect it will have is on the non-predatory registered sex offender, which is tragic. It truly disgusts me that people are for useless, evil legislation like this. But God forbid a legislator actually speak out against it, because that must mean they're siding with the evil child molesters, right?
But it becomes a bad thing when you do it for non-existent domains.
Why? If I mistype a domain name, and get a search results page, I know instantly what happened (I mistyped the domain name), and, odds are, the correct page that I'm looking for is in the search results (usually at the top), one click away, instead of a retype away. This is a net positive for me. Fortunately we can both have it our own way, since you can turn this feature off, right?
Corporations can't be charged with murder (or take drugs), which is why that system is broken
What exactly would be the point of charging the corporation with murder? What is the benefit? Corporations aren't charged with crimes because corporations have can't have criminal intent. In any situation you feel you could charge a corporation with a crime, you can charge the individuals that committed the crime instead, which is really what you want.
Corporations can still be held criminally liable, so you can get all sorts of damages out of them in a civil suit, but how can you send a corporation to prison?
I think I understand the point you're trying to make: A digital signature that is required to execute the application qualifies the digital signature as a part of the executable, and anyone distributing such an executable is, according to the GPL, required to distribute the "source code" of the digital signature, which you've interpreted to include the private key.
I don't think you've refuted my statement that courts *do* define "program" and "executable" to encompass platform-specific checks when executing a program
It's not up to me to refute it, it's up to you to prove it, since you're the one making the argument.:) Your argument revolves chiefly around the definition of "functional", as discussed in Sega. v. Accolade, which I believe to be inappropriate. You've stated that this is just one example of how courts tend to think this way, but that's still too hand-wavey for me.
The GPL uses "executable" without defining it, as you've noted. Since we're talking about a copyright license, let's look at this from a copyright perspective. The only reason we have to deal with the GPL in the first place is because our executables are considered derivative works. It doesn't matter what our executables do, or that they even run at all. It just matters that they're a transformation of copyrighted source code. Copyright law restricts how we can copy and distribute those executables, which means the GPL can set conditions on those reserved rights.
I believe the one question I still have is this: Does wrapping a copyrighted work in something purely functional (i.e. not copyrightable in isolation) result in a (copyrightable?) derivative work?
If yes, then it doesn't matter if your informational-only authenticity signature isn't necessary to run the executable. It's still part of the work, and would still be subject to the same requirements that the GPL imposes on all other aspects of the GPL. If not, then (it seems to me) that even a functionally necessary digital signature would not apply, at least for GPLv2.
That's the "common knowledge", but I think that only because no one has noticed or pursued this particular legal angle.
Of course it was noticed, because Tivo was doing it, and this situation was what led to the creation of GPLv3.
In any license or contract, if an ambiguity exists, it's nearly always interpreted conservatively, i.e., against the party the purported requirement would serve to benefit. So the argument would need to be made that (a) the license was sufficiently explicit, and (b) that it applies to your specific situation. If the lawyers that drafted the GPL weren't at least a little unsure it would hold up, they wouldn't have felt the need to add in that explicit anti-tivoization verbiage. Further, the stated goals of the GPLv3 include not limiting the use of digital signatures for other purposes (e.g. authenticity). Your argument would seem to apply to those as well.
Both [32-bit Windows CRCs and an iPhone digital signature] are mathematical hashes describing and validating the integrity of the rest of the executable. There is no possible dispute that it is not part of the executable.
If you take an arbitrary iPhone executable, and look at it, there is little doubt in my mind that, should a court feel the need to determine whether the signature present on that executable is "functional" or not, they would absolutely agree that it's functional, as a simple matter of definition. But while a CRC cannot be substituted with another, a digital signature can, and that makes a huge difference in how this definition can be applied in a particular case.
But as I said before, this definition is meaningless in the context of the GPL, because the GPL does not use it. The language of the GPL is supreme here. If you want to debate whether something is covered as part of the GPL, that is what you should be looking at.
The GPLv2 did not explicitly anticipate this situation, so the question here is whether these signatures are part of the "program" or "executable", and then the results follow from there. As a programmer I believe the correct answer is yes, and all of the court cases I have read seem to indicate the courts are likely to agree.
The FSF's own lawyers disagree with you, and your interpretation is in opposition to the stated goals of the GPL. Either you are brilliant, and have outsmarted the FSF's lawyers (and Tivo's for that matter), or there are problems with your assumptions or reasoning that are leading you to a faulty conclusion.
He's not distributing an executable for a simulator target platform. He's compiling and distributing an iPhone executable.
Fair enough, but I think the GPLv2 vs. GPLv3 distinction remains crucial. You're making arguments that could apply to GPLv2, but it's clear that the GPLv2 does not prohibit "tivoization".
Sega Enterprises Ltd. v. Accolade Inc. consistently referred to "SEGA" text trademark as being functional code
I'm familiar with Sega v. Accolade. It's a trademark/misrepresentation case, not a copyright case. The court ultimately held that "SEGA" was functional, because, as you say, it was effectively an instruction. I don't think it's appropriate to use terms and arguments in a trademark case (meant to exclude something like "SEGA" from trademark enforcement) to a copyright case (intending to include a specific digital certificate as being covered by a license).
That being said, it's the need for a digital certificate that would be the functional part here, not the certificate itself. The iPhone OS isn't checking to be sure the application has a specific digital certificate, only that the certificate satisfy some requirement (that it be signed by Apple).
But regardless of which definition you choose, it's only a definition. It has no legal consequence except that which the GPL gives it, and the GPL doesn't use this term at all. It all boils down to the language of the license. The GPLv2 is not sufficiently explicit here, which means you are unlikely to get a specific digital certificate included in its definitions so as to forbid distribution without it. The GPLv3 has no need to even recognize this definition of "functional code", since its restrictions are more inclusive and more explicit. (The very fact that they had to include "tivoization" language in GPLv3, and explicitly discuss the inability to enforce this restriction in GPLv2, should be a clue that there might be holes in this conclusion.)
No, he's not. The GPL does not extend to cover other components of the operating system, like the compiler, or system libraries. The SDK does not need to be GPLed. However, if the SDK automatically supplies code that then might find its way into GPLed software, the SDK's license needs to be sufficiently free to accommodate that.
That unique developer compilation key would in fact be part of the source used to compile the executable.
It is not part of the source, and it is not required to execute the software (it runs in a simulator fine). However, you are correct that the GPLv3 precludes GPLed iPhone apps, not because of some clever (and wrong, IMO) application of the term "functional code", but because the GPLv3 says so, quite simply:
"Installation Information" for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.
This restriction is explicit, and is not present in GPLv2. Releasing the key would be a logical way to comply with the GPL, but I suspect it's also a violation of your agreement with Apple.
I think it's absurd to talk about removing the right, but at the very least, eliminate the welfare programs' cash incentives for having children. If a household is living on state assistance, then they should be looking for work, not thinking about having children and raising a family. If they want to try stretching the assistance they receive to support a child, let them try, but if their child's basic needs aren't being met, the answer isn't to give them money, it's to take the child away and put him or her into foster care. A good welfare system should always have the goal of getting participants off welfare. "Cash for kids" is just more perpetuation nonsense.
not allowing people to have children on an equal footing with murder
Therefore, contraceptive use is murder. A cop tapping on a car window at Lover's Point has just committed murder. Anyone that decides "no means no" is a murderer. Don't be absurd.
I would agree with the argument that the option to have children should be a fundamental right. But if you can't support them, and their basic needs aren't being met, you don't get to keep them. I'd rather see things like free contraceptives and family planning services.
...because it should never have been on that machine in the first place!
In other words, it should be banned. Right.
Software behaving badly != Protocol is evil and should be regulated or banned.
I agree. Legislating against the protocol (standard, whatever) is stupid and ill-informed. But if P2P software in particular generally has the same flaw/trait that makes it easy to inadvertently share everything on your machine, then a P2P software ban doesn't sound too outrageous to me. Otherwise, it seems better to ban the specific software exhibiting this trait, or ban the entire class of "file sharing" software (including HTTP and FTP servers).
Think of it like a knob. At 0, nothing gets banned, and you get an occasional release of something sensitive. At 1, you might ban specific pieces of software (Limewire). You'll see fewer accidental releases of something sensitive, right? At 2, you might ban all P2P software. You could see even fewer accidental releases. And at 3, you could ban all file transfer/sharing software, and see the fewest accidental releases. Where that knob should be set depends on an investigation of how inadvertent releases occur, the costs of enforcing that ban, etc. I don't think either of us are qualified to make that call.
There's a subtle difference here, though. When you install an HTTP or an FTP server, it doesn't "helpfully" offer to scan your entire computer for things to share, and publish that information in a search engine. Yes, misconfigured software can expose sensitive data, but in this specific case, the P2P software in question makes it ridiculously easy to accidentally share things you probably do not want shared.
Slashdot Mirror
Why is Google Health special? Does it matter more that outages could affect your Google Health profile? Are you under the belief that emergency departments will scramble to pull up your Google Health profile before starting emergency treatment, and that, if the page were to fail to come up, they'd all sit around, pull at their hair, and keep hitting Reload until you died?
Why does it matter that the outage affects multiple organizations? If you're studying the reliability of an e-mail service (presumably to decide whether or not you want to invest in a local e-mail infrastructure, or use someone else's), shouldn't you care more about the reliability of that service as provided to you? What's the difference between you having X hours of downtime a year, versus you and 1000 other organizations having X hours of downtime a year? How is the latter worse for you?
If you're doing business deals "worth billions", that critically hinge on the availability of e-mail, you can probably afford to buy and maintain a hyper-available e-mail infrastructure. For those of us that participate in the real world, this is not an issue. It's an inconvenience that can be worked around (with POP3 or IMAP, or by taking an early lunch).
Not all foundations are deep foundations that require piles. Even deep foundations are not guaranteed to prevent all movement of the structure, especially during earthquakes.
I see a lot of comments from people emphatically recommending against identifying the owner in the machine name. Since you're talking about workstations, though, I have to disagree. A user's workstation should be wiped and re-imaged when it's reassigned, so the issue of a machine changing hands and keeping the original name should be moot. Upon a machine's first boot-up, it should be assigned a new name.
If you want to track the hardware, use a standard numeric asset tag.
If you love process and standards, a "username-pc" or "username-laptop" standard seems perfectly reasonable to me. Personally, I see no reason why you can't let users choose their own machine names (so long as it's unique and machines are placed in a separate subdomain from your services).
Obviously, the rule for servers should be different, since those outlive their owners, and RFC1178 is a great place to start there. But for workstations? They should come and go (even if the hardware is reused), so who cares?
For companies that are latency-sensitive (like Google), it doesn't make sense to serve a lot of traffic out of Iceland (except to Icelanders, perhaps).
Here's an abridged video: http://www.youtube.com/watch?v=Itc4253kjhw
Essentially it's a cross between collaborative documents (e.g. Google Docs), a container for JavaScript gadgets, e-mail, and IM (changes, even in gadget state, occur in real-time). Participants in a wave can be human, or robots hosted elsewhere (e.g. Google App Engine).
This would be trivial to automate. And really, if the fact that it's being downloaded from PACER is authentication enough, then all you really need to do is generate hashes of the documents, and serve them up (for free?) from PACER.
Link any future business you do with them to past business?
Just because you can't think of a reason that isn't unlawful does not mean their reasons are unlawful. If you really think you want to take them to court with this as your justification, it's sort of up to you to prove that they have used/are using your SSN unlawfully.
Meaningless. It is not a crime to hold copyright on an illegal image. It's usually illegal to take, distribute, or possess these images. This would have nothing to do with copyright.
I don't believe a license is sufficient. A license is a grant of (copy) rights that you would not otherwise have. It does not allow you to enforce copyright law by restricting what others can do. Only the holder of the copyright can do that.
If you take a great photograph, and license that image to news networks A and B, A can't smack down B for using the same image. You have every right to license it to whomever you wish.
A determined predator will have no difficulties whatsoever signing up to use a social networking site, despite this ban. This only keeps the "honest" registered sex offenders from using these types of sites. These individuals almost certainly pose no threat to your children in the first place, so this ban will have no measurable effect whatsoever on the safety of your children. The only effect it will have is on the non-predatory registered sex offender, which is tragic. It truly disgusts me that people are for useless, evil legislation like this. But God forbid a legislator actually speak out against it, because that must mean they're siding with the evil child molesters, right?
Why? If I mistype a domain name, and get a search results page, I know instantly what happened (I mistyped the domain name), and, odds are, the correct page that I'm looking for is in the search results (usually at the top), one click away, instead of a retype away. This is a net positive for me. Fortunately we can both have it our own way, since you can turn this feature off, right?
Natural Selection is, by definition, an evolutionary mechanism. I believe you are confusing evolution (fact) with evolution (theory). http://en.wikipedia.org/wiki/Evolution_as_theory_and_fact
What exactly would be the point of charging the corporation with murder? What is the benefit? Corporations aren't charged with crimes because corporations have can't have criminal intent. In any situation you feel you could charge a corporation with a crime, you can charge the individuals that committed the crime instead, which is really what you want.
Corporations can still be held criminally liable, so you can get all sorts of damages out of them in a civil suit, but how can you send a corporation to prison?
I think I understand the point you're trying to make: A digital signature that is required to execute the application qualifies the digital signature as a part of the executable, and anyone distributing such an executable is, according to the GPL, required to distribute the "source code" of the digital signature, which you've interpreted to include the private key.
It's not up to me to refute it, it's up to you to prove it, since you're the one making the argument. :) Your argument revolves chiefly around the definition of "functional", as discussed in Sega. v. Accolade, which I believe to be inappropriate. You've stated that this is just one example of how courts tend to think this way, but that's still too hand-wavey for me.
The GPL uses "executable" without defining it, as you've noted. Since we're talking about a copyright license, let's look at this from a copyright perspective. The only reason we have to deal with the GPL in the first place is because our executables are considered derivative works. It doesn't matter what our executables do, or that they even run at all. It just matters that they're a transformation of copyrighted source code. Copyright law restricts how we can copy and distribute those executables, which means the GPL can set conditions on those reserved rights.
I believe the one question I still have is this: Does wrapping a copyrighted work in something purely functional (i.e. not copyrightable in isolation) result in a (copyrightable?) derivative work?
If yes, then it doesn't matter if your informational-only authenticity signature isn't necessary to run the executable. It's still part of the work, and would still be subject to the same requirements that the GPL imposes on all other aspects of the GPL. If not, then (it seems to me) that even a functionally necessary digital signature would not apply, at least for GPLv2.
Isn't this an alternate root, though? With all of the problems that alternate roots have?
Of course it was noticed, because Tivo was doing it, and this situation was what led to the creation of GPLv3.
In any license or contract, if an ambiguity exists, it's nearly always interpreted conservatively, i.e., against the party the purported requirement would serve to benefit. So the argument would need to be made that (a) the license was sufficiently explicit, and (b) that it applies to your specific situation. If the lawyers that drafted the GPL weren't at least a little unsure it would hold up, they wouldn't have felt the need to add in that explicit anti-tivoization verbiage. Further, the stated goals of the GPLv3 include not limiting the use of digital signatures for other purposes (e.g. authenticity). Your argument would seem to apply to those as well.
If you take an arbitrary iPhone executable, and look at it, there is little doubt in my mind that, should a court feel the need to determine whether the signature present on that executable is "functional" or not, they would absolutely agree that it's functional, as a simple matter of definition. But while a CRC cannot be substituted with another, a digital signature can, and that makes a huge difference in how this definition can be applied in a particular case.
But as I said before, this definition is meaningless in the context of the GPL, because the GPL does not use it. The language of the GPL is supreme here. If you want to debate whether something is covered as part of the GPL, that is what you should be looking at.
The FSF's own lawyers disagree with you, and your interpretation is in opposition to the stated goals of the GPL. Either you are brilliant, and have outsmarted the FSF's lawyers (and Tivo's for that matter), or there are problems with your assumptions or reasoning that are leading you to a faulty conclusion.
Fair enough, but I think the GPLv2 vs. GPLv3 distinction remains crucial. You're making arguments that could apply to GPLv2, but it's clear that the GPLv2 does not prohibit "tivoization".
I'm familiar with Sega v. Accolade. It's a trademark/misrepresentation case, not a copyright case. The court ultimately held that "SEGA" was functional, because, as you say, it was effectively an instruction. I don't think it's appropriate to use terms and arguments in a trademark case (meant to exclude something like "SEGA" from trademark enforcement) to a copyright case (intending to include a specific digital certificate as being covered by a license).
That being said, it's the need for a digital certificate that would be the functional part here, not the certificate itself. The iPhone OS isn't checking to be sure the application has a specific digital certificate, only that the certificate satisfy some requirement (that it be signed by Apple).
But regardless of which definition you choose, it's only a definition. It has no legal consequence except that which the GPL gives it, and the GPL doesn't use this term at all. It all boils down to the language of the license. The GPLv2 is not sufficiently explicit here, which means you are unlikely to get a specific digital certificate included in its definitions so as to forbid distribution without it. The GPLv3 has no need to even recognize this definition of "functional code", since its restrictions are more inclusive and more explicit. (The very fact that they had to include "tivoization" language in GPLv3, and explicitly discuss the inability to enforce this restriction in GPLv2, should be a clue that there might be holes in this conclusion.)
No, he's not. The GPL does not extend to cover other components of the operating system, like the compiler, or system libraries. The SDK does not need to be GPLed. However, if the SDK automatically supplies code that then might find its way into GPLed software, the SDK's license needs to be sufficiently free to accommodate that.
It is not part of the source, and it is not required to execute the software (it runs in a simulator fine). However, you are correct that the GPLv3 precludes GPLed iPhone apps, not because of some clever (and wrong, IMO) application of the term "functional code", but because the GPLv3 says so, quite simply:
This restriction is explicit, and is not present in GPLv2. Releasing the key would be a logical way to comply with the GPL, but I suspect it's also a violation of your agreement with Apple.
I think it's absurd to talk about removing the right, but at the very least, eliminate the welfare programs' cash incentives for having children. If a household is living on state assistance, then they should be looking for work, not thinking about having children and raising a family. If they want to try stretching the assistance they receive to support a child, let them try, but if their child's basic needs aren't being met, the answer isn't to give them money, it's to take the child away and put him or her into foster care. A good welfare system should always have the goal of getting participants off welfare. "Cash for kids" is just more perpetuation nonsense.
Therefore, contraceptive use is murder. A cop tapping on a car window at Lover's Point has just committed murder. Anyone that decides "no means no" is a murderer. Don't be absurd.
I would agree with the argument that the option to have children should be a fundamental right. But if you can't support them, and their basic needs aren't being met, you don't get to keep them. I'd rather see things like free contraceptives and family planning services.
In other words, it should be banned. Right.
I agree. Legislating against the protocol (standard, whatever) is stupid and ill-informed. But if P2P software in particular generally has the same flaw/trait that makes it easy to inadvertently share everything on your machine, then a P2P software ban doesn't sound too outrageous to me. Otherwise, it seems better to ban the specific software exhibiting this trait, or ban the entire class of "file sharing" software (including HTTP and FTP servers).
Think of it like a knob. At 0, nothing gets banned, and you get an occasional release of something sensitive. At 1, you might ban specific pieces of software (Limewire). You'll see fewer accidental releases of something sensitive, right? At 2, you might ban all P2P software. You could see even fewer accidental releases. And at 3, you could ban all file transfer/sharing software, and see the fewest accidental releases. Where that knob should be set depends on an investigation of how inadvertent releases occur, the costs of enforcing that ban, etc. I don't think either of us are qualified to make that call.
Or, you could just ignore it, which is what browsers and search engines do anyway with unrecognized markup.
There's a subtle difference here, though. When you install an HTTP or an FTP server, it doesn't "helpfully" offer to scan your entire computer for things to share, and publish that information in a search engine. Yes, misconfigured software can expose sensitive data, but in this specific case, the P2P software in question makes it ridiculously easy to accidentally share things you probably do not want shared.