[ANNOUNCEMENT] jOOQ 3.2.0 released with a new licensing strategy, new powerful SPIs, and lots of code generator improvements

[Lukas Eder]

With the new jOOQ 3.2, apart from introducing great new features, we are 

changing quite a few things on how we operate. At Data Geekery GmbH, we believe

in Open Source. But we also believe in the creative power enabled by commercial

software. This is why we have chosen to implement a dual-licensing strategy.

Read more about this strategy here:

http://blog.jooq.org/2013/10/09/jooq-3-2-offering-commercial-licensing-and-support

But jOOQ 3.2 also ships with great new features! They include:

A new RecordListener SPI which can be hooked into the Configuration in order to

control ActiveRecord lifecycle events. This is very useful if you want to

initialise some database records prior to inserting new data, or if you want to

implement a central ID generation strategy, e.g. by generating Java UUIDs.

A new, experimental VisitListener SPI which can be hooked into the Configuration

in order to control jOOQ's complete QueryPart rendering and variable binding

lifecycle. Use this powerful SPI to perform custom SQL transformation, e.g. to

implement shared-schema multi-tenancy, or a security layer centrally preventing

access to certain data.

With this release, the Oracle and DB2 SQL dialect families will now be able to

distinguish Oracle 10g, 11g, 12c features, as well as DB2 9.x, 10.x features.

This is important as more and more databases start supporting the SQL standard

OFFSET .. FETCH clause and other clauses that are emulated by jOOQ.

The code generator has experienced a lot of improvements, mainly including a new

MatcherStrategy, which can be configured through Maven or XML code generator

configurations. This generator strategy will allow you to implement several

regular-expression based naming pattern replacements for all sorts of generated

artefacts. This is extremely useful to generate table, record, pojo class name

prefixes, suffixes in particular, or to just completely redesign the way the

jOOQ code generator generates things.

For more details, see the release notes: http://www.jooq.org/notes

[Eric Schwarzenbach]

Lukas,

Maybe you've already considered this, but let me point out one consequence of this in the form of my own real life case: I'm currently working on library in which I am currently making use of JOOQ. My intention is to release this library as open source. My intention is also for it to work with any database. With this license change, I don't think I can do so. So I will be seriously considering abandoning the use of JOOQ in this tool. I will probably have to.

My company makes another product (not open source) which can work with any database (it has a small module which makes a couple of adjustments for different database vendors...it isn't complete and we only add to if we have a customer who wants to use a database we haven't yet added support for). This product doesn't use JOOQ but I've mused before that I might if I were do the intial work today, and if I were ever to rewrite certain parts of the system I would consider using JOOQ. So to speculate on the case of if the product did use JOOQ, this would complicate our licensing and we would probably have to charge an additional fee for customers that wanted to use a commercial database. I can't say whether we would or wouldn't do that, but I'm just saying this would be a complication and some level of discouragement to using JOOQ.

This is also going to be deciding factor for many people looking for a tool like this and making JOOQ or QueryDSL choice.

I understand why you might make this change, and of course there are trade offs.I'm not intending to criticize your choices, just to give some feedback on how it may relate to your users' choices. It is with no hard feelings but with some regret, that I suspect I will be working with JOOQ somewhat less in the future.

Best regards,

Eric

[Witold Szczerba]

I am worried the licence change can be a huge stopper for adoption of
this great library.
In my company, we wanted to create some kind of application skeleton,
a full stack (back-end to front-end) and make it a public project (we
were planning the JUG meetings about it), so other
developers/companies could benefit and contribute. We have few similar
applications already created in a similar manner, all of them use JOOQ
instead of JPA.

The problem is, the developers are the most ignored people in IT
business. Most of the time we have zero influence as, for example,
what database to use in the new system, because our customer already
has... Oracle or MSSQL and we can do nothing about it. Also, in many
companies, no one will allow to spend like EUR400 per developer only
because they choose some kind of, unknown for the majority, library. I
can hear the voices: do you really need this or is it just your
craving to use it?

I am very sad to hear this huge licence change. Not because I would
never spend "x" times EUR400 for a project which is supposed to bring
like many times more profit (although there are projects which brings
loss), but because I know that developers won't be able to persuade
the guys who pay for it.

I do understand your point of view, though. I am just not sure if it
won't stop/remove the adoption of this great library. It is great, but
it's "just" (no offense) a library. The "money" guys do not understand
this. They are going to spend like dozen times more for some totally
stupid licences for unnecessary products, like Oracle or MS SQL + MS
WINDOWS + MS[whatever] because other guys with nice suits work hard to
make them feel they need it. They will buy 3 super expensive servers
which could handle like 100x more traffic they will ever need instead
of one simple, but they will never understand why those developers
need to pay licence for something unknown, which is, bye the way, "so
easy" to replace for something well known (like Hibernate).

Of course, there are also companies which will not think twice and
just buy the licences if the developers will request ones. But for
then to buy it, developers need to know it and they need to be
convinced. They can be convinced if they hear and read about this, or
about other projects using it, I am just worried there will be much
less "noise" about JOOQ after the change.

At the end, I would like to thank you for this great library and I
hope I am wrong, and it will raise in popularity. I also hope I will
be able to create new projects in future which will use JOOQ, but the
choice is not up to me any more.

