SQL Server - patents problem for developers
-
http://news.com.com/2100-1001-985359.html?tag=fd_top[^] What are peoples thoughts on this? It says SQL server 7, so is SQL server 2000 okay? Quote from a clever bloke : "I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones." - Albert Einstein
I'm guessing this could affect MSDE users too?
-
-
http://news.com.com/2100-1001-985359.html?tag=fd_top[^] What are peoples thoughts on this? It says SQL server 7, so is SQL server 2000 okay? Quote from a clever bloke : "I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones." - Albert Einstein
-
http://news.com.com/2100-1001-985359.html?tag=fd_top[^] What are peoples thoughts on this? It says SQL server 7, so is SQL server 2000 okay? Quote from a clever bloke : "I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones." - Albert Einstein
From the Timeline, Inc site: In its ruling, the court stated: “Accordingly, we reverse the trial court's declaratory judgment and remand for entry of declaratory judgment in favor of Timeline. Our construction of the agreement does not deny sublicensing protection to all Microsoft customers who add code or combine software with SQL Server. If a Microsoft licensee adds code to SQL Server that is not a 'material part' … (footnote omitted) of Timeline's patent, no infringement has occurred, even if the resulting combination would otherwise infringe Timeline's patent. But if the added code is a material part of Timeline's patent, and the resulting combination infringes the patent, the sublicensee has exceeded the scope of Microsoft's sublicensing rights under the agreement. Reversed and remanded.” I wonder if that "footnote omitted" defines what constitutes a material part of the patent? More importantly, where do we find a definition of this protected part of SQL Server? If I was a corporate lawyer and got wind of any internal project being developed using SQL Server, I'd be strongly advising my management to pick another db before spending another dime on it. It is ok for women not to like sports, so long as they nod in the right places and bring beers at the right times.
Paul Watson, on Sports - 2/10/2003 -
From the Timeline, Inc site: In its ruling, the court stated: “Accordingly, we reverse the trial court's declaratory judgment and remand for entry of declaratory judgment in favor of Timeline. Our construction of the agreement does not deny sublicensing protection to all Microsoft customers who add code or combine software with SQL Server. If a Microsoft licensee adds code to SQL Server that is not a 'material part' … (footnote omitted) of Timeline's patent, no infringement has occurred, even if the resulting combination would otherwise infringe Timeline's patent. But if the added code is a material part of Timeline's patent, and the resulting combination infringes the patent, the sublicensee has exceeded the scope of Microsoft's sublicensing rights under the agreement. Reversed and remanded.” I wonder if that "footnote omitted" defines what constitutes a material part of the patent? More importantly, where do we find a definition of this protected part of SQL Server? If I was a corporate lawyer and got wind of any internal project being developed using SQL Server, I'd be strongly advising my management to pick another db before spending another dime on it. It is ok for women not to like sports, so long as they nod in the right places and bring beers at the right times.
Paul Watson, on Sports - 2/10/2003Roger Wright wrote: If I was a corporate lawyer and got wind of any internal project being developed using SQL Server, I'd be strongly advising my management to pick another db before spending another dime on it. I was thinking the same thing. Not to run around like Chicken Little, but this is some serious stuff. I wonder how many business will pay the royalty or opp to *just* re-engineer their existing systems. quorum pars magna fui
-
MySQL is fast tables - and that is all. No transactions, stored proceedures, referential integrity contraints, triggers or programming languages. Claims of MySQL speed are worthless because as soon as you use transactions (a new feature) it becomes dog-ass slow. I've used both extensively, and until you have formal schooling in databases, you'll never see why you should use PostgreSQL. I don't say that to be mean, but that's exactly how I learned that MySQL is just fast tables, and there's a LOT more to databases than tables.
-
MySQL is fast tables - and that is all. No transactions, stored proceedures, referential integrity contraints, triggers or programming languages. Claims of MySQL speed are worthless because as soon as you use transactions (a new feature) it becomes dog-ass slow. I've used both extensively, and until you have formal schooling in databases, you'll never see why you should use PostgreSQL. I don't say that to be mean, but that's exactly how I learned that MySQL is just fast tables, and there's a LOT more to databases than tables.
-
I am very much aware. I was a 3.xx user that was eagerly awaiting the 4.x line to become stable. Still, there are no triggers and programming languages. You have to rely on the app for the logic, and having learned from experice, that is a bad thing. Imagine several clients. You upgrade the ones you know about. You don't upgrade the ones you don't. All hell breaks loose because the old clients are not behaving in the new way. Database inconsistantcy. Database develoges into garbage if not caught soon. Manwhile in a world of triggers, you must merely maintain the same business rules. Upgrade the rules on the server (stored proceedures) and whalla, all clients everywhere are updated. No incosistantcies.
-
I am very much aware. I was a 3.xx user that was eagerly awaiting the 4.x line to become stable. Still, there are no triggers and programming languages. You have to rely on the app for the logic, and having learned from experice, that is a bad thing. Imagine several clients. You upgrade the ones you know about. You don't upgrade the ones you don't. All hell breaks loose because the old clients are not behaving in the new way. Database inconsistantcy. Database develoges into garbage if not caught soon. Manwhile in a world of triggers, you must merely maintain the same business rules. Upgrade the rules on the server (stored proceedures) and whalla, all clients everywhere are updated. No incosistantcies.
in my experience when u have to make a change that significant to the database there are usually changes reqd to the client app as well so i didnt find much of an impact there are other ways than embedding the sql into the app anyways lastly clients _really_ love the licensing costs of mysql