I am just saying that there are a number of ways Apple might have lost the case which wouldn't be a disaster for open source. The latter would require an exception large enough to drive a steam roller through, and it doesn't look like Psystar was doing any such thing, trivial modifications and all, aside from possibly not purchasing the required licenses in a handful of cases.
Copyright law allows you to tell people what they can do with _your_ software.
No, it doesn't. Copyright prohibits people from doing a number of things without authorization from the copyright holder. It has absolutely nothing with the ability to tell people what other things they may and may not do with copyrighted works.
Software license agreements have no power to expand the scope of copyright or declare that something is copyright infringement when the law states that it is not.
Distributing software that makes an adaptation to disable the Apple hardware check might be a violation of the DMCA in any case, all the more reason to rewrite the DMCA. It should have been written to prohibit devices that expedite illegal copyright infringement, rather than implying the ability for a manufacturer to enforce any restriction it can dream up, by force of law.
Region restrictions, for example. You buy a DVD in Europe, and it no longer plays when you return to the United States. Should a device that lets you play DVDs purchased in foreign countries really be against the law? Laws like that should be treated with the utmost contempt. The DMCA as written, is a perversion of the first order.
The ramifications of an Apple loss would have been disastrous to copyright in general as well as Open Source
Perhaps if Apple lost due to an extraordinary neglect of 17 USC 106, or an extraordinary expansion of fair use and that treatment was upheld on appeal.
If you read my comment carefully, you will notice that I in no way suggest doing anything that violated section 117(b). There is no "redistribution" at all.
Section 117 and 1201 are in conflict here. Section 117(a) specifically gives the end user or someone that they authorize to make adaptations necessary for the utilization of a protected work on a single machine.
Assuming that making such an adaptation would otherwise violate the DMCA (the wording is awfully vague) it isn't entirely clear whether doing something explicitly allowed by 117(a) would legally be prohibited or not. 117(a) states "it is not an infringement" after all.
There are several ways to avoid the restriction on reselling modified works. Generally speaking, you have to sell the work to the end user before any modification occurs. Once the user owns a copy of the software, you *can* legitimately make modifications on his or her behalf such that the copy can be utilized on a single machine. When the end user takes physical possession is irrelevant. cf. 17 USC 117(a).
So they say. In reality, a retail EULA is mostly an exercise in wishful thinking.
At least half of the courts that have addressed the question in the United States have held that retail end user license agreements are legal fictions, because the copy is indeed actually owned by the buyer, and as such a license to use that which you already own is unnecessary (and hence superfluous). See here, for example.
That is the point of "Psystar 2". What is to stop the owners from forming a new corporation, acquiring the operations of the original Psystar, and proceeding on a more cautious basis, with the legal ability to sell unmodified copies of Mac OS X?
I am the author of the original comment, and haven't the slightest idea why the poster here pretended that he was, and posted it again. That's just weird.
I am not suggesting you have to take down the database, but rather that you either shut down applications, or queries and/or updates block until the table modification (or some other unnecessarily competing transaction) is complete. That is a serious problem in some applications. It is those sort of limitations that practically put Ingres out of business.
In Oracle, if you want strict consistency for a report you do "SET TRANSACTION READ ONLY" and for the rest of the "transaction" you get a read only snapshot of the database. Otherwise you generally get statement level consistency. New queries see newly committed data.
The big advantage of MVCC is that it prevents writers from blocking readers. The big advantage of row level locking is that it prevents writers from unnecessarily blocking other writers. That goes doubly for DDL operations. In Oracle, for example, you can create and rebuild indexes while the indexed columns are being updated. If the index creation would other wise block transactions for several minutes, that is a major advantage.
RAC is the big one, the one that would take a *lot* of work to make something comparable to. In general though, most things fall into the category of quality and depth of implementation.
To take something simple, numeric (NUMBER) types have a much more efficient storage format in Oracle than PostgreSQL. Much faster the last time I benchmarked them as well. The efficiency is a significant problem for financial applications. That could probably be fixed relatively easily, but it would still be a matter of catching up to where Oracle was twenty years ago.
Another one is type compatibility. PostgreSQL historically has had *big* problems with treating various numeric types and integral types as equivalents of each other. Last time I evaluated it you had to use typecasts all over the place to make sure that indexes were used.
Last I checked PL/SQL was much faster than PL/PGsql. PostgreSQL doesn't automatically create updateable views yet. AFAIK, there is no way to make a view filter on some sort of session variable, so you can create virtual private databases.
Oracle has no end of other relatively exotic stuff that makes a difference to some healthy percentage of their customer base. We don't use five percent of it, but its there and it is the sort of thing that would take a significant amount of time and effort to duplicate, more due to breadth than depth in this case. More power to the folks who are closing the gap.
No one is suggesting dropping a column that is still in use. The software upgrade that makes the old column obsolete must usually complete first.
All transactions dependent on the old column must also complete (the wait for this is automatic). Then, either all sessions or all software state that depend on the previous column must go away, OR some form of (updatable) views be used to allow them to continue without early termination (using a column alias or derived column).
Once that happens, it is very convenient for access to the relevant table to continue while the old column is dropped and all its data is reclaimed. Oracle and PostgreSQL can both do this, although reclaiming the previously used space is a second step in the latter.
Online upgrades. Suppose you have a service that needs to be available on a 24 x 7 basis. Is there any reason to shut everything down just because the upgrade script needs to add a new column, drop an old one, or increase the precision or maximum length of an existing one?
We do software as a service, for example, and generally speaking, we don't take our site down *ever*, certainly not for application software updates. Logged in users stay logged in and continue their work without noticing.
I don't work for Oracle, and I would like to see other databases to get into the same league inf every material respect. Take Oracle RAC (formerly Oracle Parallel Server) for example, Oracle's shared everything database clustering technology. There are no open source equivalents. MS SQL, PostgreSQL, and MySQL don't have anything like it. Apparently IBM DB2 does, but only in the mainframe editions.
There are often things that can be done to work around these limitations (replication works in some cases, for example), it is just a question of cost effectiveness. There is no reason to buy Oracle just because it is "Oracle". Only if it does what you need better than the alternatives. For many businesses that is the case. Oracle doesn't dominate the business because of FUD. It dominates due to true technical superiority. A business would be positively stupid to pay a large premium for a database that doesn't have any real superiority to much less expensive (if not free) alternatives. That is one of the reasons why it would be great if the alternatives caught up. Transparent clustering for PostgreSQL would be outstanding.
I *can* use PostgreSQL to do everything I could with Oracle 7 back in the early 90s. That is saying something (MySQL doesn't come close). A lot of people don't need much of what Oracle has added since then. If that is the case, there is a great case to be made for using something else. It is certainly a lot less expensive.
I didn't say "features" (although there are those) but rather "better overall implementation".
For example, with Oracle you can add columns, drop columns, and modify columns while there are ongoing transactions against the table. Try that with DB2 sometime.
MySQL is worse:
In most cases, ALTER TABLE works by making a temporary copy of the original table. The alteration is performed on the copy, and then the original table is deleted and the new one is renamed
That is a trivial example. Generally speaking, however, Oracle gets significant new features with a high quality implementation about a decade before anyone else does. For example, during the 1990s the lack of MVCC and row level locking were serious problems with virtually every database except Oracle. Without them, you can't reliably run large or long running transactions without risking locking every other user out of the database, even if the transactions don't have any row level overlap.
The MySQL brand name and the installed (commercial) user base are pretty much the only reasons for Oracle to acquire the MySQL database business at all. Both worth paying a considerable amount of money for.
No one needs their database server to be called "MySQL" if they don't like the path that Oracle takes with it though. And it would be easy enough to write new (and perhaps better) documentation for a fork.
If MySQL does what you need, at a pain level you can afford, then more power to you. It is certainly a lot more cost effective in those cases. I didn't say anything about ruling out MySQL for any and all possible applications.
On the contrary, it is not a problem at all. MySQL can be forked and the people dependent on it can use the forked version indefinitely. The commercial users who want to stick with the evolution of "MyOracle" can pay for the privilege. Everyone is happy. The EC has no need to worry. A fork of MySQL could provide all the necessary competition, to say nothing of PostgreSQL.
I agree that Oracle's dominance and proprietary nature places it in a unique position to dictate terms to its customers. The problem is that Oracle is at least twenty years ahead of all of their competitors in database technology. Oracle 7, ca 1991, has a better overall implementation than the latest and greatest from IBM, Microsoft, PostgreSQL, MySQL, and so on. I mean MySQL is barely out of the 'toy' stage (special purpose applications excluded). In the intervening two decades Oracle has widened the gap. That means for a certain classes of OLTP applications, people tend to think you are suicidal if you recommend anything else.
The only way to minimize this problem is to bring (open source) databases closer to parity, even with where Oracle was twenty years ago. PostgreSQL is the only one that comes close in the open source world. MySQL started out with so many bizarre design decisions and gratuitous incompatibilities, that I wonder if it will *ever* come close, at least not without losing backward compatibility in a big way.
For various reasons, an SQL injection generally targets a specific application running on a specific database. Unless your database interface is seriously deficient, like MS SQL server, it is difficult to perform a successful SQL injection without knowing what the table structure is. And of course, most applications do not run on multiple database types.
Unless you have a driver that is seriously deficient, you can leave out the cfsqltype="cf_sql_varchar" part.
Many dynamic SQL interfaces are at least as verbose, due to the requirement to bind all the parameters. And good luck if you have to count question marks to get your parameter bindings in the right order, as in PHP, ODBC, JDBC etc.
Precompiler interfaces are the best, but who uses precompilers any more? Or you could just write as much as possible using stored procedures, but that has its own unique form of pain.
The "hockey team" is a name that scientists in favor of radical AGW theories have taken on, named after Michael Mann's (falsified) "hockey stick" temperature reconstruction.
Generally speaking, I think Nature is whistling past the graveyard. Legitimate climate science has either been set back or brought forward a decade, depending on your perspective.
Traditionally, the IT department refers to the people who administer and support the systems used by the main line of business. A company that develops software for resale, as part of some embedded system, or for some other primary line of business typically makes a distinction between the IT department and the software development / engineering departments.
Etymology aside, one of the reasons for the connotation of "IT" is that Information Technology majors are taught a completely different, business oriented curriculum than computer science and engineering majors are. Perhaps it would be nice to come up with a more accurate name, but for now that is the way it is.
And the stigma will naturally stick with "IT" to the degree that it naturally employs a number of people that have substandard levels of education compared to engineers and the like, even though the higher ranking members of the field (especially in large companies) often don't deserve it.
I am convinced that retail EULAs are invalid on their face, and there are a number of courts that agree. The reason why they are invalid is a license is not required to use a copy that you own.
If there was a binding contract (as engaged in for some types of enterprise software), that would be a different story. By the point you have left the store with a copy of retail software however, you own that copy. No further license is required. The only way to make a retail EULA valid would be for the retail store to act as the software manufacturer's agent and require informed consent (preferably signed) with regard to the proposition that the customer isn't purchasing anything as part of the checkout process.
And the only reliable way for that to happen would be to agree that the physical media itself remains the property of the software manufacturer and is only leased to the customer for a finite period (ten years perhaps). No first sale rights because there wouldn't be a sale.
Slashdot Mirror
I am just saying that there are a number of ways Apple might have lost the case which wouldn't be a disaster for open source. The latter would require an exception large enough to drive a steam roller through, and it doesn't look like Psystar was doing any such thing, trivial modifications and all, aside from possibly not purchasing the required licenses in a handful of cases.
Copyright law allows you to tell people what they can do with _your_ software.
No, it doesn't. Copyright prohibits people from doing a number of things without authorization from the copyright holder. It has absolutely nothing with the ability to tell people what other things they may and may not do with copyrighted works.
Software license agreements have no power to expand the scope of copyright or declare that something is copyright infringement when the law states that it is not.
Distributing software that makes an adaptation to disable the Apple hardware check might be a violation of the DMCA in any case, all the more reason to rewrite the DMCA. It should have been written to prohibit devices that expedite illegal copyright infringement, rather than implying the ability for a manufacturer to enforce any restriction it can dream up, by force of law.
Region restrictions, for example. You buy a DVD in Europe, and it no longer plays when you return to the United States. Should a device that lets you play DVDs purchased in foreign countries really be against the law? Laws like that should be treated with the utmost contempt. The DMCA as written, is a perversion of the first order.
The ramifications of an Apple loss would have been disastrous to copyright in general as well as Open Source
Perhaps if Apple lost due to an extraordinary neglect of 17 USC 106, or an extraordinary expansion of fair use and that treatment was upheld on appeal.
If you read my comment carefully, you will notice that I in no way suggest doing anything that violated section 117(b). There is no "redistribution" at all.
Section 117 and 1201 are in conflict here. Section 117(a) specifically gives the end user or someone that they authorize to make adaptations necessary for the utilization of a protected work on a single machine.
Assuming that making such an adaptation would otherwise violate the DMCA (the wording is awfully vague) it isn't entirely clear whether doing something explicitly allowed by 117(a) would legally be prohibited or not. 117(a) states "it is not an infringement" after all.
There are several ways to avoid the restriction on reselling modified works. Generally speaking, you have to sell the work to the end user before any modification occurs. Once the user owns a copy of the software, you *can* legitimately make modifications on his or her behalf such that the copy can be utilized on a single machine. When the end user takes physical possession is irrelevant. cf. 17 USC 117(a).
So they say. In reality, a retail EULA is mostly an exercise in wishful thinking.
At least half of the courts that have addressed the question in the United States have held that retail end user license agreements are legal fictions, because the copy is indeed actually owned by the buyer, and as such a license to use that which you already own is unnecessary (and hence superfluous). See here, for example.
That is the point of "Psystar 2". What is to stop the owners from forming a new corporation, acquiring the operations of the original Psystar, and proceeding on a more cautious basis, with the legal ability to sell unmodified copies of Mac OS X?
I am the author of the original comment, and haven't the slightest idea why the poster here pretended that he was, and posted it again. That's just weird.
I am not suggesting you have to take down the database, but rather that you either shut down applications, or queries and/or updates block until the table modification (or some other unnecessarily competing transaction) is complete. That is a serious problem in some applications. It is those sort of limitations that practically put Ingres out of business.
In Oracle, if you want strict consistency for a report you do "SET TRANSACTION READ ONLY" and for the rest of the "transaction" you get a read only snapshot of the database. Otherwise you generally get statement level consistency. New queries see newly committed data.
The big advantage of MVCC is that it prevents writers from blocking readers. The big advantage of row level locking is that it prevents writers from unnecessarily blocking other writers. That goes doubly for DDL operations. In Oracle, for example, you can create and rebuild indexes while the indexed columns are being updated. If the index creation would other wise block transactions for several minutes, that is a major advantage.
RAC is the big one, the one that would take a *lot* of work to make something comparable to. In general though, most things fall into the category of quality and depth of implementation.
To take something simple, numeric (NUMBER) types have a much more efficient storage format in Oracle than PostgreSQL. Much faster the last time I benchmarked them as well. The efficiency is a significant problem for financial applications. That could probably be fixed relatively easily, but it would still be a matter of catching up to where Oracle was twenty years ago.
Another one is type compatibility. PostgreSQL historically has had *big* problems with treating various numeric types and integral types as equivalents of each other. Last time I evaluated it you had to use typecasts all over the place to make sure that indexes were used.
Last I checked PL/SQL was much faster than PL/PGsql. PostgreSQL doesn't automatically create updateable views yet. AFAIK, there is no way to make a view filter on some sort of session variable, so you can create virtual private databases.
Oracle has no end of other relatively exotic stuff that makes a difference to some healthy percentage of their customer base. We don't use five percent of it, but its there and it is the sort of thing that would take a significant amount of time and effort to duplicate, more due to breadth than depth in this case. More power to the folks who are closing the gap.
No one is suggesting dropping a column that is still in use. The software upgrade that makes the old column obsolete must usually complete first.
All transactions dependent on the old column must also complete (the wait for this is automatic). Then, either all sessions or all software state that depend on the previous column must go away, OR some form of (updatable) views be used to allow them to continue without early termination (using a column alias or derived column).
Once that happens, it is very convenient for access to the relevant table to continue while the old column is dropped and all its data is reclaimed. Oracle and PostgreSQL can both do this, although reclaiming the previously used space is a second step in the latter.
Online upgrades. Suppose you have a service that needs to be available on a 24 x 7 basis. Is there any reason to shut everything down just because the upgrade script needs to add a new column, drop an old one, or increase the precision or maximum length of an existing one?
We do software as a service, for example, and generally speaking, we don't take our site down *ever*, certainly not for application software updates. Logged in users stay logged in and continue their work without noticing.
I don't work for Oracle, and I would like to see other databases to get into the same league inf every material respect. Take Oracle RAC (formerly Oracle Parallel Server) for example, Oracle's shared everything database clustering technology. There are no open source equivalents. MS SQL, PostgreSQL, and MySQL don't have anything like it. Apparently IBM DB2 does, but only in the mainframe editions.
There are often things that can be done to work around these limitations (replication works in some cases, for example), it is just a question of cost effectiveness. There is no reason to buy Oracle just because it is "Oracle". Only if it does what you need better than the alternatives. For many businesses that is the case. Oracle doesn't dominate the business because of FUD. It dominates due to true technical superiority. A business would be positively stupid to pay a large premium for a database that doesn't have any real superiority to much less expensive (if not free) alternatives. That is one of the reasons why it would be great if the alternatives caught up. Transparent clustering for PostgreSQL would be outstanding.
I *can* use PostgreSQL to do everything I could with Oracle 7 back in the early 90s. That is saying something (MySQL doesn't come close). A lot of people don't need much of what Oracle has added since then. If that is the case, there is a great case to be made for using something else. It is certainly a lot less expensive.
I didn't say "features" (although there are those) but rather "better overall implementation".
For example, with Oracle you can add columns, drop columns, and modify columns while there are ongoing transactions against the table. Try that with DB2 sometime.
MySQL is worse:
That is a trivial example. Generally speaking, however, Oracle gets significant new features with a high quality implementation about a decade before anyone else does. For example, during the 1990s the lack of MVCC and row level locking were serious problems with virtually every database except Oracle. Without them, you can't reliably run large or long running transactions without risking locking every other user out of the database, even if the transactions don't have any row level overlap.
The MySQL brand name and the installed (commercial) user base are pretty much the only reasons for Oracle to acquire the MySQL database business at all. Both worth paying a considerable amount of money for.
No one needs their database server to be called "MySQL" if they don't like the path that Oracle takes with it though. And it would be easy enough to write new (and perhaps better) documentation for a fork.
If MySQL does what you need, at a pain level you can afford, then more power to you. It is certainly a lot more cost effective in those cases. I didn't say anything about ruling out MySQL for any and all possible applications.
On the contrary, it is not a problem at all. MySQL can be forked and the people dependent on it can use the forked version indefinitely. The commercial users who want to stick with the evolution of "MyOracle" can pay for the privilege. Everyone is happy. The EC has no need to worry. A fork of MySQL could provide all the necessary competition, to say nothing of PostgreSQL.
I agree that Oracle's dominance and proprietary nature places it in a unique position to dictate terms to its customers. The problem is that Oracle is at least twenty years ahead of all of their competitors in database technology. Oracle 7, ca 1991, has a better overall implementation than the latest and greatest from IBM, Microsoft, PostgreSQL, MySQL, and so on. I mean MySQL is barely out of the 'toy' stage (special purpose applications excluded). In the intervening two decades Oracle has widened the gap. That means for a certain classes of OLTP applications, people tend to think you are suicidal if you recommend anything else.
The only way to minimize this problem is to bring (open source) databases closer to parity, even with where Oracle was twenty years ago. PostgreSQL is the only one that comes close in the open source world. MySQL started out with so many bizarre design decisions and gratuitous incompatibilities, that I wonder if it will *ever* come close, at least not without losing backward compatibility in a big way.
For various reasons, an SQL injection generally targets a specific application running on a specific database. Unless your database interface is seriously deficient, like MS SQL server, it is difficult to perform a successful SQL injection without knowing what the table structure is. And of course, most applications do not run on multiple database types.
Unless you have a driver that is seriously deficient, you can leave out the cfsqltype="cf_sql_varchar" part.
Many dynamic SQL interfaces are at least as verbose, due to the requirement to bind all the parameters. And good luck if you have to count question marks to get your parameter bindings in the right order, as in PHP, ODBC, JDBC etc.
Precompiler interfaces are the best, but who uses precompilers any more? Or you could just write as much as possible using stored procedures, but that has its own unique form of pain.
The "hockey team" is a name that scientists in favor of radical AGW theories have taken on, named after Michael Mann's (falsified) "hockey stick" temperature reconstruction.
Generally speaking, I think Nature is whistling past the graveyard. Legitimate climate science has either been set back or brought forward a decade, depending on your perspective.
Traditionally, the IT department refers to the people who administer and support the systems used by the main line of business. A company that develops software for resale, as part of some embedded system, or for some other primary line of business typically makes a distinction between the IT department and the software development / engineering departments.
Etymology aside, one of the reasons for the connotation of "IT" is that Information Technology majors are taught a completely different, business oriented curriculum than computer science and engineering majors are. Perhaps it would be nice to come up with a more accurate name, but for now that is the way it is.
And the stigma will naturally stick with "IT" to the degree that it naturally employs a number of people that have substandard levels of education compared to engineers and the like, even though the higher ranking members of the field (especially in large companies) often don't deserve it.
I am convinced that retail EULAs are invalid on their face, and there are a number of courts that agree. The reason why they are invalid is a license is not required to use a copy that you own.
If there was a binding contract (as engaged in for some types of enterprise software), that would be a different story. By the point you have left the store with a copy of retail software however, you own that copy. No further license is required. The only way to make a retail EULA valid would be for the retail store to act as the software manufacturer's agent and require informed consent (preferably signed) with regard to the proposition that the customer isn't purchasing anything as part of the checkout process.
And the only reliable way for that to happen would be to agree that the physical media itself remains the property of the software manufacturer and is only leased to the customer for a finite period (ten years perhaps). No first sale rights because there wouldn't be a sale.