Regards,
Witold Szczerba

> --
> You received this message because you are subscribed to the Google Groups
> "jOOQ User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jooq-user+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Lukas Eder]

Dear Eric,

Dear Witold

Thank you very much for your honest feedback. First off, let me assure you that I haven't been thinking about many other things in the last three months :-) So I am fully aware of the consequences you've mentioned, which this step has on:

- costs being a factor in favour of a competitor's free product in smaller projects.

- license complexity being a factor in favour of an alternative in free open source projects

- "internal sales" between developers and managers being another factor

However, I would like to invite you to see things also on the bright side. It is my strong conviction, that Oracle Database, and Microsoft SQL Server (and PostgreSQL, of course) are the best databases on the market. It is with those databases, that jOOQ adds most value: to developers by being fun to use, and to managers by getting a big ROI on developer productivity. If an Oracle Database license is not an issue to a purchasing department, then a much less expensive jOOQ license won't be, either (see LLBLGen Pro). In fact, managers will now take jOOQ more seriously than before, when they might have mistrusted a free Open Source middleware product to whom they confide their most valuable asset: their data.

When I decided to leave Adobe for my own venture, I had taken a strong decision in favour of jOOQ in general. 

- This includes a more self-confident appearance, which will again help developers convince managers to use jOOQ. 

- This also includes a road-show, which I am planning in the next months to increase brand awareness, as my talks at JUGs had been generally well-received. 

- This includes all the current social media marketing I've been doing through the blog, twitter, etc.

- And, of course, I'm hoping to raise money through subscriptions to be able to continue providing developers with awesome SQL tooling, including but not limited to jOOQ itself.

As stated in my announcement, I don't see jOOQ as "just" a library. I see jOOQ as a vision, being the only platform on the Java market that aims for bringing Java and SQL closer together, without being distracted by the new impedance mismatch that other APIs (e.g. JDO, recent movements in some JPA implementations, QueryDSL, Microsoft LINQ, or Scala SLICK) have introduced by unifying query APIs across heterogeneous data stores. Imagine, if SQLJ had been developed with more visions and less politics, how popular it could have become!

Imagine what other awesome things can evolve, given the discussions on this user group about BNFs, DSL API generation, possible JSRs evolving from jOOQ (e.g. a better meta data API: javax.sql.meta, or an annotation-based internal / external DSL mapping), the amount of SQL transformation performed by jOOQ... 

But to continue all this work, I will need some revenue. I would thus like to invite you to see this step as a step forward, from which everyone will profit. At Adobe, Roy Fielding was often cited having said that there is essentially no difference between commercial and Open Source software. This is quite interesting, as Adobe heavily engages in blending Apache software (Felix, Sling, Jackrabbit) with its Adobe Experience Manager. In the end, software business is about perceived and about actual added value. And I firmly believe, that both perceived and actual added value offered by jOOQ will increase in the near future.

tl;dr:

Nonetheless, my developer heart continues beating as before, and I will continue to strive to keep the Open Source community around jOOQ alive. It was not at all an easy decision to make this step, as I strongly do believe in Open Source. I am always open to such feedback, for which I want to thank you again.

Lukas

2013/10/10 Witold Szczerba <pljos...@gmail.com>

[Witold Szczerba]

Hi again,
I was thinking about this license a bit. There is one difference
between spending money on application servers, database products and
things like JOOQ. Let me provide an example. I remember a discussion
with my colleague from another company about the software they use
for one of theirs project for financial institution. I was asking him
why, on earth, they use fat, slow, hard to install, very expensive and
extremely developer unfriendly application server for their project.
He explained to me how "things" happen in big companies. That very
case was like this: some bank, let it be "B" wants new system. They do
not force the IT company "X" to use product this or that, they can
choose. So, company "X" has special "sales" branch. That branch will
decide which product the bank "B" will buy. So, X talk to Oracle, MSFT
or IBM and ask them how much money "X" will get for making "B" buy the
product. Because projects live very long, the big companies can charge
them for the long time, so they really really want to be picked by
"X". Developers? No one ask them. This is why Spring was so
successful, because it provided an option for developers not to
use/depend on any of the "fancy" features of fat and slow application
servers. So, developers use Tomcat with Spring, then they deploy to
another server, launch integration tests and voilà!

What's interesting, companies like Oracle allow developers use all
their products for free, so in their free time they can experiment and
"play" with full version of Oracle 11g forever for free. They know the
money is elsewhere (in "B" from example above). They know if
developers can play with as many databases and anything else for free
the less they complain if they are forced to use it.

If the IT company "X" could use JOOQ for free, but company "B" would
have to buy a licence (together with DBMS, hardware and dozen other
things with lots of 'zeros' after initial number), and even better, if
company "X" could be a JOOQ reseller (probably this also could be
advertised on the front page, I believe)... and even better, if JOOQ -
together with a licence could attach some kind of a... profiler or
something "fancy", nice and colorful icons (managers love it) - then I
would see it's future much brighter.

What do you think?

Regards,
Witold Szczerba

[Eric Schwarzenbach]

"If an Oracle Database license is not an issue to a purchasing department, then a much less expensive jOOQ license won't be."

