Why would GNU be illegal? GNU is a software movement, not a license.
The General Protection License (GPL) would be enforceable because it explicitly does not restrict how a user can use the software -- it only restricts how a user can redistribute the software. The GPL (at least through v2) is not a EULA; it is a redistribution license, based on copyright law rather than on the applicability of contract law to software sales.
The only hold that shrink-wrap or click-through licenses have at all is because customers read them. Courts have not (so far) cared that customers skim or skip the license agreement; they have said that since the customer makes a particular action (opening the sealed package with EULA printed outside, or clicking "I agree" beneath the EULA text box), the customer agrees to the license.
For a shrink wrap license, you cannot agree without opening the external box. For a click through license, you cannot agree without running software from the install media. Many retailers have policies against you returning software after doing the first. Many software manufacturers will say that only pirates want to return software after doing the second. It is this intermediate stage -- you can neither move forward nor back -- that is being challenged by the lawsuit.
Companies could post EULAs on their web sites, but this does not mean the customer has read or agrees with them. If the retail store does not allow the customer to return opened software, they have a responsibility to ensure that the customer reads and agrees to the license at the point of "sale" -- or else they become vulnerable to this kind of lawsuit. You can imagine how long it would take for Best Buy to rethink a policy that meant any customer, making a routine purchase, can tie up a register for 5 or 10 minutes:)
It frustrates me how web services are often described as revolutionary, when built on technologies such as UDDI and WDSL which in turn are based on relatively mature technologies such as XML and HTTP.
Indeed, the only maturity in XML is relative. W3C keeps coming up with new standards on how you should define and process XML dialects. The XML standard as a whole is only five years old as of today (see W3C's site).
XML processing standards such as XSL, XSLT, XPath, XQuery, XPointer, XML Schema, SOAP/XML-RPC (getting confused yet? X marks the spot!) are still warm from the oven and they are being revised and replaced already.
Even given all that, XML is not much more than the latest fad for data processing: it is comparable to ASN.1 and SGML from the late 1980s and early 1990s, with its only saving graces being that the standards are free to download and use, yet partially endorsed by Microsoft. There is little indication that XML will prosper after the next big revolution in computing -- indeed, looking at previous "revolutions," a common theme is making it easier to use and/or develop applications on computers. XML so far fails this test. Stacking more and higher layers of data processing standards is not a revolution at all.
"Who has an estimate on how long it will take for the Army to outfit its troops with anti-personnel rocket launchers?" Those have been around for quite a while.
Which part of anti-personnel did Michael not understand, that led him to link to an anti-armor rocket?
Quake and cousins would be so much more boring if you could only use the rocket launcher against enemy vehicles -- there are a lot fewer of those than enemy troops:)
You think it is a laugh. People who spend 10 or 20 hours a week (of their spare time, more often than not) tracking down these viruses and the criminals behind them probably disagree.
One of the largest IRC networks was recently humbled by attacks from worm-infected computers. Every other large IRC network deals with several new infections each week. It is only because the script kiddies (mostly) restrain their attacks to IRC, and because IRC admins go to great lengths to fight the worms, that more damage is not done by infected computers.
IRC networks are particularly easy targets, since each server is usually run by separate person or company, and the FBI is not interested in investigating cases unless $5,000 of damages can be claimed by one group -- never mind if there are one or two thousand infected computers that could be wiped out by a malicious kiddie. If the criminals get better at hiding their tracks or their commands, they may become more brazen and attack bigger targets.
Personally, I am glad that somebody in law enforcement is taking active steps to investigate and shut down these worms. They can actually punish the criminals behind the attacks. Private parties can, at most, disperse the botnet or terminate the attacker's account.
I am not sure why you suggest that allowing 10 digit dialing for local calls breaks 11 digit dialing for embedded devices. It is a human interface thing. Embedded device designers need not be constrained to use only what end users find useful.
But really -- how often do you move a burglar alarm or elevator to a different region of the country?
That is absolutely horrible (dialing 1+ten digits because people are "used" to it or because equipment does not know how to handle ten digits).
In addition to confusing people who come from sane areas of the country, how is one supposed to know if a given call will trigger toll or long distance charges? Everywhere else I know of has 1+seven (or ten, in multiple-area-code areas) digits for toll calls and 1+ten for long distance.
When you sue someone, you are generally not limited to recovering actual damages. You can sue for punitive damages as well, to deter the defendant (and others like him) from repeating his actions in the future -- which would require further intervention of the legal system.
Depending on how much time and effort (and legal bills) GIE has invested to keep him off their forums, and how much damage their reputation has lost because of the trolls on their forums, I can believe $5000 is the actual damages. An organization I work with has persistent trolls, and we spend a huge amount of time to remove them when they act up.
I wonder, though, if GIE has talked to the guy's ISP(s) and reported him for abuse. In my experience, that is much more effective than trying to unmask and sue someone over the Internet.
Yes, let us think. In addition to the good points made by limekiller4, the following things make online attacks considerably more dangerous than plain theft or vandalism:
Trojans and worms spread to hundreds or thousands of machines. These must be cleaned identified and cleaned up, at considerable expense of time.
Sustained or repeated DDoS attacks affect not only the target site, but many other sites at the same data center or ISP.
It takes much more time to prepare a case against someone who you can only identify by typing (rather than a witness) -- for example, a wiretap warrant may be necessary.
Common targets of DDoS (specifically, IRC networks) have little legal leverage to complain; most of their servers and bandwidth are donated by different entities, so there is no real loss associated with being attacked. Infected users might file charges of computer trespass, except they do not know, do not care, or both -- and ISPs would never disclose a subscriber's identity to someone being attacked by that subscriber's computer.
You can complain that those are technical problems that should be resolved by technical means -- but I personally would prefer stronger penalties for people who are caught (commensurate with the costs of identifying and prosecuting them) than having arbitrary strangers able to identify me at will over the Internet.
The blurbs imply ("The fire department has given up every hope on protecting the server area") that the fire originated elsewhere and spread -- fire supression systems are good for fires that start in server rooms, but if somebody puts tinfoil in the microwave next door, the fire may be just too big by the time it gets to the server room.
If you can harness an ever-increasing fraction of the Internet to do your code cracking for you, it's practical to do better than Moore. Not otherwise.
Most "bad guys" (whether they are government, corporate, or whatever) cannot afford to double the number of computers they buy every 18 months -- which is what you need to keep that 260 day doubling. The numbers of computers putting time into distributed projects like this only strengthen claims that it is hard to break the encryption.
The Internet isn't magic dust you can sprinkle on code breaking to make it magically go faster. Why do you act like it is?
261 days to double is below Moore's Law? I'm sure Gordon Moore would like to hear this. The usual expression is that semiconductor (whatever) doubles every 18 months. If you say speed doubles every 18 months, that's about 540 days -- comfortably LONGER than 261 days.
1000+ bit keys (or larger) are mandatory for secure large-prime public key systems now, but they are overkill for elliptic curves. Adding one bit to an ECC key gives relatively more strength than adding one bit to an RSA key does; that 109 bit ECC problem is already roughly comparable to factoring a 512 to 640 bit product of large primes.
In my experience (which is based on using RedHat and Debian), distributions let users report bugs for any package at the site because it is easier for users, and it lets them respond to problems that are due to distribution-specific changes.
The package maintainers will look at the bug and figure out if it is specific to the distro. If it is, they respond directly. If it is not, they forward the report (or fix) upstream. Reporting the bug to your distributor lets them know that someone has seen the bug and it has been a problem for at least one of their users.
This should not stop you from submitting bugs directly upstream -- usually the package maintainer will follow the bug reports for the package, and if you mention the relevant distribution in the bug, they notice it -- but there is usually no great benefit to doing so.
At least for Debian, open bug reports also let the distribution track which packages need particular help and whether the package has been abandoned in a bad state. I assume RedHat uses a similar mechanism.
That is a fine plan -- assuming you can find their MAC address. I certainly hope the server-side software is not lame enough to advertise it to all users. Many do not even show clients' IP addresses. "Vanilla" TCP/IP does not have any way to give away the lower-level addresses past the first IP router; this includes the MAC address of some guy with whom you have a TCP session.
In my mind, I would think that companies who are completely compliant who are targeted by the BSA would be happy about it.
That totally ignores the disruption, effort, and other impact that such an "audit" (sometimes just a jackbooted search without any warrant) has on the company. When you come down to all the commercially licensed software that is used at the "average" company, it becomes an enormous hassle for the IT staff to:
Figure out who is using what
Produce the proofs of purchase or whatever else is necessary
Convince the auditors that there is no additional commercial software being used
The payware mafia are proud of saying that most audits are based on tipoffs from disgrunted ex-employees -- which scares most companies because, no matter how hard they try, they will have some disgruntled ex-employees. It doesn't have to be a tip based on fact, it just has to be believable enough to warrant an audit.
Just don't say "they were never copyrighted" because that's just not true.
Please research your rants before issuing them. The law changed so that works published after 1978 do have automatic copyright. Works published before 1978 entered the public domain unless the author or creator registered them. See this page on BitLaw.
Since 1978, copyright is automatic for new works. Works published before then but not explicitly copyrighted entered the public domain, and remained in the public domain after the law changed. See BitLaw's discussion of the topic.
This is in contrast to trademark, for which you must always file to get legal protection.
Re:At the risk of being modded redundant. . .
on
Passport vs. Plan 9
·
· Score: 2, Interesting
"Single sign-on" does not mean you have to trust some third party with all your records, or that you cannot have a fallback.
To solve the first, keep your authentication cookies on your machine (or other secure hardware local to your person). Just pick a single sign-on solution that allows you to use that. You only need to worry about making it secure from interlopers.
To solve the second, your bank/insurance company/email provider/etc can reissue you an authentication cookie once you prove to them through some other trusted mechanism (say, showing up in person, or answering hard-to-research personal questions over the phone).
("Authentication cookie" could be a password, asymmetric key pair, or whatever.)
I'm not sure what verb you wanted in the middle of "the government should everyone run", so I'll skip that. IT departments can choose to use whatever software they want to support. Users can use what is supported, or (assuming they have a license) other software. The open file formats mean that one person using not-institutionally-supported software does not put that person out of the productivity loop.
The IT department could even say to employees "You *must* use software package X here." Sincere Choice has no objection to that. It only objects to "You *must* use software package X because our customers/friends/etc use X."
Don't conflate two distinct issues just to have a strawman you can whine about.
I did some GUI and integration work for an earlier version of the same technology (the DIPLOMAT project at CMU's LTI). It uses a multi-engine translation approach; some translation is done by looking up whole (simple) sentences, some by pure dictionary lookup, some by morphology (un-declining nouns and un-conjugating verbs, basically). Once all of those are done, it runs the output through a Markov model to figure out which "looks" the best (in comparison with human-generated text in the target language). It doesn't always generate perfect output, but it's generally easy to understand.
In the "owned by" column, how do you know what the Table C "owned by" column refers to? It may be an A, it may be a B. Enforcing consistency (cascading deletes or updates of the owner) must also be done by business logic instead of using the normal SQL support for such things.
Contrary to your assumption, some database have more than one front-end. For such databases, good design dictates that business logic is kept in one place, and does not have to be replicated to every front-end or batch processing script for the back end. As I said in my original post, that could be in a layer sitting in front of a SQL database, or it could be enforced by the database itself. If it is well-integrated with the database, it allows for additional optimizations.
But I digress: The original poster asked for limitations of SQL. I pointed out several limitations. Your reply is essentially "But your assumptions are wrong if you are using SQL!" -- and that is entirely the point. Using SQL as the only interface to the database prevents the user from making certain reasonable assumptions.
In my first example, take "owning" to be whatever you mean: the hierarchical structure of a document, organization of a company or device, and so forth. Many real-world relationships have the required trait (having the same relation between distinct tuples of types).
A related case is when the hierarchy is so rigid that a general SELECT from the whole table is less efficient than the search needs to be: for example, an IRC chat channel has many bans. Bans cannot be moved between channels, and there are many more channels than there are bans per channel, so it is inefficient to do "SELECT * FROM bans WHERE channel_id=(whatever)".
But the original poster asked for limitations of SQL. For what it tries to do, as I said, it does a very good job. And as you implied, making it do everything would be an awkward thing to try. My entire comment was intended to address the limitations of the language and not whether SQL could somehow be "more SQLish."
What third-party software did you add to PostgreSQL to make it do that? The core distribution does not support it, and there is no replication solution that is particularly blessed by the PostgreSQL core developers.
While it is possible to add layers to support replication of a database, until the replication is provided or endorsed by the main distribution, it can hardly be said to be supported by PostgreSQL itself.
Slashdot Mirror
Why would GNU be illegal? GNU is a software movement, not a license.
The General Protection License (GPL) would be enforceable because it explicitly does not restrict how a user can use the software -- it only restricts how a user can redistribute the software. The GPL (at least through v2) is not a EULA; it is a redistribution license, based on copyright law rather than on the applicability of contract law to software sales.
The only hold that shrink-wrap or click-through licenses have at all is because customers read them. Courts have not (so far) cared that customers skim or skip the license agreement; they have said that since the customer makes a particular action (opening the sealed package with EULA printed outside, or clicking "I agree" beneath the EULA text box), the customer agrees to the license.
For a shrink wrap license, you cannot agree without opening the external box. For a click through license, you cannot agree without running software from the install media. Many retailers have policies against you returning software after doing the first. Many software manufacturers will say that only pirates want to return software after doing the second. It is this intermediate stage -- you can neither move forward nor back -- that is being challenged by the lawsuit.
Companies could post EULAs on their web sites, but this does not mean the customer has read or agrees with them. If the retail store does not allow the customer to return opened software, they have a responsibility to ensure that the customer reads and agrees to the license at the point of "sale" -- or else they become vulnerable to this kind of lawsuit. You can imagine how long it would take for Best Buy to rethink a policy that meant any customer, making a routine purchase, can tie up a register for 5 or 10 minutes :)
Indeed, the only maturity in XML is relative. W3C keeps coming up with new standards on how you should define and process XML dialects. The XML standard as a whole is only five years old as of today (see W3C's site).
XML processing standards such as XSL, XSLT, XPath, XQuery, XPointer, XML Schema, SOAP/XML-RPC (getting confused yet? X marks the spot!) are still warm from the oven and they are being revised and replaced already.
Even given all that, XML is not much more than the latest fad for data processing: it is comparable to ASN.1 and SGML from the late 1980s and early 1990s, with its only saving graces being that the standards are free to download and use, yet partially endorsed by Microsoft. There is little indication that XML will prosper after the next big revolution in computing -- indeed, looking at previous "revolutions," a common theme is making it easier to use and/or develop applications on computers. XML so far fails this test. Stacking more and higher layers of data processing standards is not a revolution at all.
Quake and cousins would be so much more boring if you could only use the rocket launcher against enemy vehicles -- there are a lot fewer of those than enemy troops :)
You think it is a laugh. People who spend 10 or 20 hours a week (of their spare time, more often than not) tracking down these viruses and the criminals behind them probably disagree.
One of the largest IRC networks was recently humbled by attacks from worm-infected computers. Every other large IRC network deals with several new infections each week. It is only because the script kiddies (mostly) restrain their attacks to IRC, and because IRC admins go to great lengths to fight the worms, that more damage is not done by infected computers.
IRC networks are particularly easy targets, since each server is usually run by separate person or company, and the FBI is not interested in investigating cases unless $5,000 of damages can be claimed by one group -- never mind if there are one or two thousand infected computers that could be wiped out by a malicious kiddie. If the criminals get better at hiding their tracks or their commands, they may become more brazen and attack bigger targets.
Personally, I am glad that somebody in law enforcement is taking active steps to investigate and shut down these worms. They can actually punish the criminals behind the attacks. Private parties can, at most, disperse the botnet or terminate the attacker's account.
I am not sure why you suggest that allowing 10 digit dialing for local calls breaks 11 digit dialing for embedded devices. It is a human interface thing. Embedded device designers need not be constrained to use only what end users find useful.
But really -- how often do you move a burglar alarm or elevator to a different region of the country?
That is absolutely horrible (dialing 1+ten digits because people are "used" to it or because equipment does not know how to handle ten digits).
In addition to confusing people who come from sane areas of the country, how is one supposed to know if a given call will trigger toll or long distance charges? Everywhere else I know of has 1+seven (or ten, in multiple-area-code areas) digits for toll calls and 1+ten for long distance.
When you sue someone, you are generally not limited to recovering actual damages. You can sue for punitive damages as well, to deter the defendant (and others like him) from repeating his actions in the future -- which would require further intervention of the legal system.
Depending on how much time and effort (and legal bills) GIE has invested to keep him off their forums, and how much damage their reputation has lost because of the trolls on their forums, I can believe $5000 is the actual damages. An organization I work with has persistent trolls, and we spend a huge amount of time to remove them when they act up.
I wonder, though, if GIE has talked to the guy's ISP(s) and reported him for abuse. In my experience, that is much more effective than trying to unmask and sue someone over the Internet.
Yes, let us think. In addition to the good points made by limekiller4, the following things make online attacks considerably more dangerous than plain theft or vandalism:
You can complain that those are technical problems that should be resolved by technical means -- but I personally would prefer stronger penalties for people who are caught (commensurate with the costs of identifying and prosecuting them) than having arbitrary strangers able to identify me at will over the Internet.
The blurbs imply ("The fire department has given up every hope on protecting the server area") that the fire originated elsewhere and spread -- fire supression systems are good for fires that start in server rooms, but if somebody puts tinfoil in the microwave next door, the fire may be just too big by the time it gets to the server room.
If you can harness an ever-increasing fraction of the Internet to do your code cracking for you, it's practical to do better than Moore. Not otherwise.
Most "bad guys" (whether they are government, corporate, or whatever) cannot afford to double the number of computers they buy every 18 months -- which is what you need to keep that 260 day doubling. The numbers of computers putting time into distributed projects like this only strengthen claims that it is hard to break the encryption.
The Internet isn't magic dust you can sprinkle on code breaking to make it magically go faster. Why do you act like it is?
261 days to double is below Moore's Law? I'm sure Gordon Moore would like to hear this. The usual expression is that semiconductor (whatever) doubles every 18 months. If you say speed doubles every 18 months, that's about 540 days -- comfortably LONGER than 261 days.
1000+ bit keys (or larger) are mandatory for secure large-prime public key systems now, but they are overkill for elliptic curves. Adding one bit to an ECC key gives relatively more strength than adding one bit to an RSA key does; that 109 bit ECC problem is already roughly comparable to factoring a 512 to 640 bit product of large primes.
But thanks for playing anyway.
In my experience (which is based on using RedHat and Debian), distributions let users report bugs for any package at the site because it is easier for users, and it lets them respond to problems that are due to distribution-specific changes.
The package maintainers will look at the bug and figure out if it is specific to the distro. If it is, they respond directly. If it is not, they forward the report (or fix) upstream. Reporting the bug to your distributor lets them know that someone has seen the bug and it has been a problem for at least one of their users.
This should not stop you from submitting bugs directly upstream -- usually the package maintainer will follow the bug reports for the package, and if you mention the relevant distribution in the bug, they notice it -- but there is usually no great benefit to doing so.
At least for Debian, open bug reports also let the distribution track which packages need particular help and whether the package has been abandoned in a bad state. I assume RedHat uses a similar mechanism.
That is a fine plan -- assuming you can find their MAC address. I certainly hope the server-side software is not lame enough to advertise it to all users. Many do not even show clients' IP addresses. "Vanilla" TCP/IP does not have any way to give away the lower-level addresses past the first IP router; this includes the MAC address of some guy with whom you have a TCP session.
That totally ignores the disruption, effort, and other impact that such an "audit" (sometimes just a jackbooted search without any warrant) has on the company. When you come down to all the commercially licensed software that is used at the "average" company, it becomes an enormous hassle for the IT staff to:
- Figure out who is using what
- Produce the proofs of purchase or whatever else is necessary
- Convince the auditors that there is no additional commercial software being used
The payware mafia are proud of saying that most audits are based on tipoffs from disgrunted ex-employees -- which scares most companies because, no matter how hard they try, they will have some disgruntled ex-employees. It doesn't have to be a tip based on fact, it just has to be believable enough to warrant an audit.Please research your rants before issuing them. The law changed so that works published after 1978 do have automatic copyright. Works published before 1978 entered the public domain unless the author or creator registered them. See this page on BitLaw.
This is in contrast to trademark, for which you must always file to get legal protection.
"Single sign-on" does not mean you have to trust some third party with all your records, or that you cannot have a fallback.
To solve the first, keep your authentication cookies on your machine (or other secure hardware local to your person). Just pick a single sign-on solution that allows you to use that. You only need to worry about making it secure from interlopers.
To solve the second, your bank/insurance company/email provider/etc can reissue you an authentication cookie once you prove to them through some other trusted mechanism (say, showing up in person, or answering hard-to-research personal questions over the phone).
("Authentication cookie" could be a password, asymmetric key pair, or whatever.)
I'm not sure what verb you wanted in the middle of "the government should everyone run", so I'll skip that. IT departments can choose to use whatever software they want to support. Users can use what is supported, or (assuming they have a license) other software. The open file formats mean that one person using not-institutionally-supported software does not put that person out of the productivity loop.
The IT department could even say to employees "You *must* use software package X here." Sincere Choice has no objection to that. It only objects to "You *must* use software package X because our customers/friends/etc use X."
Don't conflate two distinct issues just to have a strawman you can whine about.
I did some GUI and integration work for an earlier version of the same technology (the DIPLOMAT project at CMU's LTI). It uses a multi-engine translation approach; some translation is done by looking up whole (simple) sentences, some by pure dictionary lookup, some by morphology (un-declining nouns and un-conjugating verbs, basically). Once all of those are done, it runs the output through a Markov model to figure out which "looks" the best (in comparison with human-generated text in the target language). It doesn't always generate perfect output, but it's generally easy to understand.
In the "owned by" column, how do you know what the Table C "owned by" column refers to? It may be an A, it may be a B. Enforcing consistency (cascading deletes or updates of the owner) must also be done by business logic instead of using the normal SQL support for such things.
Contrary to your assumption, some database have more than one front-end. For such databases, good design dictates that business logic is kept in one place, and does not have to be replicated to every front-end or batch processing script for the back end. As I said in my original post, that could be in a layer sitting in front of a SQL database, or it could be enforced by the database itself. If it is well-integrated with the database, it allows for additional optimizations.
But I digress: The original poster asked for limitations of SQL. I pointed out several limitations. Your reply is essentially "But your assumptions are wrong if you are using SQL!" -- and that is entirely the point. Using SQL as the only interface to the database prevents the user from making certain reasonable assumptions.
In my first example, take "owning" to be whatever you mean: the hierarchical structure of a document, organization of a company or device, and so forth. Many real-world relationships have the required trait (having the same relation between distinct tuples of types). A related case is when the hierarchy is so rigid that a general SELECT from the whole table is less efficient than the search needs to be: for example, an IRC chat channel has many bans. Bans cannot be moved between channels, and there are many more channels than there are bans per channel, so it is inefficient to do "SELECT * FROM bans WHERE channel_id=(whatever)". But the original poster asked for limitations of SQL. For what it tries to do, as I said, it does a very good job. And as you implied, making it do everything would be an awkward thing to try. My entire comment was intended to address the limitations of the language and not whether SQL could somehow be "more SQLish."
What third-party software did you add to PostgreSQL to make it do that? The core distribution does not support it, and there is no replication solution that is particularly blessed by the PostgreSQL core developers.
While it is possible to add layers to support replication of a database, until the replication is provided or endorsed by the main distribution, it can hardly be said to be supported by PostgreSQL itself.