I believe that the state DID provide some funding to them in some form or another. Now, if any of that money came from out of Fed funds, they're stuck. If there's any sort of free speech clauses in the State's laws, they're stuck.
Don't worry about the late reply... All these things typically end up being is people closing off arguments (which, when done this way is fun anyhow...). Now, on to your latest comment...
Considering that the acts of Infringement can't be applied to a tool supplier, save for contributory infringement (and that's not what I see the AHRA talking to there...), it's odd to say the least to refer to the consumer in this matter. I guess my understanding is a little different than yours on this one.
My understanding is from how my dealings with Copyright and Patent law, due to my being an SF Author (not published, mind, but it's not because of a lack of trying...:-), a software engineer for hire, a computer games developer, and a Patented Inventor. I won't say that I'm a 100% reliable resource, since I'm not a lawyer. But, when they specifically mention out something along the lines of the discussed passage, it's typically meant literally- they can't bring an action against a consumer using the device to infringe in a non-commercial manner, not that the manufacuterer can't be held for contributory infringement. In this case, you have to consider that they're charging a compulsory royalty license on each and every analog audio playback capable device in existence with the AHRA- why? Because they wanted to get reimbursed for any potential losses due to recording media by individuals. So, they gave it to them with the understanding that copying is licensed in the context of personal re-recording of protected works for non-profit reasons, incl. fair use ones. Now, this may not be the case, but everything else points to what I'm saying. Otherwise, they shouldn't be able to charge us that Tariff on devices and media- legally.
And New Orleans was also talking to turning over the service once things are largely done over to a commercial entity instead of maintaining it themselves- BellSouth just did themselves out of a possible nice broadband services offering (because I sure as hell wouldn't list them as one of the businesses slated for the taking over phase of things...).
Idiots, they're so damn greedy that they're willing to cut their nose off to spite their face.
"or based on the noncommercial use by a consumer of such a device or medium for making digital musical recordings or analog musical recordings."
Considering that the Copyright laws don't directly apply in that timeframe (The DMCA changed things, mind...) to the device manufacturers themselves save for deliberate design work to provide infringements but applied to the people doing the infringing, the above portion of the passage applies to you and I. There is a small extra amount applied to all devices and media that is paid to the labels, ostensibly to reimburse the artists for "losses" incurred due to casual copying performed by devices by individuals in a not for profit manner. In order for them to do this, the government had to give something back (because they weren't corrupt like they are these days, they still viewed things as give or take- nowadays with the take, take, take mentality...), in this case, it's a defense to prosecution to say "I'm a consumer and I did it just for myself with personal equipment...". You've paid for the act in question as the fees charged on consumer recording equipment and media has been assessed against it as a compulsory license on the works in question.
...and a completely different animal when it's offered and then recinded for most reasons imagineable or possible.
"Well then, I guess I'll take my ball and go home now..."
Instead of figuring a way to work their business position out in the context of a legitimate offering by the government, they opt to act like spoiled brats.
Upon a proper search of the USPTO database of Registered Trademarks, "Risk" for the board and computer game variants IS registered for Hasbro. However, there is no registration for the look/feel of the game pieces, etc. so that falls pretty clearly into the Copyright domain. Now, since the Web Risk[TM] game that used Google Maps to render the globe's details didn't really USE anything other than the game mechanics, doesn't specifically copy the verbiage from the game's rulesheet, and didn't appear to do anything else that might have infringed on Hasbro's "IP" rights, I reccomend that he consult a lawyer for certainty, strip out the Trademark Violation from the game, and tell Hasbro to go pound sand on the rest of it as it's not infringing nor is it a Trademark Violation at that point.
It's a Trademark issue and they're claiming Trademark on the entire game including gameplay (which is what was in the cease and desist letter...). However, they can only Trademark (and I'd love to check and see if they've GOT the registrations on all of that up-to-date (because if they don't- I'm advising the guy go get a lawyer and sue the hell out of Hasbro for harassment...)) and they can only trademark something along the lines of the look and feel of the game pieces at best. "Risk" is a very common word and would be difficult to make a trademark case out of any "infringements" on the same. The actual rules might be copyrighted, but since he's not duplicating the content thereof, only the mechanics, that's not applicable.
Simply put, he pulled it because he didn't have a Lawyer to defend his position, nor could he afford to mount a case. Me, I might have changed the name, but the rest, I'd have told them to go pound sand as they can't make the claims they're making.
...one of Trademarks. While I'm not a lawyer, I am rather familiar with the various "IP" laws, being an inventor and an author of SF. Since the online Risk game used the name, the guy who wrote the Google Maps version had a problem with that part specifically- and Hasbro DID have a right to ask him to stop calling it that. The other claims of the elements of Risk are bogus since these are NOT really trademarkable, only Copyrightable. Since Copyright only covers the SPECIFIC implementation of an idea, they really didn't have a leg to stand on as this was a game, played on the Web that used Google Maps to render portions of the screens- NOT a board game like Risk is. The MAIN reason why the guy pulled it was one of not having the funds to put up a defense against the rest of the complaints Hasbro fobbed off on him. And, that's the biggest complaint I've got about how the "IP" laws are worded- the rich are the only ones that can actually use it or defend against spurious uses thereof. If you're a rights holder, you only have as much protection for your "IP" as you have cash to burn defending your rights. If you're not and aren't really infringing on things, you only have as much defense against unreasonable claims as you've got cash to burn defending your rights.
"No action may be brought under this title alleging infringement of copyright based on the manufacture, importation, or distribution of a digital audio recording device, a digital audio recording medium, an analog recording device, or an analog recording medium, or based on the noncommercial use by a consumer of such a device or medium for making digital musical recordings or analog musical recordings."
When the government agreed to let them collect money on the potential of infringements done by way of tape and CD, they also took away their right to pursue infringements regarding the same when they enacted the AHRA. You have already paid the royalties in most cases, so it's not really illegal. Now, this only applies to AUDIO- I don't believe there's an analog for video present.
"No action may be brought under this title alleging infringement of copyright based on the manufacture, importation, or distribution of a digital audio recording device, a digital audio recording medium, an analog recording device, or an analog recording medium, or based on the noncommercial use by a consumer of such a device or medium for making digital musical recordings or analog musical recordings."
You can legally make copies of things, so long as you're personally copying someone else's instance of the protected work while it's in their posession and you're not doing it for profit. You've already paid the compulsory royalties on the media and the device in most cases.
Simply put, stating publicly that you will not pursue litigation with respect to a Patent or Copyright under "X" conditions, while not carrying the same weight as a license, will make it deucedly difficult to pursue an "infringer" at some later date because there would be an expectation of them keeping to their public proclaimations at a later date. But, it would only apply to the implementations that explicitly followed what was "promised" and anything else, esp. after they go back on their promise, would be fair game. With a license, what is stated goes- period. No, "Oh, we changed our minds...", etc.
I want a license, not a promise. While it will protect me in court, a promise holds less weight than an explicit license.
Defys logic and common sense? Only if you're thinking APIs, which glibc isn't just that...
If you compile and link cleanly against a given version of glibc, you've built against an interface to the whole system for a given version of the system. If you're working an ABI layer (not an API, which has different thinking involved- which may be where you think it defys logic and reason...) you don't want an application trying to use an older ABI interface because it might try to run against features NOT present in the ABI at the time of the application build. In this case, glibc is an API AND an ABI- so you pretty much need the versioning/locking scheme glibc uses for things. RPM blocks, yes, but if you've got source code, you can rpmbuild the package to map to the older glibc (so long as the app doesn't attempt to use anything from the newer glibc- which would be unworkable anyhow...).
It's problematic, yes. Defys logic and reason, no. If they had the same thing consistent on C++, there'd be a lot less issues with dynamic objects, etc. and it'd be easier to consistently build applications that span multiple revisions of a given distribution(s)- so long as you adhered to the rules. Besides, you really, really don't want to use code that hasn't been vetted against the oldest version of the ABI it's intended to be ran against ANYHOW. The fact that Autopackage "works around it" is irrelevent, really- you shouldn't really be "working around it" in the first place. Better yet, Autopackage, as it currently exists, only helps out with someone making packages for x86 ON x86 machines and doesn't cope with a lot of the things one might encounter doing cross-compilation, AMD64 execution, etc. I know, I've recently tried to utilize some of their tech, currently it doesn't play nice in a cross-compile environment because it doesn't know how to cope with it. It doesn't really work nicely with AMD64 setups either- all the Autopackages I've tried to install on my Athlon64 machines kind of don't install; but a 32-bit version, copied from a 32-bit machine that had the selfsame package installed on, it works as intended.
Autopackage is nice, but it's not for all solution sets, nor does it fix all the problems for even desktop deployment like you make it out to do here. It's a dramatic improvement with things, but it's not the silver bullet for all these problems that you make it out to be.
...niether is glibc updates for Linux admins... When they are, they're handled, typically, in the manner a Windows update is... What they did, wasn't what would be in either world.
That if you consider that the decisions are representative for most large companies, then they'd have had issues with Windows. It's as if the admins deliberately chose the absolute wrong path for each Linux decision. I've made these points earlier, if you did the analogous things under Windows you'd end up with a mess much like the one the Linux admins ended up with- probably worse.
You simply don't replace glibc without vetting code- all of it in the system. An official update or the next version should (and typically does) have the bulk of this work done for you already. If they're saying that the revision control process wouldn't let them upgrade the version of the distribution, they already broke that because an update to glibc of the nature in question IS a version update for all intents and purposes.
The whole thing is flawed because the analogous insane decisions were NOT applied to the Windows side as well.
"And several 'experienced' Linux admins had trouble making MySQL work on SUSE?"
To play devil's advocate for a moment, how do we know you're past just "experienced" and on deep into the Wizard or Guru realm of administration or programming? (I know, I know, but he's going to flip that one out all the same... I'd be legitimately tarred with that brush in his response... >:-))
Realistically, though, you're right- I have issues with all of this. They picked distros that would most likely have issues with things. They picked rules that required a lot of patching on the Linux side, but only had the normal set of updates on the Windows side- a lot of patching that simply wasn't needed and didn't have an analog in the Windows world. They picked a stilted set of conditions that honestly would have mandated a distribution version update- in any shop for any OS you could name in the real world.
I have trouble buying into this- and it's to the point that I'm being forced to re-work my own stuff for my startup because I was referring to other papers by them; I can't trust the data here as far as I could pick the Doctor up and throw him, so everything from this consultancy firm is now suspect.
I have grave concerns as I'm reading the paper. If the 3rd party component needed an upgrade to a new glibc, you would never have done what these admins allegedly did in the paper. It would have been a red-flag on the component in question and if it was something critical to the application, it would be assumed that the official version of the OS that was supported by the components was SLES 9, not 8 because it didn't have support for that version of glibc. You don't hack something like this in a production system, ever- even if you've got the skills to pull something like it off. I've got the skills, but even I wouldn't do what was done. You'd do a migration to the next version- period. There's far, far too many things that can go wrong and you really need to vet everything once you do it. What your esteemed admins did was analogous to someone haxoring kernel.dll by patching it manually and then putting it into a production Windows machine. I honestly don't know of anyone in their right mind that would do that one- ever.
Another faintly disturbing thing in this paper is that it's assumed that it's Linux at fault, when in reality, it was the ancillary components' requirements and someone trying to bull their way through the "problem". There's several problems with this, but I can number a few key ones for you:
1) glibc's interface, the ABI, doesn't change all that much over time. Typically, it's linked to at runtime through a sonamed link to the actual.so file (Currently libc.so.6 on modern Linux and *BSD distributions...). This interface can be safely used for many years at a time, in spite of varying version numbers and the expected behavior will be the same for an older and a newer version- so long as you're not stepping on a bug within the older version or a new feature offered by a later on version of the runtime.
2) Yes, you CAN get away with minor revision updates of glibc without problems, but typically, you need to vet all your compiled code for regression testing purposes. It really, really is like replacing kernel.dll on Windows. If it isn't provided as an update, you've got a lot of regression work ahead of you to ensure that fixes done to the library don't break other code (Typically not a problem, but you never can tell when someone mis-used something...)- this is NOT something that your rank-and-file sysadmin has any real business doing. It's NOT their job.
3) Either the component stepped on a bug, or they're using some new feature of the glibc layer. In either case, you can't bull your way into using it on something that doesn't have the needed support level. What your admins did was analogous to trying to make this work on NT4, only to find out that you need the.Net framework for everything and then proceeded to install pieceparts of the OS to get it there.
The study's flawed- that plain, that simple. You can defend it all you'd like, but it's got bad problems that everyone, myself included, have been pointing out and you've avoided answering several of the key points we've been making.
The Linux admins were artificially given much more to do and screw up than the Windows admins, if the verbiage in the paper is to be believed. They were mandated to patch much more than is realistic, etc. in a production shop. If you were to have to patch all the local exploits in everything Windows related, you'd be very busy, moreso than the Linux admins- but they only had to do the Windows critical updates as MS provided them. The Linux admins were off patching everything- even if it wasn't very relevent to the servers (i.e. if it's a properly set up server, they shouldn't be ABLE to exploit local exploit possibilities, etc...). Worse, they had the guys doing manual updates to a lot of stuff, even though it WASN'T needed.
The study's heavily stilted to favor Microsoft and Windows- either through ignorance or malice. It'd be your call on how it got there, but it DID get there all the same.
...upgrading something like kernel.dll under NT4, 2000, XP, etc. It's not something lightly undertaken on a running machine- especially a production machine. Typically, when something of that magnitude needs an update, it's a full system upgrade- doesn't matter if it's Windows, etc. What makes the author of the report think that this was even remotely a fair comparison in question.
And I'll be honest, I find it fishy to say the least that he seemed to need that specific version of glibc; pretty much all vendors that are in the FOSS world try to track deprecated interfaces, avoid making calls to "broken" apis on the machines in question, etc. Even with a security flaw present, unless the glibc actually is the root cause, they will go out of their way to code around problems in most cases instead of mandating a glibc update for customers- it's that big a deal. Better yet, it seems that the official version updates from SuSE DID address all of this, including dealing with a fix to glibc that changed the revision number. If it's on SuSE's update sets, it's been pretty much vetted unless you change something fundamental, like glibc, at which time, all bets are off- it'd be the same way with Windows if you figured out how to accomplish a swap out of kernel.dll, or similar. Currently, for all distributions in main use except for Slackware, a system of handling all dependency relationships and obtaining all the official updates, etc. online. This is a KNOWN feature of all those distributions, whether you're talking Yast, urpmi, apt-get, yum, up-2-date, etc. Given that this is the case, not a single admin that actually knows what he's doing would have ever done what you describe in the draft 13 version of the paper on page 31, where you list things like admins doing by-hand updates of glibc, etc. That's "where Angels fear to tread" territory and would only be attempted by people that either roll custom distributions for embedded use or similar (Myself, for example...)- which would not be your typical sysadmin and they'd not be doing something like that with a production or pre-production server because they know better. And this is just one of numerous flaws with the whole study. I'll try to get to more later.
While I won't label you as a shill for Microsoft (partly because you're brave enough to face the gauntlet on this site...), I will question your ability to frame in adequate tests that actually test something- because you failed to do anything useful here except give Microsoft precisely what they were looking for. The work you did as presented to the whole world is hopelessly flawed in a manner not unlike what Mindcraft did for Microsoft a while back. I'd not consider your firm a reliable source of input or information at this point- while I was going to use one of your other papers that was provided online for a reference item in one of the white papers I am working on for my company, I must now largely discard this and find other sources for the information as everything you've produced is suspect because of the egregious flaws in the paper we're discussing.
If people don't buy the titles, then they don't see further royalties as the studios won't press any more titles- $10/disc is pretty steep expenditures. If you do well, say like EA's stuff, it'll be okay. If you're a lesser publisher/studio, that'd be daunting. You could very well dump THOUSANDS on royalties up-front and see little of any return on an excellent but undersold (for whatever reasons...) game. It's a bloody balancing act and they know it.
I know better than this, and really, so do you if you thought about this just a little bit...
Developer costs have to be kept low so that people will produce for a given console in the first place- if you extract part of the costs of the console losses even slightly from the developers, they'll very probably skip the console in question and go to another one. It's as simple as that. As a developer, if I'm not going to see a return on a run that ends up producing at least a wash on sales, it's just not going to get done as I'm supposed to be in the business of making money. I have to pay per instance just to run on the damn thing so people can play my game. I have to pay for a developer station so I can test for deploy. I have to pay for a runtime engine or roll my own that'll run on it. And, so forth... All this adds up. The amount of money they "recoup" on developer fees alone is in the noise floor here. It doesn't do anything for their bottom line- it does, however, regulate who gets to provide games and the quality level though. It has to meet with Microsoft's final stamp of approval or it doesn't ship for X-Box/XB360 and you have to pony up some cash and pay a portion of your profits back to them to be able to run on it. That's a bar against any Joe Shmoe wannabe game developer from producing something for sale that makes their console(s) look bad.
Royalties is the only place they expect to really see a return on things at this point (No guarantees of production process improvements- and you'd better NOT be betting on that as that's counting chickens before they hatch...) so they need 13 titles to be sold per XB360 unit currently ever sold to begin see a profit. This means that in order to be profitable, they're going to have to stay the course for at least 2-3 years at minimum to start seeing profits on this mess.
Production process improvements come over time, typically somewhere between 1-3 years of production. Sometimes within 6 months, but usually it's 12-18 months into it that you start really seeing anything out of that. And that's if you've designed everything right. Sometimes you get a design that won't see benefits from production improvements for years. You can't bet on that sort of thing unless you've designed them in from the start and they're more due to volume than device improvements when you run that play. At $400+ per unit, any volume discounts will also be in the noise floor for some time to come as they're already seeing those discounts with what they're producing in the first place.
The numbers being high? Not really. These prices I'm seeing in the article are conservative, as in being close to what they're probably seeing in costs.
Sony tends to lose a little money on each console for the first 6 to 12 months of sales and then as production volumes and process improvements come into play, they start seeing a small profit on the consoles, even as the prices get cut through the lifespan of the console. They're willing to eat a little of their potential profits to get the box out into the market. Now, Microsoft's blowing money left and right by comparison.
$399 is NOT appealing. It's not even enticing. For that, you can get a decently decked out PC and rig it to the TV with pretty much the same results (Esp. in light of the recent stability woes the XB360 seems to be experiencing...). A lower price point would have been appealing- but they really don't want to shoulder over 2/3rds of the cost for the machines- they're shouldering probably half right now as it is. (The figures given are off- they're using the MS cost and the MSRP for the boxes, which typically accounts for anywhere from a 50-300% markup for retail profits to make it appealing to stock the things in the first place (You don't think Wal-Mart, Best Buy, etc. would stand up for stocking the things at their cost do you?)).
I see Sony coming in under that price point, if only slightly, just to turn the screws on Microsoft here.
Borrowing other rulings from other Jurisdictions tends to make for appeals getting granted- Judges don't like doing that and typically don't do that sort of thing. Now, you said that you've seen this thing in Texas- why didn't you quote some Texas Jurisprudence instead of out of state stuff. I'm sure there's been some suits out there like this in the past. You didn't because there's nothing as of yet in Texas that has been done the way you're talking to. No, I'm not a lawyer, but unless you've read the law and consulted WITH one (I've done this on a periodic basis in the past on things similar to this one...) how can you suppose anything without past proof? You can't.
To quote you, go blow smoke up someone's ass, as mine's full of yours.
Actually, that all varies from state to state. And, in many cases, all the Judge gets to do is say, "Yeah, they have to pay that" or, "Yeah, but it's only X dollars in fines..." or, "No, they didn't do anything wrong...". The Judge is bound by what the LAW stipulates he can/can't do with regards to things like fines, etc. Each state has different laws and different applications thereof- just because Calif. has it one way, doesn't mean that Texas has it exactly the same way. All you did was point out jurisprudence in other states which isn't applicable to Texas Law. Unless you're a lawyer practicing in the State of Texas or have read up on various bits and bobs of Texas Law, you might want to refrain from discussing the subject as you honestly don't know how it works.
Slashdot Mirror
I believe that the state DID provide some funding to them in some form or another. Now, if any of that money came from out of Fed funds, they're stuck. If there's any sort of free speech clauses in the State's laws, they're stuck.
Don't worry about the late reply... All these things typically end up being is people closing off arguments (which, when done this way is fun anyhow...). Now, on to your latest comment...
:-), a software engineer for hire, a computer games developer, and a Patented Inventor. I won't say that I'm a 100% reliable resource, since I'm not a lawyer. But, when they specifically mention out something along the lines of the discussed passage, it's typically meant literally- they can't bring an action against a consumer using the device to infringe in a non-commercial manner, not that the manufacuterer can't be held for contributory infringement. In this case, you have to consider that they're charging a compulsory royalty license on each and every analog audio playback capable device in existence with the AHRA- why? Because they wanted to get reimbursed for any potential losses due to recording media by individuals. So, they gave it to them with the understanding that copying is licensed in the context of personal re-recording of protected works for non-profit reasons, incl. fair use ones. Now, this may not be the case, but everything else points to what I'm saying. Otherwise, they shouldn't be able to charge us that Tariff on devices and media- legally.
Considering that the acts of Infringement can't be applied to a tool supplier, save for contributory infringement (and that's not what I see the AHRA talking to there...), it's odd to say the least to refer to the consumer in this matter. I guess my understanding is a little different than yours on this one.
My understanding is from how my dealings with Copyright and Patent law, due to my being an SF Author (not published, mind, but it's not because of a lack of trying...
And New Orleans was also talking to turning over the service once things are largely done over to a commercial entity instead of maintaining it themselves- BellSouth just did themselves out of a possible nice broadband services offering (because I sure as hell wouldn't list them as one of the businesses slated for the taking over phase of things...).
Idiots, they're so damn greedy that they're willing to cut their nose off to spite their face.
Considering that the Copyright laws don't directly apply in that timeframe (The DMCA changed things, mind...) to the device manufacturers themselves save for deliberate design work to provide infringements but applied to the people doing the infringing, the above portion of the passage applies to you and I. There is a small extra amount applied to all devices and media that is paid to the labels, ostensibly to reimburse the artists for "losses" incurred due to casual copying performed by devices by individuals in a not for profit manner. In order for them to do this, the government had to give something back (because they weren't corrupt like they are these days, they still viewed things as give or take- nowadays with the take, take, take mentality...), in this case, it's a defense to prosecution to say "I'm a consumer and I did it just for myself with personal equipment...". You've paid for the act in question as the fees charged on consumer recording equipment and media has been assessed against it as a compulsory license on the works in question.
...and a completely different animal when it's offered and then recinded for most reasons imagineable or possible.
"Well then, I guess I'll take my ball and go home now..."
Instead of figuring a way to work their business position out in the context of a legitimate offering by the government, they opt to act like spoiled brats.
Upon a proper search of the USPTO database of Registered Trademarks, "Risk" for the board and computer game variants IS registered for Hasbro. However, there is no registration for the look/feel of the game pieces, etc. so that falls pretty clearly into the Copyright domain. Now, since the Web Risk[TM] game that used Google Maps to render the globe's details didn't really USE anything other than the game mechanics, doesn't specifically copy the verbiage from the game's rulesheet, and didn't appear to do anything else that might have infringed on Hasbro's "IP" rights, I reccomend that he consult a lawyer for certainty, strip out the Trademark Violation from the game, and tell Hasbro to go pound sand on the rest of it as it's not infringing nor is it a Trademark Violation at that point.
It's a Trademark issue and they're claiming Trademark on the entire game including gameplay (which is what was in the cease and desist letter...). However, they can only Trademark (and I'd love to check and see if they've GOT the registrations on all of that up-to-date (because if they don't- I'm advising the guy go get a lawyer and sue the hell out of Hasbro for harassment...)) and they can only trademark something along the lines of the look and feel of the game pieces at best. "Risk" is a very common word and would be difficult to make a trademark case out of any "infringements" on the same. The actual rules might be copyrighted, but since he's not duplicating the content thereof, only the mechanics, that's not applicable.
Simply put, he pulled it because he didn't have a Lawyer to defend his position, nor could he afford to mount a case. Me, I might have changed the name, but the rest, I'd have told them to go pound sand as they can't make the claims they're making.
...one of Trademarks. While I'm not a lawyer, I am rather familiar with the various "IP" laws, being an inventor and an author of SF. Since the online Risk game used the name, the guy who wrote the Google Maps version had a problem with that part specifically- and Hasbro DID have a right to ask him to stop calling it that. The other claims of the elements of Risk are bogus since these are NOT really trademarkable, only Copyrightable. Since Copyright only covers the SPECIFIC implementation of an idea, they really didn't have a leg to stand on as this was a game, played on the Web that used Google Maps to render portions of the screens- NOT a board game like Risk is. The MAIN reason why the guy pulled it was one of not having the funds to put up a defense against the rest of the complaints Hasbro fobbed off on him. And, that's the biggest complaint I've got about how the "IP" laws are worded- the rich are the only ones that can actually use it or defend against spurious uses thereof. If you're a rights holder, you only have as much protection for your "IP" as you have cash to burn defending your rights. If you're not and aren't really infringing on things, you only have as much defense against unreasonable claims as you've got cash to burn defending your rights.
When the government agreed to let them collect money on the potential of infringements done by way of tape and CD, they also took away their right to pursue infringements regarding the same when they enacted the AHRA. You have already paid the royalties in most cases, so it's not really illegal. Now, this only applies to AUDIO- I don't believe there's an analog for video present.
You can legally make copies of things, so long as you're personally copying someone else's instance of the protected work while it's in their posession and you're not doing it for profit. You've already paid the compulsory royalties on the media and the device in most cases.
Simply put, stating publicly that you will not pursue litigation with respect to a Patent or Copyright under "X" conditions, while not carrying the same weight as a license, will make it deucedly difficult to pursue an "infringer" at some later date because there would be an expectation of them keeping to their public proclaimations at a later date. But, it would only apply to the implementations that explicitly followed what was "promised" and anything else, esp. after they go back on their promise, would be fair game. With a license, what is stated goes- period. No, "Oh, we changed our minds...", etc.
I want a license, not a promise. While it will protect me in court, a promise holds less weight than an explicit license.
Defys logic and common sense? Only if you're thinking APIs, which glibc isn't just that...
If you compile and link cleanly against a given version of glibc, you've built against an interface to the whole system for a given version of the system. If you're working an ABI layer (not an API, which has different thinking involved- which may be where you think it defys logic and reason...) you don't want an application trying to use an older ABI interface because it might try to run against features NOT present in the ABI at the time of the application build. In this case, glibc is an API AND an ABI- so you pretty much need the versioning/locking scheme glibc uses for things. RPM blocks, yes, but if you've got source code, you can rpmbuild the package to map to the older glibc (so long as the app doesn't attempt to use anything from the newer glibc- which would be unworkable anyhow...).
It's problematic, yes. Defys logic and reason, no. If they had the same thing consistent on C++, there'd be a lot less issues with dynamic objects, etc. and it'd be easier to consistently build applications that span multiple revisions of a given distribution(s)- so long as you adhered to the rules. Besides, you really, really don't want to use code that hasn't been vetted against the oldest version of the ABI it's intended to be ran against ANYHOW. The fact that Autopackage "works around it" is irrelevent, really- you shouldn't really be "working around it" in the first place. Better yet, Autopackage, as it currently exists, only helps out with someone making packages for x86 ON x86 machines and doesn't cope with a lot of the things one might encounter doing cross-compilation, AMD64 execution, etc. I know, I've recently tried to utilize some of their tech, currently it doesn't play nice in a cross-compile environment because it doesn't know how to cope with it. It doesn't really work nicely with AMD64 setups either- all the Autopackages I've tried to install on my Athlon64 machines kind of don't install; but a 32-bit version, copied from a 32-bit machine that had the selfsame package installed on, it works as intended.
Autopackage is nice, but it's not for all solution sets, nor does it fix all the problems for even desktop deployment like you make it out to do here. It's a dramatic improvement with things, but it's not the silver bullet for all these problems that you make it out to be.
...niether is glibc updates for Linux admins... When they are, they're handled, typically, in the manner a Windows update is... What they did, wasn't what would be in either world.
That if you consider that the decisions are representative for most large companies, then they'd have had issues with Windows. It's as if the admins deliberately chose the absolute wrong path for each Linux decision. I've made these points earlier, if you did the analogous things under Windows you'd end up with a mess much like the one the Linux admins ended up with- probably worse.
You simply don't replace glibc without vetting code- all of it in the system. An official update or the next version should (and typically does) have the bulk of this work done for you already. If they're saying that the revision control process wouldn't let them upgrade the version of the distribution, they already broke that because an update to glibc of the nature in question IS a version update for all intents and purposes.
The whole thing is flawed because the analogous insane decisions were NOT applied to the Windows side as well.
To play devil's advocate for a moment, how do we know you're past just "experienced" and on deep into the Wizard or Guru realm of administration or programming? (I know, I know, but he's going to flip that one out all the same... I'd be legitimately tarred with that brush in his response... >:-))
Realistically, though, you're right- I have issues with all of this. They picked distros that would most likely have issues with things. They picked rules that required a lot of patching on the Linux side, but only had the normal set of updates on the Windows side- a lot of patching that simply wasn't needed and didn't have an analog in the Windows world. They picked a stilted set of conditions that honestly would have mandated a distribution version update- in any shop for any OS you could name in the real world.
I have trouble buying into this- and it's to the point that I'm being forced to re-work my own stuff for my startup because I was referring to other papers by them; I can't trust the data here as far as I could pick the Doctor up and throw him, so everything from this consultancy firm is now suspect.
I have grave concerns as I'm reading the paper. If the 3rd party component needed an upgrade to a new glibc, you would never have done what these admins allegedly did in the paper. It would have been a red-flag on the component in question and if it was something critical to the application, it would be assumed that the official version of the OS that was supported by the components was SLES 9, not 8 because it didn't have support for that version of glibc. You don't hack something like this in a production system, ever- even if you've got the skills to pull something like it off. I've got the skills, but even I wouldn't do what was done. You'd do a migration to the next version- period. There's far, far too many things that can go wrong and you really need to vet everything once you do it. What your esteemed admins did was analogous to someone haxoring kernel.dll by patching it manually and then putting it into a production Windows machine. I honestly don't know of anyone in their right mind that would do that one- ever.
.so file (Currently libc.so.6 on modern Linux and *BSD distributions...). This interface can be safely used for many years at a time, in spite of varying version numbers and the expected behavior will be the same for an older and a newer version- so long as you're not stepping on a bug within the older version or a new feature offered by a later on version of the runtime.
.Net framework for everything and then proceeded to install pieceparts of the OS to get it there.
Another faintly disturbing thing in this paper is that it's assumed that it's Linux at fault, when in reality, it was the ancillary components' requirements and someone trying to bull their way through the "problem". There's several problems with this, but I can number a few key ones for you:
1) glibc's interface, the ABI, doesn't change all that much over time. Typically, it's linked
to at runtime through a sonamed link to the actual
2) Yes, you CAN get away with minor revision updates of glibc without problems, but typically, you need to vet all your compiled code for regression testing purposes. It really, really is like replacing kernel.dll on Windows. If it isn't provided as an update, you've got a lot of regression work ahead of you to ensure that fixes done to the library don't break other code (Typically not a problem, but you never can tell when someone mis-used something...)- this is NOT something that your rank-and-file sysadmin has any real business doing. It's NOT their job.
3) Either the component stepped on a bug, or they're using some new feature of the glibc layer. In either case, you can't bull your way into using it on something that doesn't have the needed support level. What your admins did was analogous to trying to make this work on NT4, only to find out that you need the
The study's flawed- that plain, that simple. You can defend it all you'd like, but it's got bad problems that everyone, myself included, have been pointing out and you've avoided answering several of the key points we've been making.
The Linux admins were artificially given much more to do and screw up than the Windows admins, if the verbiage in the paper is to be believed. They were mandated to patch much more than is realistic, etc. in a production shop. If you were to have to patch all the local exploits in everything Windows related, you'd be very busy, moreso than the Linux admins- but they only had to do the Windows critical updates as MS provided them. The Linux admins were off patching everything- even if it wasn't very relevent to the servers (i.e. if it's a properly set up server, they shouldn't be ABLE to exploit local exploit possibilities, etc...). Worse, they had the guys doing manual updates to a lot of stuff, even though it WASN'T needed.
The study's heavily stilted to favor Microsoft and Windows- either through ignorance or malice. It'd be your call on how it got there, but it DID get there all the same.
...upgrading something like kernel.dll under NT4, 2000, XP, etc. It's not something lightly undertaken on a running machine- especially a production machine. Typically, when something of that magnitude needs an update, it's a full system upgrade- doesn't matter if it's Windows, etc. What makes the author of the report think that this was even remotely a fair comparison in question.
And I'll be honest, I find it fishy to say the least that he seemed to need that specific version of glibc; pretty much all vendors that are in the FOSS world try to track deprecated interfaces, avoid making calls to "broken" apis on the machines in question, etc. Even with a security flaw present, unless the glibc actually is the root cause, they will go out of their way to code around problems in most cases instead of mandating a glibc update for customers- it's that big a deal. Better yet, it seems that the official version updates from SuSE DID address all of this, including dealing with a fix to glibc that changed the revision number. If it's on SuSE's update sets, it's been pretty much vetted unless you change something fundamental, like glibc, at which time, all bets are off- it'd be the same way with Windows if you figured out how to accomplish a swap out of kernel.dll, or similar. Currently, for all distributions in main use except for Slackware, a system of handling all dependency relationships and obtaining all the official updates, etc. online. This is a KNOWN feature of all those distributions, whether you're talking Yast, urpmi, apt-get, yum, up-2-date, etc. Given that this is the case, not a single admin that actually knows what he's doing would have ever done what you describe in the draft 13 version of the paper on page 31, where you list things like admins doing by-hand updates of glibc, etc. That's "where Angels fear to tread" territory and would only be attempted by people that either roll custom distributions for embedded use or similar (Myself, for example...)- which would not be your typical sysadmin and they'd not be doing something like that with a production or pre-production server because they know better. And this is just one of numerous flaws with the whole study. I'll try to get to more later.
While I won't label you as a shill for Microsoft (partly because you're brave enough to face the gauntlet on this site...), I will question your ability to frame in adequate tests that actually test something- because you failed to do anything useful here except give Microsoft precisely what they were looking for. The work you did as presented to the whole world is hopelessly flawed in a manner not unlike what Mindcraft did for Microsoft a while back. I'd not consider your firm a reliable source of input or information at this point- while I was going to use one of your other papers that was provided online for a reference item in one of the white papers I am working on for my company, I must now largely discard this and find other sources for the information as everything you've produced is suspect because of the egregious flaws in the paper we're discussing.
If people don't buy the titles, then they don't see further royalties as the studios won't press any more titles- $10/disc is pretty steep expenditures. If you do well, say like EA's stuff, it'll be okay. If you're a lesser publisher/studio, that'd be daunting. You could very well dump THOUSANDS on royalties up-front and see little of any return on an excellent but undersold (for whatever reasons...) game. It's a bloody balancing act and they know it.
I know better than this, and really, so do you if you thought about this just a little bit...
Developer costs have to be kept low so that people will produce for a given console in the first place- if you extract part of the costs of the console losses even slightly from the developers, they'll very probably skip the console in question and go to another one. It's as simple as that. As a developer, if I'm not going to see a return on a run that ends up producing at least a wash on sales, it's just not going to get done as I'm supposed to be in the business of making money. I have to pay per instance just to run on the damn thing so people can play my game. I have to pay for a developer station so I can test for deploy. I have to pay for a runtime engine or roll my own that'll run on it. And, so forth... All this adds up. The amount of money they "recoup" on developer fees alone is in the noise floor here. It doesn't do anything for their bottom line- it does, however, regulate who gets to provide games and the quality level though. It has to meet with Microsoft's final stamp of approval or it doesn't ship for X-Box/XB360 and you have to pony up some cash and pay a portion of your profits back to them to be able to run on it. That's a bar against any Joe Shmoe wannabe game developer from producing something for sale that makes their console(s) look bad.
Royalties is the only place they expect to really see a return on things at this point (No guarantees of production process improvements- and you'd better NOT be betting on that as that's counting chickens before they hatch...) so they need 13 titles to be sold per XB360 unit currently ever sold to begin see a profit. This means that in order to be profitable, they're going to have to stay the course for at least 2-3 years at minimum to start seeing profits on this mess.
Production process improvements come over time, typically somewhere between 1-3 years of production. Sometimes within 6 months, but usually it's 12-18 months into it that you start really seeing anything out of that. And that's if you've designed everything right. Sometimes you get a design that won't see benefits from production improvements for years. You can't bet on that sort of thing unless you've designed them in from the start and they're more due to volume than device improvements when you run that play. At $400+ per unit, any volume discounts will also be in the noise floor for some time to come as they're already seeing those discounts with what they're producing in the first place.
The numbers being high? Not really. These prices I'm seeing in the article are conservative, as in being close to what they're probably seeing in costs.
Sony tends to lose a little money on each console for the first 6 to 12 months of sales and then as production volumes and process improvements come into play, they start seeing a small profit on the consoles, even as the prices get cut through the lifespan of the console. They're willing to eat a little of their potential profits to get the box out into the market. Now, Microsoft's blowing money left and right by comparison.
$399 is NOT appealing. It's not even enticing. For that, you can get a decently decked out PC and rig it to the TV with pretty much the same results (Esp. in light of the recent stability woes the XB360 seems to be experiencing...). A lower price point would have been appealing- but they really don't want to shoulder over 2/3rds of the cost for the machines- they're shouldering probably half right now as it is. (The figures given are off- they're using the MS cost and the MSRP for the boxes, which typically accounts for anywhere from a 50-300% markup for retail profits to make it appealing to stock the things in the first place (You don't think Wal-Mart, Best Buy, etc. would stand up for stocking the things at their cost do you?)).
I see Sony coming in under that price point, if only slightly, just to turn the screws on Microsoft here.
Borrowing other rulings from other Jurisdictions tends to make for appeals getting granted- Judges don't like doing that and typically don't do that sort of thing. Now, you said that you've seen this thing in Texas- why didn't you quote some Texas Jurisprudence instead of out of state stuff. I'm sure there's been some suits out there like this in the past. You didn't because there's nothing as of yet in Texas that has been done the way you're talking to. No, I'm not a lawyer, but unless you've read the law and consulted WITH one (I've done this on a periodic basis in the past on things similar to this one...) how can you suppose anything without past proof? You can't.
To quote you, go blow smoke up someone's ass, as mine's full of yours.
Thank you for your sympathy. As it stands, I'm trying to reclaim that which is MINE to begin with- hence the tagline.
Actually, that all varies from state to state. And, in many cases, all the Judge gets to do is say, "Yeah, they have to pay that" or, "Yeah, but it's only X dollars in fines..." or, "No, they didn't do anything wrong...". The Judge is bound by what the LAW stipulates he can/can't do with regards to things like fines, etc. Each state has different laws and different applications thereof- just because Calif. has it one way, doesn't mean that Texas has it exactly the same way. All you did was point out jurisprudence in other states which isn't applicable to Texas Law. Unless you're a lawyer practicing in the State of Texas or have read up on various bits and bobs of Texas Law, you might want to refrain from discussing the subject as you honestly don't know how it works.