In my experience the equation rarely works that way. The decisions to buy Oracle and the decsions to buy such and such an application that will use a database are more often than not connected, not made at the same level, do not occur in the same timescale, etc. In working for small companies selling software solutions, time and time again we see the situation of a group (department, whatever) withing a company buying a small or modest software solution with a small or modest budget. The larger company owns an Oracle (or SQL Server or DB2 or whatever) license. The solution they are buying is required to use that database system. The fact that the larger company was willing and able to blow millions on Oracle has nothing to do with what its many departments are willing and able to spend in the many smaller purchasing decisions they make around software solutions.

For much the same reason I can't build software that is tied specifically to PostgreSQL, as much I would like to. Selling that to such a place saying "this product is highly optimized for PostgeSQL...don't worry it's free" isn't going to fly. There is no arguing with the policy that "our company uses database X" for all database solutions.

Often, when I begin writing a piece of software, it is a "venture" in a certain sense. I don't necessarily know what databases it will eventually need to be able to run on. It may eventually go into one of the above situations. I also may not know how (or if) it will be sold, and what kind of revenue it will justify. You are asking new software efforts when considering whether to use JOOQ to know (or bet on) that they will only ever use a non-commercial database, or that they will be able to justify the cost of your license.

[Eric Schwarzenbach]

On a somewhat similar note, sometimes the code I write is not for a specific product, it may be for a library or component I want to reuse across any of my company's projects. Or I may be writing for a specific project with the thought that I might push it into such a library or component later, or I may have no idea when I'm writing it and the thought to do so may come later. Or, in the imperfect real world, a piece of such code may get reused by being copied to another project.

The context where decisions in writing code get made ("hey, I could use JOOQ for this!") and decisions at a much higher level ("What database do we use? How do we sell this and how much can we charge?") are often highly disconnected, and it is often highly desirable that they remain disconnected. You are making it such that the former decisions cannot be made without consideration of and visibility into the latter. For many of us, this is a strong motivator for the decision not to use JOOQ as the only safe decision.

To put it another way, the set of people unable to use JOOQ is not simply those who answer "no" to the two questions "can we use a non-commercial database" and "can my sales model support the cost of this licence." There is a vast grey area of different shades of "I don't know", "maybe today but I can't swear to tomorrow" which also equates to "can't afford to tie my code to JOOQ". I hope you don't underestimate the complexities that go into creating that grey area.

[Eric Schwarzenbach]

Actually I've been assuming something about how this license works, that I should verify:

Suppose I've written a piece of software using JOOQ (and say it uses the JOOQ Runtime module for execution) and sell this product to buy 5 companies that will use it with Oracle. Does this mean that either they each have to buy a JOOQ licence, or I have to buy those licenses and include them with my product? I've been assuming that my buying a single license does not cover me for however many copies of it I sell and get deployed on my customers servers.

Is this right or am I misinterpreting?

[darren.s...@gmail.com]

I think it's a terrible idea to charge money for "drivers" to commercial databases. I know you need to make money, but the value add should come from software you build on top of jooq, profilers, IDE integrations, debug tools, etc. Dont shoot yourself in the foot now. You have a good vision and jooq can turn into so much more that you can sell and do consulting for. The magical feature of Ruby on Rails was activerecord. You have a magical feature here with jooq. Just build some more things around it.

I know people who buy oracle can probably spare a few bucks, but what your doing is now making my open source product that is free (as in beer) and then suddenly adding a cost to it. I really really think your are going to alienate a lot of users based on perception and principal. It doesn't matter that your probably right that the cost shouldn't be that big of a deal, but people will perceive it that way and not adopt jooq.

I have to think twice now about using jooq. Which is really upsetting because I really like it and do think its a better than everything that is out there. It's a sad day....

Darren

[darren.s...@gmail.com]

So here's my dilemma now. I'm a committer on Apache CloudStack. ACS currently has a custom data access framework that is somewhat limiting. I've been working on the technical feasibility of moving to an off the shelf open source framework for database access. After much analysis I came to the conclusion that hands down jooq was the right framework. I was just working through some technical issues on how to integrate jooq and then I was going to put this up for discussion on the mailing list. Now with this license announcement, I'm not sure if I should do that anymore.

It's not a legal issue I'm worried about, when people see this style of commercial licensing they get turned off by it and apache is full of a bunch of open source enthusiasts. So while jooq is awesome, querydsl is probably acceptable. So I think I'm going to have to look further at querydsl because I'm not too sure jooq will be accepted by the community anymore.

As I said before, sad day for me....

Darren

[Lukas Eder]

Hello Darren,

Thank you very much for your openness. I'm very sorry to hear how bad our new licensing strategy has made you feel. As mentioned before, I have long contemplated many alternatives, and even if I found this one to be the most promising, I knew that it will be very disappointing to many users who believe in Open Source as much as you do. I hadn't been looking forward to that aspect of moving forward at all.

