What I don't understand, as an author who holds copyright in at least one book that is out of print, is: how can a lawsuit to which I am not a party give *my* rights under copyright law to someone else?
That seems to be fundamentally wrong.
Tangentially, I find it somewhere between interesting and amusing (or perhaps scary) that Google appears to have made no attempt to contact me, despite the fact that I'm hardly the most difficult person to find.
Even more tangentially, there doesn't seem to be any place to go to see if google has actually digitized a book in which I have rights. Someone please correct me if there's a way to do that. (But in any case, why should I be the one who has to go and see if they've infringed rights? They are the ones who are supposed to seek permission from me.)
Frankly, this whole "settlement" seems utterly unconscionable.
My main concern would be privacy. You start putting confidential client files on the internet, and if anything goes wrong you are looking at a malpractice suit for sure.
I tried to explain that to a local lawyer who wanted to use gmail (unencrypted, of course) for his practice's e-mail. I could never get him to understand that there was anything even remotely wrong with doing what he wanted to do. So now he's doing it.
Just as scary, none of his clients seem to think that it's a problem.
This is one of those times that I just want to bang my head on a wall and scream (to myself, since no one else seems to listen), "Why does no one else get it?"
And by talking to other lawyers here, their backup strategy generally seems to consist of... hope that they never have a fire (or, in some cases, hope that they never lose a hard drive).
I'm wondering if the problem is not so much poor software quality as it is a bottleneck in the feed itself. Perhaps the servers can't take the load, or perhaps they simply don't have enough well-placed bandwidth.
I don't see how that can be the problem. I just watched a program on my Roku box, and it was the same quality (4 stars on their bandwidth indicator) as usual. I watch several movies or programs a week in this manner, and it's always the same quality.
> So... the bug report will be marked "Cannot reproduce". Then a couple other suckers that were so annoyed by it that they took the time to create an account in the bug system will post "Still reproducible on 4.4", but it'll never get fixed. And even if it does get fixed, the bug report will never be changed from "Cannot reproduce" to "Fixed" since it's lost in the morass
I've filed a lot of bugs against KDE4. A *lot*. My experience is that (surprise, surprise, I guess), the KDE4 developers are like any other sample of human beings. Some bugs get responded to almost immediately (within minutes or hours). Some are acknowledged and are worked on over the course of days or weeks. And some indeed languish and one thinks "why did I bother? Doesn't anyone care that this is a REALLY ANNOYING BUG?" Maybe the poster just had a bad experience with one of the last kinds of bugs. Yes, it's frustrating sometimes. But hey, it's still on average hugely better than filing bugs with a big company.
Try filing a report to MS. Or Google -- or Seagate in the current mess. I've never even received a sane acknowledgement.
So bugs.kde.org sure isn't perfect; and neither are the developers. And even though I agree with most posters that the current state of KDE4 is that it frankly sucks, the best way to help is to file reports. It sure isn't going to get better if we don't.
> Followed the directions (which were linked to here last week) in detail, and I have heard back NOTHING.
They just silently closed my case.
I'm not sure what I expected, but it was definitely NOT that they would SILENTLY close the case (I only happened to notice because I have been manually checking the case page).
It's one thing to have a firmware problem; it's quite something else to simply close an active case that was created in good faith. I've opened a duplicated case, and if they don't have a darned good explanation of how the last one got closed, they just lost my business for all future drives.
I don't want to spend an hour writing a treatise on this, but I do think I need to make a few things clear.
Several issues are convolved here, and the "right" answer to each individual issue is not obvious (at least not once one factors in political and business viewpoints), so the convolution is essentially a mess. Like the original poster of the story, I have to assume that the FCC decided intentionally to delve into the mess. Anyway, here are the real issues:
1. There is (as far as I know) no new technology here. The PacketCable specs, which define how cable operators (most of them, anyway) implement VoIP were released in 1999. Comcast (like other US cable operators) has been deploying this technology since about 2002. As far as I know, the only part of the spec that Comcast don't really implement is the security portion. In any case, the specs are public and have been so for nearly a decade.
2. There is a fundamental technical difference between over-the-top VoIP (i.e., service provided by a third party such as Vonage) and telephony provided by the cable company.
3. The cable company can differentiate between its VoIP (or any other service needing preferential Quality of Service (QoS)) and ordinary so-called "best-effort" traffic, which is what is used to carry everything else, including over-the-top VoIP.
4. The reason for this is that it is the only entity that has access to the Cable Modem Termination System (CMTS), which controls the microsecond-by-microsecond details of traffic flow over the plant between a customer and the cable operator's facilities.
5. It is reasonable (from the cable operator's point of view) that since it owns the CMTS (and CMTSes are not cheap either to acquire or to manage), it's not voluntarily going to let some other company control any part of its operation (especially since if that gets screwed up, the customer experience is impacted).
6. Looked at from the point of view of guarantees applied to services, this looks like a violation of net neutrality, since over-the-top operators have to fight for bandwidth against things like P2P and web browsing, while the cable operator's phone calls don't have to do so (they have QoS guarantees).
7. But there is no law against violating new neutrality (as far as I know, in the US anyway). IANAL.
8. One can also argue that although it *looks* like a violation of net neutrality, it is in fact not such a violation, since from the viewpoint of what is happening inside DOCSIS (the protocols used to manage bandwidth on the plant between the residence and the cable company), over-the-top VoIP looks completely different from the cable company's offering. From that technical viewpoint, they can be considered two different services, and hence it would (presumably) be fine even under net neutrality principles to treat them differently.
Those are the basic ideas (although of course I've just summarized; it would take a lot more space to really describe all the details). But the basic point here is that there are lots of issues and viewpoints, some business-related, some political, and some technical. And much though one might like to demonize one party or the other, in this particular case the issues don't really seem to lend themselves to such a simple analysis.
Disclaimer: this was a quickly-written post of my initial impressions given the rather sparse (and not unambiguous) information available.
I've worked for a number of publishers, such as O'Reilly, QUE, Dummies, as both an author and editor.
Don't use Framemaker, InDesign, Pagemaker, LaTex, or any esoteric format UNLESS THE PUBLISHER TELLS YOU.
Yep. I was astounded when I did a book for O'Reilly, and they said "Don't use TeX; we don't have anyone here who understands it any more. Use Word with a template we'll send you". Personally, I hated using Word, but it's what they wanted; and part of your job as an author is to make things easy for the publisher; believe me, they'll screw up anything you try to do in a non-standard way [where "non-standard" means "something they aren't used to"].
(Ultimately, the book was published by Addison-Wesley, and they were very happy just to take the Word document and use that.)
What might be a more reasonable compromise is for ISPs to reserve a fixed 64kbps or so per user.
64kbps per customer is pretty close to what most cable companies are currently using as their "average long-term use per customer" in their network engineering.
So if they were to permanently keep this available for each customer, then there would be little or nothing left over for those customers to use for other purposes (and less than nothing for some cable operators).
Cable companies use the DOCSIS specifications: multicast is pretty feeble (I won't argue with you if you say "broken") in the versions of DOCSIS that are currently deployed. However, that changes in DOCSIS 3.0. It is one of the "big three" benefits in DOCSIS 3.0 (the others being channel bonding and IPv6 support). DOCSIS 3.0 will probably start being rolled out by at least some cable companies next year.
What good reason is there that would make Matlab insufficient for a physics major? What amount of programming does a physicist do on a given day at the job?
As a working physicist for 15 years, I would estimate somewhere between two and four hours.
And the idea of trying to do that work in Matlab makes me shudder. Well, more than shudder, really. My jobs would run for hours or days, even with C. I have no idea how typical that experience is, but it is mine.
(However, I did once model the Saha equation as applied to Jupiter's atmosphere in SuperCalc, which was a perfectly adequate tool for that job.)
Games are usually patented. Weirdly, though, Scrabble seems to have been copyrighted instead (http://www.mattelscrabble.com/en/adults/history/page6.html). It's pretty difficult for a non-lawyer like me to see how this is adequate protection. (If it was patented at some point, the patent must surely have expired anyway.)
Although TFM insists (like the summary) on using the emotive word "count", there appears to no evidence of this ability cited. TFM does describe a situation in which the fish appear to be able to distinguish among small numbers. But that is a far cry from any concept of counting.
(Which is not to say that fish can't count; I'm merely pointing out that I see no evidence for it in TFM.)
Does anyone know where the actual paper can be found? TFA is just a news release for the popular press. Going to the list of publications for the author of the study (http://www.physics.usyd.edu.au/~bmg/papers/) doesn't list anything that looks like it's the paper on which the news release is based.
TFA says: "The team's results were presented in January this year at the 211th meeting of the American Astronomical Society in Austin, Texas." but there's no indication of where the results have actually been published in a peer-reviewed journal so that one could read the paper for oneself. I looked on the AAS site and couldn't find anything there either. So, pending access to a detailed published per-reviewed account of their work, I'm reserving judgement as to how valid the claim is.
Yes; this capability is built into DOCSIS (the most common generic name for it is "DOCSIS boost"). Some cable operators turn on the feature, some do not. Comcast not only turns the feature on, but markets it rather aggressively (I think they call it "Powerboost", to give it a sexy name). The feature allows cable operators to set a temporary higher bandwidth limitation for a user, and also to set how many octets are transferred before the user is relegated to their normal bandwidth limitations. It's all spelled out in DOCSIS.
I do not know what their patent is, but the ideas from the DOCSIS MAC layer are also used in all 802.11 standards as well as satellite modem standards.
And WiMAX. To a rather good approximation, WiMAX is DOCSIS-over-radio.
It would be nice to get some detailed information about what exactly these Rembrandt people are claiming, but TFA seems to be devoid of any technical details.
TFA does also talk about another lawsuit, filed jointly last November by the big data-over-cable equipment manufacturers against Rembrandt, basically seeking a declaratory ruling that they aren't infringing any Rembrandt IP.
I couldn't find a confirmation in TFA as to which companies really had machines decertified. Our local (Boulder) paper reported this morning that of the four companies involved, only Premier/Diebold had *no* certification revoked. So that's rather at odds with the summary. Seeing that I couldn't see any confirmation of the summary's statement in TFA, I suspect that the local paper got it right.
Because that's not useful. If they encrypt your data for you, guess what? They have the key! If you want your data safe from them, YOU need to encrypt it. That's just how it works.
That's only how symmetric key cryptography works. If the only reason that this system was insecure was that Google would have the decryption key, then one would use public key cryptography to circumvent the weakness.
However, the real hole in letting them encrypt the data is that you have no way to stop them from keeping an unencrypted version somewhere.
So your conclusion is correct, but for the wrong reason.
I hereby place the qmail package (in particular, qmail-1.03.tar.gz, with MD5 checksum 622f65f982e380dbe86e6574f3abcb7c) into the public domain. You are free to modify the package, distribute modified versions, etc.
Slashdot Mirror
Are we back to the late 90s "no business model yet possible future earning potential" view of businesses?
Yes.
Publishers' Weekly is reporting that a request for a four-month extension by a group of authors has been approved.
http://www.publishersweekly.com/article/CA6654845.html
What I don't understand, as an author who holds copyright in at least one book that is out of print, is: how can a lawsuit to which I am not a party give *my* rights under copyright law to someone else?
That seems to be fundamentally wrong.
Tangentially, I find it somewhere between interesting and amusing (or perhaps scary) that Google appears to have made no attempt to contact me, despite the fact that I'm hardly the most difficult person to find.
Even more tangentially, there doesn't seem to be any place to go to see if google has actually digitized a book in which I have rights. Someone please correct me if there's a way to do that. (But in any case, why should I be the one who has to go and see if they've infringed rights? They are the ones who are supposed to seek permission from me.)
Frankly, this whole "settlement" seems utterly unconscionable.
My main concern would be privacy. You start putting confidential client files on the internet, and if anything goes wrong you are looking at a malpractice suit for sure.
I tried to explain that to a local lawyer who wanted to use gmail (unencrypted, of course) for his practice's e-mail. I could never get him to understand that there was anything even remotely wrong with doing what he wanted to do. So now he's doing it.
Just as scary, none of his clients seem to think that it's a problem.
This is one of those times that I just want to bang my head on a wall and scream (to myself, since no one else seems to listen), "Why does no one else get it?"
And by talking to other lawyers here, their backup strategy generally seems to consist of... hope that they never have a fire (or, in some cases, hope that they never lose a hard drive).
I'm wondering if the problem is not so much poor software quality as it is a bottleneck in the feed itself. Perhaps the servers can't take the load, or perhaps they simply don't have enough well-placed bandwidth.
I don't see how that can be the problem. I just watched a program on my Roku box, and it was the same quality (4 stars on their bandwidth indicator) as usual. I watch several movies or programs a week in this manner, and it's always the same quality.
> So... the bug report will be marked "Cannot reproduce". Then a couple other suckers that were so annoyed by it that they took the time to create an account in the bug system will post "Still reproducible on 4.4", but it'll never get fixed. And even if it does get fixed, the bug report will never be changed from "Cannot reproduce" to "Fixed" since it's lost in the morass
I've filed a lot of bugs against KDE4. A *lot*. My experience is that (surprise, surprise, I guess), the KDE4 developers are like any other sample of human beings. Some bugs get responded to almost immediately (within minutes or hours). Some are acknowledged and are worked on over the course of days or weeks. And some indeed languish and one thinks "why did I bother? Doesn't anyone care that this is a REALLY ANNOYING BUG?" Maybe the poster just had a bad experience with one of the last kinds of bugs. Yes, it's frustrating sometimes. But hey, it's still on average hugely better than filing bugs with a big company.
Try filing a report to MS. Or Google -- or Seagate in the current mess. I've never even received a sane acknowledgement.
So bugs.kde.org sure isn't perfect; and neither are the developers. And even though I agree with most posters that the current state of KDE4 is that it frankly sucks, the best way to help is to file reports. It sure isn't going to get better if we don't.
> Followed the directions (which were linked to here last week) in detail, and I have heard back NOTHING.
They just silently closed my case.
I'm not sure what I expected, but it was definitely NOT that they would SILENTLY close the case (I only happened to notice because I have been manually checking the case page).
It's one thing to have a firmware problem; it's quite something else to simply close an active case that was created in good faith. I've opened a duplicated case, and if they don't have a darned good explanation of how the last one got closed, they just lost my business for all future drives.
I don't want to spend an hour writing a treatise on this, but I do think I need to make a few things clear.
Several issues are convolved here, and the "right" answer to each individual issue is not obvious (at least not once one factors in political and business viewpoints), so the convolution is essentially a mess. Like the original poster of the story, I have to assume that the FCC decided intentionally to delve into the mess. Anyway, here are the real issues:
1. There is (as far as I know) no new technology here. The PacketCable specs, which define how cable operators (most of them, anyway) implement VoIP were released in 1999. Comcast (like other US cable operators) has been deploying this technology since about 2002. As far as I know, the only part of the spec that Comcast don't really implement is the security portion. In any case, the specs are public and have been so for nearly a decade.
2. There is a fundamental technical difference between over-the-top VoIP (i.e., service provided by a third party such as Vonage) and telephony provided by the cable company.
3. The cable company can differentiate between its VoIP (or any other service needing preferential Quality of Service (QoS)) and ordinary so-called "best-effort" traffic, which is what is used to carry everything else, including over-the-top VoIP.
4. The reason for this is that it is the only entity that has access to the Cable Modem Termination System (CMTS), which controls the microsecond-by-microsecond details of traffic flow over the plant between a customer and the cable operator's facilities.
5. It is reasonable (from the cable operator's point of view) that since it owns the CMTS (and CMTSes are not cheap either to acquire or to manage), it's not voluntarily going to let some other company control any part of its operation (especially since if that gets screwed up, the customer experience is impacted).
6. Looked at from the point of view of guarantees applied to services, this looks like a violation of net neutrality, since over-the-top operators have to fight for bandwidth against things like P2P and web browsing, while the cable operator's phone calls don't have to do so (they have QoS guarantees).
7. But there is no law against violating new neutrality (as far as I know, in the US anyway). IANAL.
8. One can also argue that although it *looks* like a violation of net neutrality, it is in fact not such a violation, since from the viewpoint of what is happening inside DOCSIS (the protocols used to manage bandwidth on the plant between the residence and the cable company), over-the-top VoIP looks completely different from the cable company's offering. From that technical viewpoint, they can be considered two different services, and hence it would (presumably) be fine even under net neutrality principles to treat them differently.
Those are the basic ideas (although of course I've just summarized; it would take a lot more space to really describe all the details). But the basic point here is that there are lots of issues and viewpoints, some business-related, some political, and some technical. And much though one might like to demonize one party or the other, in this particular case the issues don't really seem to lend themselves to such a simple analysis.
Disclaimer: this was a quickly-written post of my initial impressions given the rather sparse (and not unambiguous) information available.
I note that Seagate says (at http://seagate.custkb.com/seagate/crm/selfservice/search.jsp?DocId=206091): "Desktop and Mobile SATA and PATA drives are not designed for firmware updates in the field."
Yep. I was astounded when I did a book for O'Reilly, and they said "Don't use TeX; we don't have anyone here who understands it any more. Use Word with a template we'll send you". Personally, I hated using Word, but it's what they wanted; and part of your job as an author is to make things easy for the publisher; believe me, they'll screw up anything you try to do in a non-standard way [where "non-standard" means "something they aren't used to"].
(Ultimately, the book was published by Addison-Wesley, and they were very happy just to take the Word document and use that.)
In the US, ISPs do not have, and never have had, "common carrier status".
PowerPro. http://powerpro.webeddie.com/
64kbps per customer is pretty close to what most cable companies are currently using as their "average long-term use per customer" in their network engineering.
So if they were to permanently keep this available for each customer, then there would be little or nothing left over for those customers to use for other purposes (and less than nothing for some cable operators).
Cable companies use the DOCSIS specifications: multicast is pretty feeble (I won't argue with you if you say "broken") in the versions of DOCSIS that are currently deployed. However, that changes in DOCSIS 3.0. It is one of the "big three" benefits in DOCSIS 3.0 (the others being channel bonding and IPv6 support). DOCSIS 3.0 will probably start being rolled out by at least some cable companies next year.
As a working physicist for 15 years, I would estimate somewhere between two and four hours.
And the idea of trying to do that work in Matlab makes me shudder. Well, more than shudder, really. My jobs would run for hours or days, even with C. I have no idea how typical that experience is, but it is mine.
(However, I did once model the Saha equation as applied to Jupiter's atmosphere in SuperCalc, which was a perfectly adequate tool for that job.)
Games are usually patented. Weirdly, though, Scrabble seems to have been copyrighted instead (http://www.mattelscrabble.com/en/adults/history/page6.html). It's pretty difficult for a non-lawyer like me to see how this is adequate protection. (If it was patented at some point, the patent must surely have expired anyway.)
(Which is not to say that fish can't count; I'm merely pointing out that I see no evidence for it in TFM.)
TFA says: "The team's results were presented in January this year at the 211th meeting of the American Astronomical Society in Austin, Texas." but there's no indication of where the results have actually been published in a peer-reviewed journal so that one could read the paper for oneself. I looked on the AAS site and couldn't find anything there either. So, pending access to a detailed published per-reviewed account of their work, I'm reserving judgement as to how valid the claim is.
Yes; this capability is built into DOCSIS (the most common generic name for it is "DOCSIS boost"). Some cable operators turn on the feature, some do not. Comcast not only turns the feature on, but markets it rather aggressively (I think they call it "Powerboost", to give it a sexy name). The feature allows cable operators to set a temporary higher bandwidth limitation for a user, and also to set how many octets are transferred before the user is relegated to their normal bandwidth limitations. It's all spelled out in DOCSIS.
Yes. It's part of the data returned by Google. The ISP has to snoop the data stream and insert its own traffic into it.
ISPs should be forbidden from altering the data stream unless they own the content that's being transferred.
And WiMAX. To a rather good approximation, WiMAX is DOCSIS-over-radio.
It would be nice to get some detailed information about what exactly these Rembrandt people are claiming, but TFA seems to be devoid of any technical details.
TFA does also talk about another lawsuit, filed jointly last November by the big data-over-cable equipment manufacturers against Rembrandt, basically seeking a declaratory ruling that they aren't infringing any Rembrandt IP.
Why do you think it's not part of Ubuntu? According to synaptic, it's part of the "Base System" in my 64-bit Kubuntu gutsy installation.
I couldn't find a confirmation in TFA as to which companies really had machines decertified. Our local (Boulder) paper reported this morning that of the four companies involved, only Premier/Diebold had *no* certification revoked. So that's rather at odds with the summary. Seeing that I couldn't see any confirmation of the summary's statement in TFA, I suspect that the local paper got it right.
That's only how symmetric key cryptography works. If the only reason that this system was insecure was that Google would have the decryption key, then one would use public key cryptography to circumvent the weakness.
However, the real hole in letting them encrypt the data is that you have no way to stop them from keeping an unencrypted version somewhere.
So your conclusion is correct, but for the wrong reason.
From http://cr.yp.to/qmail/dist.html:
I hereby place the qmail package (in particular, qmail-1.03.tar.gz, with MD5 checksum 622f65f982e380dbe86e6574f3abcb7c) into the public domain. You are free to modify the package, distribute modified versions, etc.