For the sake of discussion, let's assume the case has merit. The Linux community will rewrite the improperly used code, redesigning it if need be, craft tools to migrate everyone over to it, and go on.
Trouble is, SCO appears to be doing everything they can to avoid giving out enough information to identify the allegedly infringing code. They don't want the infringing code taken out, they want it left in so they can then levy a charge on every Linux user. Giving out enough information to enable removal of infringing code would threaten that potential revenue stream, so they'll do everything they can to avoid it. They don't want the infringement to stop, they just want to make money on it.
This strikes me as a continuation of the cost-shifting that began when sufficient levels of copyright violation were made 'criminal'. The cost of prosecuting a civil case is borne by the plaintiff (i.e. the RIAA). The cost of prosecuting a criminal case is borne by the taxpayer. Hence the criminalisation of copyright violation caused the costs of prosecuting those violations to be shifted from the RIAA et al to the taxpayer.
This is the same type of thing. The RIAA et al faces fairly high costs in trying to deal with P2P networks. Putting the FBI in charge of policing P2P networks means the taxpayer will be funding those investigations instead of the RIAA.
There is a critical point here, carefully obfuscated by the RIAA and it's minions - there is no such thing as "Intellectual Property."
Exactly, which is why I increasingly prefer to use the term GGTM (Government-Granted Temporary Monopoly) over the deceptive term "Intellectual Property".
The fiction is that it isn't property at all... it's a time limited grant of monopoly, and it's meant to expire. Property is a durable item, not a lease.
Which is why increasingly I prefer the term GGTM (Government-Granted Temporary Monopoly) to the term 'Intellectual Property'.
Ben
I still don't understand why Microsoft calls their scheme "Software Assurance".
It's similar to real estate naming conventions: you always name a development for something that it doesn't have (e.g. if a development is named "Fair Oaks", there probably isn't an oak tree within 50 miles).
Ben
It's a law of USENET - transmogrified to discussion web sites - that anyone criticising the spelling or grammar of another poster will always make a spelling or grammar gaffe in that their very own post.
If you're just trying to state the law, yes. I'm pointing out that the questioned post is in fact an example of the law, which I then append.
It's a law of USENET, transmogrified to discussion web sites - anyone criticising the spelling or grammar of another poster will always make a spelling or grammar gaffe in that very post.
And taken with the Verizon ruling (and you KNOW the RIAA will cite it) all this means is that the only people they can go after are you, the USERS.
Which is what they ought to be doing anyhow. Far better that they go after individual users who are violating their copyrights than that they try to have possession of legitimate knowledge and technology restricted from everyone but themselves.
However, I'm not sure the suggestions are really the way forward. In particular, such research as I've seen (sorry, can't cite a link off the top of my head) suggested that actually, a small team of programmers was much more productive in their own open-plan-like "team space". There are several logical explanations for this, not least the fact that if you do get stuck with a mental block, help is just a question away. You also get interaction with conversations other members of the team have, and either learn something yourself or offer them a solution neither of them knew about but you did.
I have to wonder how much of that 'research' was commissioned by those selling 'open-plan' office furniture. Note that the information in the article is not at all new. Tom DeMarco was saying the same things back in 1987 in his excellent book "Peopleware". And back then he noted that those touting open-plan offices as productivity enhancements could offer no proof beyond 'proof by repeated assertion'.
Most programming tasks nowadays involve picking up some toolkit, an IDE, and an office chair, and then dragging icons around to combine parts of the toolkit into some working product. Visual Basic especially is a good example of this, but Java/.Net, plain old Windows GUI programming, Web scripting etc. are also way past the point where creativity matters. There are well-known solutions (f.ex. design patterns) for most problems, and CS students in today's colleges are only taught how to apply them. They are no more creative than assembly line workers.
Hogwash. I do development in one of those Windows GUI programming environments, Clarion, and have by no means found that the need for creativity has disappeared. It does mean that the application of creativity has moved to a higher conceptual level. I have higher-level tools, therefore I'm able to apply my experience and creativity at a higher (and more effective) level.
The existence of those tools may mean that those that unthinkingly drag around icons can manage to produce a program. It's doesn't mean that programs produced that way are going to be that effective or useful.
A recent report on spam by Reuters stated that Yugoslavia, in an attempt to bring in more revenue is "harboring" spammers through its new program in which the government sells mass emailing licenses to spammers. These licenses basically exempt these spammers from any kind of criminal prosecution.
That loud clicking you just heard is the sound of every Yugoslavia netblock permanently going into thousands of private mail block lists. Enjoy your intranet, Yugoslavia.
Most applications on the AS/400 are written in RPG which I bet most people would these days would not like to program in. I don't like it much either so I never bothered to learn it.
RPG is pretty awful, although given what you have to do to program in modern windowing systems, the aspect of having to fit what you want to do into RPG's fixed flow of control may well seem less onerous that it used to. I still remember the story of someplace running a small 360 with only RPG available who whipped up a version of the old text 'Star Trek' game using 5 RPG programs, so you can probably do more than you might expect if you're willing to bend your mind into the way RPG does things.
How long before Yahoo or Microsoft decide, in light of the anti-spam laws, to open their pipelines to spam companies for a cost. i.e. you may spam to Yahoo addresses for $500 a mailing, or whatever.
Shortly before Yahoo or Microsoft find that customers are deserting them in droves. People *will* change providers over the issue of getting too much spam, and if it's known the provider has a profit motive, and therefore no motive to stop the spam, people will leaves in droves.
"But we'll let them opt out!", you say. One spammer at at time, or will we let the customer have a "don't send me any of your paid spam" button? If the former, customers will still leave over the hassle of having to do all of the opt out. If the latter, it won't be long before enough customers have opted out that the spammer will object that he/she can't get enough coverage for the money.
While Carter's definitely going overboard with the level of punishment, I'd rather see the RIAA et al. going after individual GGTM[1]-violators than trying to get the government to lock down the technology.
[1] Government-Granted Temporary Monopoly. I refuse to use the term 'Intellectual Property', which implies ownership of ideas, etc. It's not property you can own, it's a temporary monopoly granted by the government.
I think most zealots are blind to the fact that Windows is a stable, unified platform that can be leveraged without fear of one's products becoming obsolete or broken with the next release of Gnome or KDE.
Instead, you have the fear that one's product will become obsolete or broken with the next release of Windows (or maybe even with the next Service Pack), or that Microsoft will kill your market by bundling a competing product with Windows, or by offering a competing product free for download, or that the tests you have to make to check out the various permutations of the supposedly 'stable, unified' Windows add enough complexity to your product to make it unconscionably buggy, or that the failure to test for enough of those permutations causes your product to fail on certain installations, resulting in loss of customers....shall I go on?
Actually, what disturbs me more than the potential bias against 'scripters' is the acceptance of a situation where the supposed 'programmer' faction are comfortable not knowing at least one 'scripting' language. Even if you're not using a 'scripting' language such as Perl for production code, it still comes in mighty handy for anciliary tasks while programming in your 'production' language. The typical 'production' language boils down, at some point, to plain text, and there will be situations where using the 'scripting' language to generate or manipulate code in your primary language will eliminate a lot of tedious and repetitious coding.
For example, in a situation where Clarion was the 'production' language, I found myself needing to read a file downloaded from an IBM mainframe. The file had variable-size records (not directly supported by Clarion), with no record-size bytes preceding the records, and the only machine-readable layout for the records was a COBOL copy-file. String fields needed to be converted from EBCDIC to ASCII, except that in some cases the REDEFINES verb was used to re-map parts of the record - in those cases, you can't just automatically do the conversion. COMP fields (16-byte integers) also needed to be byte-swapped. The record layout was large enough that I could have spent a couple or three weeks converting the COBOL layout to a Clarion layout by hand, and writing the code to do the EBCDIC/ASCII and byte-swap conversions. Instead I wrote a series of 3 Perl scripts that parsed the COBOL copy-file, produced the equivalent Clarion layout, wrote the conversion code for those fields which should always be converted, and documented those which might need to be conditionally converted. The result was a Clarion template, so that the code could be easily incorporated into the Clarion development environment.
Not only was this more efficient than hand-coding, it made dealing with the eventual changing of the format by the vendor much easier, as all that was necessary was to run the updated COBOL copy file through the Perl scripts to produce a new template. If I had done the layout by hand, dealing with an updated layout would have required wading through the COBOL copy files looking for changes, and then made the corresponding changes in the Clarion code, a much more tedious and error-prone activity.
It's not just a question of using the right tools for the right jobs, it's also a question of having your people know enough different tools to be able to recognize when something other than the primary tool is needed.
I note that Bruce Eckel (a book author and trainer for Java and C++) is suggesting that Java programmers also know Python, for much the same reasons.
What exactly do they have to gain from this? What do they lose by having more systems support their architecture? This makes zero sense.
Sounds to me a lot like another case of thinking solely in legal terms, and ignoring the likely affects of legal action on the marketplace. Kind of reminds of the SEA vs PKWare lawsuit. SEA won the legal case, but the online community's response to SEA's legal actions shortly turned ARC from the defacto standard archiving utility to an also-ran (when was the last time you had to deal with a.ARC file?).
The fact is, you may be throwing out 50 spam emails a day, but if you see a subject line that speaks to an immediate need, you're probably going to stop, read it, and consider a purchase.
Maybe. But I won't consider purchasing from the spammer. If, unlikely as it seems, I see a spammed product that I might want to buy, I'd go and find some other company selling the product who doesn't spam, and buy it from them.
What I'd really like to see is a provision that every time a patent is invalidated in court, the USPTO gets to foot the legal bill for the case. The only way I can see for the USPTO to develop some sanity is for the results of rubber-stamping patent applications to have a negative effect on them. Making them foot the legal bill for the eventual suit required just might do it.
Slashdot Mirror
Trouble is, SCO appears to be doing everything they can to avoid giving out enough information to identify the allegedly infringing code. They don't want the infringing code taken out, they want it left in so they can then levy a charge on every Linux user. Giving out enough information to enable removal of infringing code would threaten that potential revenue stream, so they'll do everything they can to avoid it. They don't want the infringement to stop, they just want to make money on it.
This strikes me as a continuation of the cost-shifting that began when sufficient levels of copyright violation were made 'criminal'. The cost of prosecuting a civil case is borne by the plaintiff (i.e. the RIAA). The cost of prosecuting a criminal case is borne by the taxpayer. Hence the criminalisation of copyright violation caused the costs of prosecuting those violations to be shifted from the RIAA et al to the taxpayer.
This is the same type of thing. The RIAA et al faces fairly high costs in trying to deal with P2P networks. Putting the FBI in charge of policing P2P networks means the taxpayer will be funding those investigations instead of the RIAA.
Exactly, which is why I increasingly prefer to use the term GGTM (Government-Granted Temporary Monopoly) over the deceptive term "Intellectual Property".
Which is why increasingly I prefer the term GGTM (Government-Granted Temporary Monopoly) to the term 'Intellectual Property'. Ben
Not here. The Info-Zip Zip, Unzip, and Wiz utilities are perfectly usable, and free, so there's no reason to pirate WinZip.
It's similar to real estate naming conventions: you always name a development for something that it doesn't have (e.g. if a development is named "Fair Oaks", there probably isn't an oak tree within 50 miles). Ben
Soon followed by the implementation of IPV6-based DNS blocking lists, of course.
If you're just trying to state the law, yes. I'm pointing out that the questioned post is in fact an example of the law, which I then append.
It's a law of USENET, transmogrified to discussion web sites - anyone criticising the spelling or grammar of another poster will always make a spelling or grammar gaffe in that very post.
Thank you, Mr Revere
Which is what they ought to be doing anyhow. Far better that they go after individual users who are violating their copyrights than that they try to have possession of legitimate knowledge and technology restricted from everyone but themselves.
They don't actually grow them that big in West Virginia
I have to wonder how much of that 'research' was commissioned by those selling 'open-plan' office furniture. Note that the information in the article is not at all new. Tom DeMarco was saying the same things back in 1987 in his excellent book "Peopleware". And back then he noted that those touting open-plan offices as productivity enhancements could offer no proof beyond 'proof by repeated assertion'.
Hogwash. I do development in one of those Windows GUI programming environments, Clarion, and have by no means found that the need for creativity has disappeared. It does mean that the application of creativity has moved to a higher conceptual level. I have higher-level tools, therefore I'm able to apply my experience and creativity at a higher (and more effective) level.
The existence of those tools may mean that those that unthinkingly drag around icons can manage to produce a program. It's doesn't mean that programs produced that way are going to be that effective or useful.
That loud clicking you just heard is the sound of every Yugoslavia netblock permanently going into thousands of private mail block lists. Enjoy your intranet, Yugoslavia.
RPG is pretty awful, although given what you have to do to program in modern windowing systems, the aspect of having to fit what you want to do into RPG's fixed flow of control may well seem less onerous that it used to. I still remember the story of someplace running a small 360 with only RPG available who whipped up a version of the old text 'Star Trek' game using 5 RPG programs, so you can probably do more than you might expect if you're willing to bend your mind into the way RPG does things.
Shortly before Yahoo or Microsoft find that customers are deserting them in droves. People *will* change providers over the issue of getting too much spam, and if it's known the provider has a profit motive, and therefore no motive to stop the spam, people will leaves in droves.
"But we'll let them opt out!", you say. One spammer at at time, or will we let the customer have a "don't send me any of your paid spam" button? If the former, customers will still leave over the hassle of having to do all of the opt out. If the latter, it won't be long before enough customers have opted out that the spammer will object that he/she can't get enough coverage for the money.
While Carter's definitely going overboard with the level of punishment, I'd rather see the RIAA et al. going after individual GGTM[1]-violators than trying to get the government to lock down the technology.
[1] Government-Granted Temporary Monopoly. I refuse to use the term 'Intellectual Property', which implies ownership of ideas, etc. It's not property you can own, it's a temporary monopoly granted by the government.
Then why single out KDE and GNOME for it in the first place, and act as though Windows is so much better?
Instead, you have the fear that one's product will become obsolete or broken with the next release of Windows (or maybe even with the next Service Pack), or that Microsoft will kill your market by bundling a competing product with Windows, or by offering a competing product free for download, or that the tests you have to make to check out the various permutations of the supposedly 'stable, unified' Windows add enough complexity to your product to make it unconscionably buggy, or that the failure to test for enough of those permutations causes your product to fail on certain installations, resulting in loss of customers....shall I go on?
Actually, what disturbs me more than the potential bias against 'scripters' is the acceptance of a situation where the supposed 'programmer' faction are comfortable not knowing at least one 'scripting' language. Even if you're not using a 'scripting' language such as Perl for production code, it still comes in mighty handy for anciliary tasks while programming in your 'production' language. The typical 'production' language boils down, at some point, to plain text, and there will be situations where using the 'scripting' language to generate or manipulate code in your primary language will eliminate a lot of tedious and repetitious coding.
For example, in a situation where Clarion was the 'production' language, I found myself needing to read a file downloaded from an IBM mainframe. The file had variable-size records (not directly supported by Clarion), with no record-size bytes preceding the records, and the only machine-readable layout for the records was a COBOL copy-file. String fields needed to be converted from EBCDIC to ASCII, except that in some cases the REDEFINES verb was used to re-map parts of the record - in those cases, you can't just automatically do the conversion. COMP fields (16-byte integers) also needed to be byte-swapped. The record layout was large enough that I could have spent a couple or three weeks converting the COBOL layout to a Clarion layout by hand, and writing the code to do the EBCDIC/ASCII and byte-swap conversions. Instead I wrote a series of 3 Perl scripts that parsed the COBOL copy-file, produced the equivalent Clarion layout, wrote the conversion code for those fields which should always be converted, and documented those which might need to be conditionally converted. The result was a Clarion template, so that the code could be easily incorporated into the Clarion development environment.
Not only was this more efficient than hand-coding, it made dealing with the eventual changing of the format by the vendor much easier, as all that was necessary was to run the updated COBOL copy file through the Perl scripts to produce a new template. If I had done the layout by hand, dealing with an updated layout would have required wading through the COBOL copy files looking for changes, and then made the corresponding changes in the Clarion code, a much more tedious and error-prone activity.
It's not just a question of using the right tools for the right jobs, it's also a question of having your people know enough different tools to be able to recognize when something other than the primary tool is needed.
I note that Bruce Eckel (a book author and trainer for Java and C++) is suggesting that Java programmers also know Python, for much the same reasons.
Sounds to me a lot like another case of thinking solely in legal terms, and ignoring the likely affects of legal action on the marketplace. Kind of reminds of the SEA vs PKWare lawsuit. SEA won the legal case, but the online community's response to SEA's legal actions shortly turned ARC from the defacto standard archiving utility to an also-ran (when was the last time you had to deal with a .ARC file?).
Maybe. But I won't consider purchasing from the spammer. If, unlikely as it seems, I see a spammed product that I might want to buy, I'd go and find some other company selling the product who doesn't spam, and buy it from them.
What I'd really like to see is a provision that every time a patent is invalidated in court, the USPTO gets to foot the legal bill for the case. The only way I can see for the USPTO to develop some sanity is for the results of rubber-stamping patent applications to have a negative effect on them. Making them foot the legal bill for the eventual suit required just might do it.