Rest assured, though, that I'm very open to discussion and creative solutions. I believe that there is room for win-win situations also with non-commercial Open Source stakeholders such as Apache CloudStack. What if jOOQ followed suit with the popular YourKit Profiler's licensing strategy (see http://www.yourkit.com/purchase/index.jsp) and allowed Apache CloudStack and other non-commercial OSS projects to include (but not redistribute) "jOOQ Enterprise" in return for a backlink? By "not redistributing", I mean that the jOOQ API may only be used by CloudStack internally, and must not be made available to CloudStack consumers.

I am aware of the Apache Foundation's generally rather strict views on what is acceptable for inclusion, but I think that it might be worth to pitch such an idea to your community. What do you think?

> So while jooq is awesome, querydsl is probably acceptable.

That is the best comparison I've heard so far. :-) May I cite this?

Best regards,

Lukas

2013/10/11 <darren.s...@gmail.com>

Darren

[Lukas Eder]

Hello Witold,

Thank you very much for your additional input. I agree that developers should be able to "play" with new software for free, to get a better picture. This is why I offer free one-month trial licenses for both the jOOQ Professional Edition and the jOOQ Enterprise Edition. I am also contemplating adding a competitive jOOQ Personal Edition (with Enterprise features), similar to what IntelliJ does. This is particularly interesting for freelancers.

I have kept a "jOOQ Reseller Edition" license in the back of my head as I also think that it could be quite interesting from a Data Geekery sales perspective. In principle, what you're saying amounts to a regular Server license. In a first step of my business and legal development, I think that such a license model is quite complex as opposed to the rather straightforward Workstation license I'm offering right now. But I don't generally exclude it for 2014.

Note that with jOOQ 3.2 and Data Geekery, I'm at the beginning of what will hopefully evolve into an enduring, long-running adventure. Things aren't set in stone, and I will have to experiment with various possibilities of making money in order to provide you with new awesome features. Again, I think that even if these steps may be a bit of a short-term bummer (and I fully understand your concerns!), I think that in the long run, everyone will win.

Thanks again for your open feedback! I very much appreciate that.

Lukas

[Lukas Eder]

Hi Eric,

It is true that *some* setups will be at a disadvantage by the current licensing strategy, much like other licensing strategies will put others at a disadvantage. Another option might have been to follow suit with OneWebSQL and charge only for the code generator: http://onewebsql.com. For jOOQ, this would have put 80% of all users at such a disadvantage. So I agree with you, that there is a grey area of different shades of "I don't know if jOOQ is right". I would even say that this has been true for all previous versions of jOOQ. I can assure you that I don't underestimate those complexities, but I cannot address them all at once. This is why I keep trying to assure this group that I am open to discussion and to creative solutions. But I also want to start this business now, and I have to start somewhere, with some assumptions.

Now, when you buy a car, you don't just buy the cheap Fiat because of the "disadvantages" induced by the Ferrari, right? :-) You make an informed (or emotional) decision. So let's start again at looking at advantages, at the bright side. I think that by looking at the advantages, we'll find the best solution for jOOQ's future.

For instance, by using jOOQ's typesafe API, generated code and all the SQL knowledge put inside jOOQ, you might be able to complete your project 20% faster, as you:

- Make no syntax or data type mistakes

- Write SQL much faster through IDE autocompletion

- Take advantage of all the powerful SPIs to control SQL output

- Can embed all your stored functions into SQL, typesafely

Now, with Oracle in particular, the above advantage is extraordinary, as you get native jOOQ support for things like:

- CONNECT BY

- PIVOT clauses

- Oracle UDTs with member procedures

- I just registered a feature request about the partition extension clause from this thread: https://groups.google.com/forum/#!topic/jooq-user/hLojif16pXM

I hope you stay with me on this matter. I think that by looking at advantages and added value, we'll find the best set of solutions for a dual-licensed jOOQ. I am fully aware that going from free to partially non-free leaves some uneasy feelings of surprise and regret. And I'm glad that they're expressed and (hopefully) addressed. But I'm very positive about this whole venture as I'm sure it will work out one way or another. It was the right time to make such a step.

Lukas

2013/10/10 Eric Schwarzenbach <ericjs...@gmail.com>

Actually I've been assuming something about how this license works, that I should verify:

Suppose I've written a piece of software using JOOQ (and say it uses the JOOQ Runtime module for execution) and sell this product to buy 5 companies that will use it with Oracle. Does this mean that either they each have to buy a JOOQ licence, or I have to buy those licenses and include them with my product? I've been assuming that my buying a single license does not cover me for however many copies of it I sell and get deployed on my customers servers.

Is this right or am I misinterpreting?

--

[Lukas Eder]

Hi Eric,

2013/10/10 Eric Schwarzenbach <ericjs...@gmail.com>

Actually I've been assuming something about how this license works, that I should verify:

Suppose I've written a piece of software using JOOQ (and say it uses the JOOQ Runtime module for execution) and sell this product to buy 5 companies that will use it with Oracle. Does this mean that either they each have to buy a JOOQ licence, or I have to buy those licenses and include them with my product? I've been assuming that my buying a single license does not cover me for however many copies of it I sell and get deployed on my customers servers.

Is this right or am I misinterpreting?

The jOOQ license is a developer Workstation license. If you're the only developer on your product, and your product is used only with Oracle, then you can buy a single "jOOQ Professional Edition" license regardless of the number of your customers. However, you may not sublicense or redistribute jOOQ, i.e. you may not make it available to your customers. Otherwise, they too (or you) would have to buy additional Workstation licenses.

I believe that the additional cost of using jOOQ in licensed software products is negligible, the more customers you have. This is comparable to ZKoss, a popular UI framework who are selling developer licenses (http://www.zkoss.org/price/pricing)

[biziclop]

Hi Lukas,

It's a shame you made this decision, although of course I can see where you're coming from.

Since the sizes of our developer teams vary in time (when a product needs a new module built, we'll have more working on that product, during normal maintenance mode only a few), for us your licensing strategy rules JOOQ out as a viable tool pretty much from the off. Paying for let's say 10 developer licences when 90% of the time we only need 2 is something we simply won't be able to justify. 

It is a pity because JOOQ used to be a brilliant library and we'd probably pay for a straightforward support licence but the quirkiness and awkwardness of the workstation licence makes it thoroughly impractical and unworkable.

Sometimes less is more.

Peter

[Lukas Eder]

Hi Peter,

I'm sorry to hear you have come to this conclusion so quickly. Have you read through the entire license text? There is a clause covering a shifting number of workstations needed:

17.2 Partial Ordinary Termination

The Customer shall be entitled to terminate the Agreement for a part of the 

Workstations at the end of each Subscription Period by observing a notice 

period of three (3) months. [...]

Would this respond to your needs? Of course you don't have to pay for 10 licenses if you don't need them 90% of the time.

In addition to that, compared to other vendors who sell developer licenses, jOOQ's developer workstation license is not tied to the actual person working on the team. This provides you with even more flexibility when working with jOOQ.

As I've mentioned before in this thread, I'm open to constructive solutions. This is also reflected on the downloads page (http://www.jooq.org/download):

Other price plans

Haven't found a price plan that suits your needs? Contact us for an individual price plan.

So if you feel that there is any other way for us to come to an agreement, I am willing to discuss alternatives. Openly, or through the above e-mail.

Regards

Lukas

2013/10/11 biziclop <bizi...@gmail.com>

[Eric Schwarzenbach]

I think my confusion centers around that "redistribute jOOQ" part. When you say "workstation license" I think of a tool like IntelliJ. Obviously when I develop code with IntelliJ my customers don't have to buy a license to it also when they use my software, however I don't need to redistribute any part of IntelliJ with my software. However if I use JOOQ to develop a piece of software, I generally will need to include some JOOQ libraries packaged with my code, say for example in the WEB-INF/lib folder inside a war file. While I don't expect my customers to extract your jars from my software package and develop code with it, still I have redistributed these JOOQ jars to them.

I think you may have a different understanding of the word redistribute than I do. Perhaps mine is flawed, but what really matters, I guess is what lawyers will understand from the terms of the license. Are you saying that your license allows me to include you jars with my software and my customers to run that software without buying additional licenses? (If so, I'm very happy and the concerns I have been expressing have been over-inflated.)

[Lukas Eder]

2013/10/11 Eric Schwarzenbach <ericjs...@gmail.com>

Fair point. I will have to review this term with my lawyer. From my understanding, the term distribution is not 100% clear. Everyone agrees that Data Geekery distributes jOOQ. But I think that not everyone would agree that Data Geekery customers redistribute jOOQ, if they manage to "hide" it inside their application. While "hiding" is difficult technically, it is simple, legally. 

Others claim that making jOOQ available via services (e.g. over the net) is also a form of redistribution. Prohibiting that, of course, is not at all my intent.

 

Are you saying that your license allows me to include you jars with my software and my customers to run that software without buying additional licenses?

Yes. Only those *developers* who run the software on their *developer workstations* need to buy a license. This is set out more precisely in the annex: 

2.1.1 Workstation 

All of the above price plans charge a Subscription Fee only for developer 

Workstations, not for server Workstations. A developer Workstation may only 

be accessed by one user at a time. 

I have chosen this approach because I think that the biggest added value is added at development time, not at run time - as opposed to a database, which is most likely sold using server licenses. In addition, I did not want to tie the license to the actual developer, such that new team members may inherit licenses from old ones. Workstation licenses are often also referred to as seat licenses.

This is what I'm offering right now. I don't exclude offering server licenses in a way similar to what Witold has suggested earlier this thread. But I do not want to engage in too many complex licensing models right now.

 

(If so, I'm very happy and the concerns I have been expressing have been over-inflated.)

I am happy to hear that! :-)

Clearly, initial feedback from this discussion will have to be reviewed with my lawyer. Then, next week, I shall write a small FAQ explaining common concerns with the license model.

Cheers

Lukas

[Witold Szczerba]

On 11 October 2013 15:11, biziclop <bizi...@gmail.com> wrote:
> Hi Lukas,
>

> It's a shame you made this decision [...]
> Peter

Peter,
who are you to tell things like that? Lukas is more than generous by
giving us JOOQ and devoting his time helping us for free for many
years. Maybe you haven't noticed, but Lukas is not working for a
company like e.g. Google, which pays developers running projects which
might be of use internally.
If it was up to you, would you prefer Lukas to stop developing JOOQ
and get another job to earn a living? Would you be happy going back to
concatenating SQL commands or (God protect us) switching back to
OR-Misery? OK, this one was biased :)
I'd suggest thinking twice before expressing thoughts like that.

--
Witold Szczerba

[Roger Thomas]

OK, as everyone out there has to eat I can't argue against you trying to generate a living from all the work you have put into this product.

One thing, have you considered setting the licence up in such a way as to still allow the open source licence to allow deployment against the Express version of MSSQL? This is a free release from MS that basically is deployed as a background service by many Windows applications.

Roger

[Roger Thomas]

As a follow up,

Will the OS and Trial releases found on the download page of the web site be in sync going forwards (so all the same release). I don't need to code against MSSQL and I may never need to deploy anything I write to MSSQL, but I do need to make sure that once in a while I check that it all works against MSSQL as its the market leader in the Windows world. So being able to pull down the Trial release once in a while will work fine, but only if its the same code base as the OS release.

Thanks.

Roger

[Lukas Eder]

Hi Roger,

Thank you very much for the feedback. Yes, I have considered creating specific price plans for SQL Server Express and Oracle Express. The general licensing strategy connects the "jOOQ Open Source Edition" to "open source databases", not to "free databases". So, express edition support will not be included in "jOOQ Open Source".

However, I'm gathering feedback in the next 1-2 weeks and work out another, cheaper price plan than "jOOQ Professional Edition", which grants access to SQL Server Express and Oracle Express in addition to all the OSS databases. Such a license will be available for jOOQ 3.2, then.

Cheers

Lukas

2013/10/12 Roger Thomas <rithom...@gmail.com>

--

[Lukas Eder]

Hi Roger,

Good question. And probably a slight "license-vulnerability". The license agreement's annex defines some constraints on the Trial Edition:

2.1.2 Termination of Trial Edition 

The Trial Edition Subscription shall be automatically terminated 30 days after 

Delivery onto a Workstation, after which it must be immediately removed from 

such Workstation. Without the written consent of the Supplier, Customer is not 

entitled to install the same Major Release of the Software on the same 

Workstation again under the terms of the Trial Edition Subscription. 

So, you can check your application's SQL Server compatibility once per Workstation and Major Release. jOOQ's licensing strategy generally doesn't keep you from implementing a 15-people, 5-year project against MySQL, and then switching to SQL Server in the last month of the project. But I'm pretty sure, if you were to do this, your application will terribly fail and the money saved on jOOQ licenses will be lost again in eternal bugfixing sessions :-)

But anyway, thanks for pointing this out. This shows that the "Express Edition" license that we've discussed in another mail will have to include some additional limitations to prevent such a scenario...

About your version sync concerns:

Yes, the OS / Trial / Professional / Enterprise versions will remain in sync, also for future releases. There are no plans to reduce the feature scope or delay releases for the OS version. Do note, however, that the Trial version might have other limitations, such as a "synchronized (SomeClass.class)" in the query execution code. I might also limit the number of executable queries per application execution, which will make it unusable for pre-existing, large applications built on "jOOQ Open Source Edition". It is really intended to be a Trial version to assess whether jOOQ should be used at all, or not.

Cheers

Lukas

2013/10/12 Roger Thomas <rithom...@gmail.com>

As a follow up,

--

[busi...@axelfontaine.com]

Hi everyone,

I, for one, agree with Lukas' decision about the license change. As some of you have already pointed out, everyone needs to eat, including Lukas. He has invested countless hours into building a great product with great documentation. He probably spends even more time answering all the questions on this mailing list, stack overflow and the issue tracker. And yet, some people are firm believers that the awesome end result of this effort, jOOQ, is worth 0. Every single penny is too much, either it's totally free, or they don't want it. And that's OK. I strongly believe there will be many other people who will recognize the incredible value jOOQ provides, and will be happy to support it. After all, who would want to go back to plain jdbc, spring jdbc or hibernate? Heck, that thought alone is worth some money!

In fact the pricing structure is very democratic (almost a joke!) compared to what the commercial DB vendors charge per processor core and for support. And yes, maybe it needs some fine tuning (see the discussion about the express editions), but let's be honest, what are a few hundred euros per year for a company that can afford to run Oracle or SQL Server in production? Absolutely nothing. All that is needed is a little bit of convincing with a business case. Lukas, maybe you could set up a ROI calculator like JRebel has on the pricing page? This would make it easier for users to argue why it is a great deal!

Keep up the excellent work and thanks for making such a great library!

Axel

P.S.: I am both an independent consultant and an open-source developer (I make Flyway, flywaydb.org), so I understand both sides, and what their thoughts and tradeoffs are, really well. 

[Roger Thomas]

So, you can check your application's SQL Server compatibility once per Workstation and Major Release. jOOQ's licensing strategy generally doesn't keep you from implementing a 15-people, 5-year project against MySQL, and then switching to SQL Server in the last month of the project. But I'm pretty sure, if you were to do this, your application will terribly fail and the money saved on jOOQ licenses will be lost again in eternal bugfixing sessions :-)

Unless you have the power of Microsoft behind you all licensing agreements are honor based rather than enforceable, but I hope that you find that the majority of your business focussed users are prepared to honor not just the letter but also the spirit of your agreement terms. I fit far more in the 'likes to mess about with code' group of users and so am unlikely to generate you any income as your OS based solution allows me to continue to work with JOOQ.

[Lukas Eder]

Hello Axel,

Thank you very much for joining in on the discussion and for your encouraging words! In particular for the hint with respect to the JRebel ROI calculator is very good. I've had a similar idea in mind. It's true that helping engineers convince their managers is an important next step to help promote jOOQ.

Best Regards,

Lukas

2013/10/13 <busi...@axelfontaine.com>

--

[Lukas Eder]

Hi Roger,

2013/10/13 Roger Thomas <rithom...@gmail.com>

So, you can check your application's SQL Server compatibility once per Workstation and Major Release. jOOQ's licensing strategy generally doesn't keep you from implementing a 15-people, 5-year project against MySQL, and then switching to SQL Server in the last month of the project. But I'm pretty sure, if you were to do this, your application will terribly fail and the money saved on jOOQ licenses will be lost again in eternal bugfixing sessions :-)

Unless you have the power of Microsoft behind you all licensing agreements are honor based rather than enforceable, but I hope that you find that the majority of your business focussed users are prepared to honor not just the letter but also the spirit of your agreement terms.

Yes, you are right.

 

I fit far more in the 'likes to mess about with code' group of users and so am unlikely to generate you any income as your OS based solution allows me to continue to work with JOOQ.

Good for you :-)

