Ingres screws up their open source license, again!

IMPORTANT: Some people have commented/emailed that I’m off my rocker by asserting using a GPL database triggers the viral nature of GPL. I should make the VERY CLEAR distinction that the reason it triggers the GPL (I believe) is because the CLIENT ACCESS LIBRARIES are GPL licensed (the client code is embedded into the CLIENT applications). I don’t think it really matters what the server in a different process is licensed as, it’s the JDBC drivers that cause GPL to kick in. Refer to the MySQL interpretation of this (LGPL to GPL)

UPDATE: I’ve been told that the announcements on GPL may have been incomplete. There is possibilty that interface code may be LGPL to allow for use in the ISV/OEM apps without GPL restrictions. I’ll update this if/when there is an actual announcement on LGPL stuff.

I was quite optimistic when Ingres was divested from CA. Here was an opportunity for Ingres, a mature feature rich database, to make a real dent in the world. Instead, Ingres (the codebase) has made the same mistake AGAIN by choosing a license which will ensure it never becomes a “real” open source community, project or sustainable business model.

CA made the mistake of picking a funny license when they open sourced Ingres: CA-TOSL was an off color license that many people passed up even considering Ingres. CA squandered an opportunity to create a real open source project, which is just disheartening. There is SO MUCH in Ingres that with “two cups and two tablespoons of community” Ingres could have been the leading open source database. Instead, they came up with a “pro-CA” but relatively business friendly license that meant Ingres, it’s source repository, etc remained decidely in the fortress of CA.

Ingres was divested to a lean, mean Ingres company with the sole purpose to making Ingres the leading “business open source.” This was truly exciting, and the potential of what Ingres could become was palpable. Parallel query execution, intelligent join operations, replication, distribution, table partitioning. A robust feature rich RDBMS primed for the ISV/OEM and early adopters needing an open source RDBMS worthy of their applications. Forget the GUIs, marketing materials, and blackbox functionality: Ingres was primed to be the tool of choice for companies willing to overcome some of the rough edges to power their platforms. It could have been the “Kleenex” of FOSS DB. The “Hobart” of FOSS DB. The “Phillips Screwdriver” of FOSS DB.

Terry, I’m sorry to say, you must have received some bad advice. Actually, let me clear here: REALLY BAD ADVICE! The GPL is the nail in the coffin that will make the long drawn out history of Ingres final. It will fade to obscurity because NO ONE will touch it with GPL. Let me explain and I hope for your investors and customers that I am wrong!

The days of being an RDBMS for general purpose are done!
You are going to be used as a component in an application or service. If people are purchasing their DB first and they plan to build extensively on a database they are choosing commercial vendors. Quite simply put, if someone wants to build their application and the database is the most important piece of that puzzle (think PL/SQL, triggers, etc) then it’s not an open source database. ISV and OEMs are the ONLY ONES that are going to build sustainable economic conditions for an open source database. Your company identifies this in the “Three Degrees of Seperation” whitepaper posted on your site.

GPL means that companies building applications for BUSINESS won’t use you!
Why do you think that most BUSINESS ORIENTED applications considering an open source database have chosen Postgres? The GPL is quite frankly, really really scary to companies and so NO ONE who is building any sort of “Pro” edition, building applications with significant amounts of their own capital, or using other business friendly open source license (which is one of the valid open source business models) will use it. Quite simply put, the GPL ensures that Ingres will not be used by companies building business applications.

Partners/ISVs/OEMs willing to purchase your license will choose SOMEONE ELSE!
Knowing that your GPL option is entirely unsuitable for embedding into an application why would anyone choose to PAY the licensing for Ingres when embedded proprietary licenses are cheap? ie, Knowing that customers aren’t going to get the benefit of an open source database it may as well be a black box that an application runs on and that’s it. Why choose to pay for a product that is technically behind Oracle when the “embedded” commercial version terms are comparable? If it costs the same amount, both are proprietary licenses, why would someone selling a business application forego the “powered by Oracle” to choose a proprietary Ingres license?

Zero chance at “community”
Ingres (the project, not the company) had failed to build any sort of community in more than a year. By ensuring that the entire Ingres codebase remains copyright Ingres Corporation you pretty much ensure that any features people may build into Ingres won’t see the light of day. This is the secret sauce of open source. Inventors inventing, leveraging the ideas and efforts of people all over the world. Well then, what about the GPL projects of the world that will use Ingres and contribute their time testing, qa’ing, bug fixing, etc? See next bullet.

The GPL “database of choice” is already decided
Every GPL project uses MySQL (not every, but close). Community, applications, knowledge, support, training, brand awareness. Done, finished. GPL projects needing a DB don’t really think about it. It is the de facto standard for GPL projects. Why would anyone writing Joe’s Open Source Scheduling and Management Toolkit choose Ingres that has NO community outside of Ingres corp and will NOT develop one (see previous bullet). Anyone needing your “enterprise features” above and beyond what MySQL provides will fit the category mentioned above (ISV/OEM) and find your license unsuitable.

Quite simply put, the CA-TOSL was bad for Ingres but the GPL is just horrendous (not necessarily because GPL is, just GPL for Ingres). Anyone who needs your features won’t use your commerical license (think integrated health care application X) when they can use other proprietary RDBMS and open source projects that COULD use Ingres won’t because they don’t need the features and MySQL is 10x better from a community/FOSS perspective.

