My Thoughts on the Datomic License(blog.goodstuff.im)
blog.goodstuff.im
My Thoughts on the Datomic License
http://blog.goodstuff.im/datomic_license
23 comments
> I find the no benchmarking clause to be absolutely ridiculous in this environment
That's called a DeWitt Clause and most database ELUAs have it.
http://en.wikipedia.org/wiki/David_DeWitt
That's called a DeWitt Clause and most database ELUAs have it.
http://en.wikipedia.org/wiki/David_DeWitt
The original DeWitt Clause was established by Oracle at
the behest of Larry Ellison. Ellison was displeased with
a benchmark study done by David DeWitt in 1982, then
just an assistant professor, using his new Wisconsin
Benchmark, which showed that Oracle's system had poor
performance.
See, if it were just "the ellison clause" it would need no further explanation.
I have considered and purchased a number of commercial libraries and development tools over the years (in particular, some Lisp implementations/compilers and databases, and some libraries), so I'll drop in a few notes on the subject:
* Price does not necessarily correspond to quality/capabilities. I have seen very expensive software that was disappointing, and very cheap (or free) software that was impressive.
* Paying a lot for software does not mean you will get the support you expect. You will get the attention, but your problems will not necessarily get fixed. This is just a business reality: some problems are too expensive to fix.
* A commercial licensing agreement you enter into is usually a huge problem that crops up later. It's baggage that you will carry along and will need to look into regularly: when you make a huge new sale, when you sign an escrow agreement with a customer, when you go through due diligence, or when you sell your company.
* A licensing agreement with revenue sharing is an even bigger problem. Setting apart the management costs, it is something that not all of your investors/partners/buyers will approve of.
* Commercial software, in general, has fewer users than free software. Which means you are more likely to end up the first or the only user of certain functionality. Not a good place to be in when you have systems to ship.
* If a company does not have a clear pricing structure, the negotiations might take too long to be worthwile. Just hearing a price is sometimes difficult and requires exchanging multiple E-mails („let us assess your needs so that we can provide you with a custom quote”).
* If you build your product on top of a commercial library, take into account that you are now dependent on the company you bought it from. Unless you have the source code and the rights to modify it — but even then, if the company goes under or gets bought, you might end up holding the bag and having to develop and support the code you bought.
Put another way, when I make a decision to use a commercial library, in general I will avoid it, unless:
* the pricing is transparent and immediately available,
* there is no revenue sharing, quarterly reporting, etc,
* there are few licensing restrictions,
* there are enough users I know of that I can assume the library has been used and tested,
* I get the source code,
* I get the rights to use the code after the company goes under or gets sold.
* Price does not necessarily correspond to quality/capabilities. I have seen very expensive software that was disappointing, and very cheap (or free) software that was impressive.
* Paying a lot for software does not mean you will get the support you expect. You will get the attention, but your problems will not necessarily get fixed. This is just a business reality: some problems are too expensive to fix.
* A commercial licensing agreement you enter into is usually a huge problem that crops up later. It's baggage that you will carry along and will need to look into regularly: when you make a huge new sale, when you sign an escrow agreement with a customer, when you go through due diligence, or when you sell your company.
* A licensing agreement with revenue sharing is an even bigger problem. Setting apart the management costs, it is something that not all of your investors/partners/buyers will approve of.
* Commercial software, in general, has fewer users than free software. Which means you are more likely to end up the first or the only user of certain functionality. Not a good place to be in when you have systems to ship.
* If a company does not have a clear pricing structure, the negotiations might take too long to be worthwile. Just hearing a price is sometimes difficult and requires exchanging multiple E-mails („let us assess your needs so that we can provide you with a custom quote”).
* If you build your product on top of a commercial library, take into account that you are now dependent on the company you bought it from. Unless you have the source code and the rights to modify it — but even then, if the company goes under or gets bought, you might end up holding the bag and having to develop and support the code you bought.
Put another way, when I make a decision to use a commercial library, in general I will avoid it, unless:
* the pricing is transparent and immediately available,
* there is no revenue sharing, quarterly reporting, etc,
* there are few licensing restrictions,
* there are enough users I know of that I can assume the library has been used and tested,
* I get the source code,
* I get the rights to use the code after the company goes under or gets sold.
I was confused by, or the author is confused by the free community edition license.
The JAR files and runtime of the free community edition can be redistributed in other open source projects. Right? Haas something changed?
Edit: the author probably wanted to purchase the commercial version. If this is the case he could still package the runtime assets for docker, etc.
The JAR files and runtime of the free community edition can be redistributed in other open source projects. Right? Haas something changed?
Edit: the author probably wanted to purchase the commercial version. If this is the case he could still package the runtime assets for docker, etc.
As a developer of commercial software, this strikes me as a lot of paranoia, although I do agree with one or two points.
These types of agreements have to be somewhat broadly written so that if someone acts like a jerk and e.g. resells Datomic as a cloud service, the license has a way to stop that. It has nothing to do with preventing you from privately installing your Datomic instance on AWS, or otherwise being a reasonable customer.
Companies generally have a strong interest in being fair to their customers. Taking the most paranoid reading of the license text like it is constitutional law and tyranny is right around the corner is simply incorrect and unfair.
I invite comment on my own license: https://wukix.com/mocl-license-agreement (for https://wukix.com/mocl)
These types of agreements have to be somewhat broadly written so that if someone acts like a jerk and e.g. resells Datomic as a cloud service, the license has a way to stop that. It has nothing to do with preventing you from privately installing your Datomic instance on AWS, or otherwise being a reasonable customer.
Companies generally have a strong interest in being fair to their customers. Taking the most paranoid reading of the license text like it is constitutional law and tyranny is right around the corner is simply incorrect and unfair.
I invite comment on my own license: https://wukix.com/mocl-license-agreement (for https://wukix.com/mocl)
Which parts specifically would you consider paranoid? Issues similar to those pointed to by DPP (e.g. those found in the License Grant and Restrictions sections) have been used many times by software vendors to extort fees from licensees. And before you say that this would surely take such vendors out of business in short order, please know that this approach has been used by some of the worlds most successful software companies who are still very much around and well (at least financially).
For starters, objecting to the anti-criminality clauses seems paranoid. Granted, if you're a human rights organization under a hostile government, maybe you need to worry about this. But otherwise, what is the problem? Does one really need the ability to write viruses with Datomic? WTF?
Can you point to any specific examples of the extortionate behavior you describe? I imagine some companies cry extortion when they get nailed for genuine infringement (e.g., lots of unlicensed installs), but I would like to see an example where a software vendor went truly tyrannical on a customer that was actually using the software as agreed and intended.
Can you point to any specific examples of the extortionate behavior you describe? I imagine some companies cry extortion when they get nailed for genuine infringement (e.g., lots of unlicensed installs), but I would like to see an example where a software vendor went truly tyrannical on a customer that was actually using the software as agreed and intended.
> I'll use PostgreSQL 9.3 with JSON support. Yeah, it's technically not as good, but I know what my rights are.
What makes Datomic better than pg?
What makes Datomic better than pg?
Depends on what you are after I guess. Datomic puts the query engine in your application, so you're querying over a built-in cache. This means Datomic could be rediculusly fast for often requested data (should always be in cache). Datomic allows you to "travel back in time" as it has built in time management. Writes never blocks reads. All writes are atomic. Datomic supports functions (Java or Clojure) in queries and transactions. There is more, but this was a list of my most liked features.
Of course, Datomic has some drawbacks as well. Like storage space. Datomic never deletes anything, and isn't exactly conservative on storage either. For instance, a timestamp is saved for every value in the database. This allows you to view the database the way it was at any point in time, or tell you exactly when a user changed his password, username or email, but it does have a storage cost. Since Datomic is distributed, you also need a bigger setup (more machines) than with traditional databases.
Of course, Datomic has some drawbacks as well. Like storage space. Datomic never deletes anything, and isn't exactly conservative on storage either. For instance, a timestamp is saved for every value in the database. This allows you to view the database the way it was at any point in time, or tell you exactly when a user changed his password, username or email, but it does have a storage cost. Since Datomic is distributed, you also need a bigger setup (more machines) than with traditional databases.
I know you're not contrasting against PG here, but just to add: writes never block reads in PG either, all writes are atomic, and you can create functions for use in queries.
The main USP for Datomic is the way it distributes data, which if you've got the right use case (i.e. you're generally querying over a subset of the data) is really nice.
The main USP for Datomic is the way it distributes data, which if you've got the right use case (i.e. you're generally querying over a subset of the data) is really nice.
Standard SQL also supports temporal databases: https://en.wikipedia.org/wiki/SQL:2011#Temporal_support
Datomic doesn't have an O/R impedance mismatch, which is a Really Big Deal.
I attempted to explain this here: http://www.dustingetz.com/2013/03/26/orm.html
I attempted to explain this here: http://www.dustingetz.com/2013/03/26/orm.html
'Better' is a loaded term, from what I gather it has functionality reminiscent of graph dbs and a temporal aspect to it (versioning / auditing).
> reminiscent of graph dbs
Why are you talking as if graph dbs are a thing of the past like the "object-oriented dbs"? I'm about to start a project for which a graph db seems the only sane option right now and I'm contemplating Neo4j vs Titan.
I see graph dbs as a the only sensible future because graph data is a very common type of data, and once your queries involve traversals, path findings with conditions and such, expressing them as joins becomes both a performance penalty and a need to basically implement a graph db atop a rdbms in a form of a monstrous graph-orm-thingy.
And once you use a graph db with acid and all the goodies, you'll probably ask yourself what's the point of having a two datastores system, so one will have to go away.
Why are you talking as if graph dbs are a thing of the past like the "object-oriented dbs"? I'm about to start a project for which a graph db seems the only sane option right now and I'm contemplating Neo4j vs Titan.
I see graph dbs as a the only sensible future because graph data is a very common type of data, and once your queries involve traversals, path findings with conditions and such, expressing them as joins becomes both a performance penalty and a need to basically implement a graph db atop a rdbms in a form of a monstrous graph-orm-thingy.
And once you use a graph db with acid and all the goodies, you'll probably ask yourself what's the point of having a two datastores system, so one will have to go away.
> expressing them as joins becomes both a performance penalty
Under the hood, graph databases are still effectively performing 'joins'. There'll likely be optimisations with respect to node lookups, but the fundamental issue of locality of access is still there: it's simply a hard problem in graph data storage. Depending on the flexibility/declaritiveness of the query language provided, there's still the issue of intermediate result set explosion that also plagues triple stores.
This isn't meant to say that graph databases aren't very useful: native graph stores will certainly offer some useful technical specialisations and ease of use benefits - it's more to say that there's not (afaik) anything wondrous under the hood that means that native graph databases fundamentally solve the performance challenges of graph-structures-on-relational-dbs.
Under the hood, graph databases are still effectively performing 'joins'. There'll likely be optimisations with respect to node lookups, but the fundamental issue of locality of access is still there: it's simply a hard problem in graph data storage. Depending on the flexibility/declaritiveness of the query language provided, there's still the issue of intermediate result set explosion that also plagues triple stores.
This isn't meant to say that graph databases aren't very useful: native graph stores will certainly offer some useful technical specialisations and ease of use benefits - it's more to say that there's not (afaik) anything wondrous under the hood that means that native graph databases fundamentally solve the performance challenges of graph-structures-on-relational-dbs.
I think you may have misinterpreted his use of "reminiscent"
That's exactly it - it's a triple store with an extra version timestamp column, which allows (partial) distributed caches to be brought up to particular timestamps. Writes then happen against a central transaction engine.
He does make good points about the legalese. Quite worrisome.
It seems to be that this post is just not happy with the fact that Datomic guys are selling their software :)
From the article,
"I will also gladly pay Cognitect for Datomic if I get it into production for a non-trivial site."
"I will also gladly pay Cognitect for Datomic if I get it into production for a non-trivial site."
"I will also gladly pay" + look there are guys who give their product for free + I don't agree with your pretty much standard EULA = I will never pay but I would use it if it were free.
Your words, not his.
I too am very interested in diatomic, but I find the no benchmarking clause to be absolutely ridiculous in this environment. sure, some technologies are harder to compare because the specialization differs, but surely with something like the yahoo cloud data test or whatever could be helpful for someone considering the trade offs they get with Datomic.