Cheers

Lukas

[Ryan How]

Hey Lukas, I read a few posts on this thread. I think it might be helpful to have some dot points about the licensing on the website just to give a quick overview. In particular the runtime library. I think you said about putting some FAQs or something. That would be a great idea :)

[Ryan How]

And all the best on your new endeavor! Exciting.

[Lukas Eder]

Thank you for your nice words, Ryan.

Yes, the licensing FAQ will be a valuable addition to the website.

Best Regards,

Lukas

2013/10/16 Ryan How <rh...@exemail.com.au>

And all the best on your new endeavor! Exciting.

--

[darren.s...@gmail.com]

Lukas,

I think if your open to creative solutions we can probably work something out.  I'll have to get back to you when I have more concrete plans to include jOOQ and also after I've discussed it with the larger community.

Just a general comment.  You obviously know databases and are quite an expert with SQL.  jOOQ offers some incredible power if you want to fully exploit the capabilities of SQL.  There are a lot of users that would use jOOQ that are not SQL experts and have very simple requirements.  For example, in Apache CloudStack the data access patterns are trivial and do not really need advanced SQL features.  But regardless of the features and power that jOOQ exposes, I believe users will still want to use jOOQ because its a delightfully simple API and easy to use.  So you can look at your users in two groups: casual users who use jOOQ because it provides a simple and nice API, and power user who use jOOQ because it allows them to get to powerful SQL features.  For power users, I think they will pay because jOOQ truly provides unmatched features.  For casual users, you'll never be able to monetize them.  Power users though will probably be less than 10% of your user base.  So just be careful as you try to monetize the power user, that you do not alienate the casual users.  The casual user will never pay you money, but they are essential to the livelihood of jOOQ.  I think you run the risk of unintentionally painting a picture that jOOQ is for people that need advanced SQL features.