I’m sad actually, I was quite excited about Ingres. RIP, Ingres. I hope the death comes swiftly and customers find little pain in their migration to other sustainable RDBMS projects/products.

6 thoughts on “Ingres screws up their open source license, again!

  1. Ganesh Prasad

    This seems to be a load of FUD. I can see that you don’t like the GPL, but there are any number of ways in which ISVs and business partners may use Ingres that don’t trigger the viral clause of the GPL. For example, if a proprietary product only connects to Ingres as a JDBC DataSource, and the manufacturer co-distributes Ingres with their product, how does that trigger the viral clause?

    “Embedding” is a loose term, too. There are ways to “embed” a database without making it a part of your product. You appear not to have considered those alternatives.

    Finally, there are “business-friendly” reasons why software should be protected by the GPL (gasp!). No one wants to contribute to a project whose fruits can be exploited in proprietary ways by a competitor. I’m sure the authors of BSD networking utilities felt really great about Microsoft blatantly porting their stuff to Windows (Decompile the versions of http://ftp.exe and telnet.exe on Windows NT 4.0 and see the license if you want proof).

    All in all, a great one-sided article, but far from a balanced picture.

    Reply
  2. Ganesh Prasad

    This seems to be a load of FUD. I can see that you don’t like the GPL, but there are any number of ways in which ISVs and business partners may use Ingres that don’t trigger the viral clause of the GPL. For example, if a proprietary product only connects to Ingres as a JDBC DataSource, and the manufacturer co-distributes Ingres with their product, how does that trigger the viral clause?

    “Embedding” is a loose term, too. There are ways to “embed” a database without making it a part of your product. You appear not to have considered those alternatives.

    Finally, there are “business-friendly” reasons why software should be protected by the GPL (gasp!). No one wants to contribute to a project whose fruits can be exploited in proprietary ways by a competitor. I’m sure the authors of BSD networking utilities felt really great about Microsoft blatantly porting their stuff to Windows (Decompile the versions of http://ftp.exe and telnet.exe on Windows NT 4.0 and see the license if you want proof).

    All in all, a great one-sided article, but far from a balanced picture.

    Reply
  3. Ganesh Prasad

    Oh, and two words for any company that absolutely must extend the product in a proprietary way — dual licensing.

    Since dual licensing is definitely on the table, Ingres Corp’s decision to go GPL makes perfect sense. I’m afraid your arguments are totally unconvincing.

    Reply
  4. Nicholas Goodman

    First, and perhaps most importantly, please please please do not consider this an “article.” It’s a blog. From my upper right hand corner “Observations, reviews, analysis.” I make no assertions that I’m a journalist… I have my opinions and I’m happy to share them. I’m also happy to have discussions about the content so thank you for commenting! It has now become, a “two sided” picture! 🙂

    “You appeared not to have considered those alternatives.”

    Ummm… that’s exactly what the UPDATE at the top of the page was about. You see, Ingres WAS going to be entirely GPL (including the JDBC and API access points) much the same that MySQL has. Using the JDBC client that is GPL would definitely be considered linking or embedding (check out MySQL licensing on this matter). Based on the community response (refer to Ingres website) Ingres is considering doing exactly what you suggest to ensure it doesn’t trigger the GPL (making JDBC LGPL or similar).

    re: FUD. Not my desire… the market will sort out what the Ingres adoption rate looks like. Check out this article and what the CTO says about how many “new customers” they’ve acquired:
    http://www.computerworld.com/softwaretopics/software/story/0,10801,109166,00.html

    re: GPL. GPL is grand for many applications (yes, even some business applications). However, my point is that the market that Ingres will ultimately be used in (ISV/OEMs) won’t accept a viral GPL. If Ingres wanted to be another MySQL (simple, solid DB) GPL might be a suitable choice.

    Ganesh… I mean this honestly… Ingres is AWESOME. It’s a technically sound database with GREAT enterprise features. I’m hopeful that Ingres does choose a good license (GPL DB and LGPL APIs) and learns how to build a community. I’ve offered to help them (I’ve emailed with more than 8 people at CA/Ingres), btw. They’re not interested….

    Ultimately, everyone is free to choose the license that suits them. Like I said… I hope I’m wrong. 🙂

    Reply
  5. Kenn

    FUD or no FUD?

    The project I am working on looked at ISVing Ingres. We had some technical issues and the licensing issue meant we chose PostgreSQL.

    I was heavily into Ingres in the past and I really wanted to use it for the project. I was biased and wasted too much time on it. I really believe this was the last chance for Ingres and its gone.

    Now I have PostgreSQL, I believe it has filled a gap left by its parent.

    Reply
  6. Jens

    This is not FUD 🙂
    Look at how Ingres progressed since this article was written? There are no community and few users. Ingres is a dying entity.
    As an ISV you are better off looking at SQL Server or Oracle if you need performance or PostgreSQL if you need low cost. With Ingres you cannot even give customers a trial version of the software without paying through the nose, you can do that with all other databases except MySQL (Unless you use PHP). Even SQL Server has a bigger penetration in the open source market than Ingres so there really is no reason to use it at all.
    The business situation for MySQL is very different in that PHP users has developed a large number of applications that are used extensively. It is still PHP that drives the MySQL user-base and programmers of other languages tends not to use it at all (except ruby, but it is changing also in the direction of PostgreSQL).
    So PostgreSQL is winning, too bad for Ingres may she rest in peace

    Reply

Leave a Reply

Your email address will not be published.