Darren

[Lukas Eder]

Hi Darren,

2013/10/22 <darren.s...@gmail.com>

Lukas,

I think if your open to creative solutions we can probably work something out.  I'll have to get back to you when I have more concrete plans to include jOOQ and also after I've discussed it with the larger community.

Thanks for the feedback. Looking forward to hearing what your community says! Feel free to cross-link any discussion thread here on the jOOQ User Group. I'd be interested to join the discussion on your mailing list.

 

Just a general comment.  You obviously know databases and are quite an expert with SQL.  jOOQ offers some incredible power if you want to fully exploit the capabilities of SQL.  There are a lot of users that would use jOOQ that are not SQL experts and have very simple requirements.  For example, in Apache CloudStack the data access patterns are trivial and do not really need advanced SQL features.  But regardless of the features and power that jOOQ exposes, I believe users will still want to use jOOQ because its a delightfully simple API and easy to use.  So you can look at your users in two groups: casual users who use jOOQ because it provides a simple and nice API, and power user who use jOOQ because it allows them to get to powerful SQL features.  For power users, I think they will pay because jOOQ truly provides unmatched features.  For casual users, you'll never be able to monetize them.  Power users though will probably be less than 10% of your user base.  So just be careful as you try to monetize the power user, that you do not alienate the casual users.  The casual user will never pay you money, but they are essential to the livelihood of jOOQ. 

Have a look at this page:

http://java-source.net/open-source/persistence

In the "casual user" segment, jOOQ has a huge amount of "casual competition". Little tools like DbUtils, JDBCTemplate, Ebean, ActiveJDBC, Squill, JaQu, Iciql, Jequel, you name it. jOOQ doesn't offer too many USPs in the area of "not using hardcore SQL". But it has awesome features like multi-tenancy (shared-schema multi-tenancy from jOOQ 3.3 onwards!), SQL transformation, SQL standardisation, typesafe embedding of stored functions, UDTs, powerful query lifecycle handling. 

Just today, I have implemented support for the SQL standard WINDOW clause (currently available in PostgreSQL and Sybase SQL Anywhere). Thanks to jOOQ 3.2's SQL transformation feature, this awesome SQL clause can be emulated easily in DB2, Oracle or SQL Server, which do not support the WINDOW clause. No other affordable database software is capable of such SQL transformation.

Now, I think that the power users in jOOQ's user base are far more than 10%. The feedback I get on this user group indicates precisely so. My sales efforts in the last two weeks indicate the same. jOOQ's biggest added value is where people spend a lot of money on very good, feature-rich databases, such as Oracle or SQL Server and that's why they're here. My vision and my business plan is really to provide awesome tooling to those who want to do heavy SQL and have but two choices: jOOQ or JDBC.

Now, I can tell you that the OSS jOOQ downloads have slightly increased since jOOQ 3.2, due to my recent (and upcoming) marketing efforts. And I'll be spreading the word even more at conferences, such as Topconf in Tallinn in November: http://www.topconf.com. Anyways, "casual SQL users" are often fine with MySQL, or if they're lucky, with PostgreSQL. And they still get jOOQ for free! Isn't that great and essential to jOOQ's livelihood? So in other words...

I think you run the risk of unintentionally painting a picture that jOOQ is for people that need advanced SQL features.

That picture is being painted quite intentionally :-) Finally, advanced SQL developers have appropriate tooling. And "casual users" can use it for a competitive price if they're using an advanced SQL database, or for free if they're using a "causal database".

Lukas

[Witold Szczerba]

Hi Lukas,
I think Darren is right and you are underestimating, so called,
'casual' users. JOOQ gives power users features they can get nowhere
else.

The fact is, most casual database users are struggling with JPA or
Hibernate. In fact, I guess, they would save themselves a pain if they
would switch to document repositories, because most of the time they
do CRUD of tree-like forms, mapped to relational table model. Maybe
few percent of their data is truly "relational".

So, they don't want or they cannot switch to NoSQL (like I said, most
of the time they cannot even switch from Oracle/MsSQL to PostgreSQL),
so basic JOOQ usage like code generator and basic CRUD is all they can
hope for.

JOOQ works great, simple stuff is simple, so there is no need for them
to ask questions or have their say. I think there can be more of them
than you think...

As usual, taking advantage of the opportunity, thanks for great job!
If only the JCP Spec Leaders were capable of creating such a stuff,
the world would be a much better place to live, hehehe

Regards,
Witold Szczerba

2013/10/22 Lukas Eder <lukas...@gmail.com>:

[Lukas Eder]

Hi Witold

2013/10/23 Witold Szczerba <pljos...@gmail.com>

Hi Lukas,
I think Darren is right and you are underestimating, so called,
'casual' users. JOOQ gives power users features they can get nowhere
else.

The fact is, most casual database users are struggling with JPA or
Hibernate. In fact, I guess, they would save themselves a pain if they
would switch to document repositories, because most of the time they
do CRUD of tree-like forms, mapped to relational table model. Maybe
few percent of their data is truly "relational".

So, they don't want or they cannot switch to NoSQL (like I said, most
of the time they cannot even switch from Oracle/MsSQL to PostgreSQL),
so basic JOOQ usage like code generator and basic CRUD is all they can
hope for.

Hehe, funny how a code generator and basic CRUD is what Hibernate had been offering all along, and apparently, people are struggling with it...? But clearly, not everyone agrees on that. Many people love Hibernate, and I wish people wouldn't try to look for a "better Hibernate" in jOOQ. jOOQ's mission statement compared to Hibernate is very clear: http://www.hibernate-alternative.com

Hibernate was awesome from the beginning. But people expected it to be a magic bullet for all sorts of problems and didn't get what they wanted...

 

JOOQ works great, simple stuff is simple, so there is no need for them
to ask questions or have their say. I think there can be more of them
than you think...

As usual, taking advantage of the opportunity, thanks for great job!
If only the JCP Spec Leaders were capable of creating such a stuff,
the world would be a much better place to live, hehehe

Eh, I don't do politics (yet). ;-)

[Lukas Eder]

Hi Eric,

Hi Group,

This is a short update on the recent discussion about jOOQ licensing. There is a new version of the license text available, clarifying on Eric's very justified concerns about how "distribution" was laid out in the previous text. The updated text now clearly defines what is possible and what isn't possible. As mentioned before, it is not at all my intent to keep you from shipping your end-user applications with an embedded jOOQ. My intent is to keep you from making jOOQ broadly available to your users.

More details can also be found in the newsletter:

http://us7.campaign-archive2.com/?u=56a8329c44f5581f516d4e490&id=bff05e4d6d

And in the new license text:

http://www.jooq.org/legal/131028_jOOQ_License_and_Support_Agreement.pdf

As this license is more permissive than the previous one, it becomes effective immediately, also for existing customers.

Furthermore, FAQ's have finally been set up:

- http://www.jooq.org/licensing#faq-commercial

- http://www.jooq.org/licensing#faq-opensource

I'm happy to discuss further issues on this user group or directly at sa...@datageekery.com

Thanks again, for all your valuable feedback!

Cheers

Lukas

2013/10/11 Eric Schwarzenbach <ericjs...@gmail.com>

--