ABI compatibility between commerical and OSS

[Darren S]

I'm currently writing some code that is intended to work across multiple databases and as such nothing is really using any DB specific features.  I'm only using and testing open sources DBs at the moment but I have every intention of supporting SQL Server.  I was wondering though if there is ABI compatibility between the commerical and OSS versions.  Specifically, can I compile against the OSS version and then ship with the commerical version for SQL Server.  I currently pick the dialect based off of configuration, so I do something like

SQLDialect.valueOf(database.trim().toUpperCase())

Obviously If I take advantage of any SQL Server specific functionality, then I would need to compile against the commercial version for that module.  But again, I don't wish to compile the entire platform against the commerical version, if possible.

Darren

[Lukas Eder]

Hi Darren,

Apart from legally interesting aspects of your enquiry, what is the reason you do not want to compile against the commercial version from the beginning?

From a merely technical point of view, the jOOQ Open Source Edition contains a subset of the jOOQ Enterprise Edition's source code, API and ABI. Going from OSS to Professional/Enterprise should certainly be feasible.

Cheers

Lukas

2014/1/20 Darren S <darren.s...@gmail.com>

[Darren Shepherd]

What I'm working on is a platform that is largely DB agnostic. The
data access patterns are trivial and, with the great help of jOOQ, it
should run on any DB. So I write my platform, which is open source,
and produce a release. I would then like to enable somebody else to
pick up my release, and if they choose to buy a jOOQ license, run my
platform on a non-OSS database. If somebody wishes to use a
commerical version of jOOQ I won't want to force them to recompile the
platform. For practical reasons, I would like them to run the same
signed releases that I've produced so that I can ensure that what they
are running is the same binaries that I've done my QA against.

Since what I've created is a platform, I also want to enable people to
use commercial versions of jOOQ and take advantage of the powerful
features of their DB. So the platform is DB agnostic, but the
extensions people write on top of my platform may be specific to a DB
or leverage commerical features.

Darren

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "jOOQ User Group" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jooq-user/DmhmO7J9380/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> jooq-user+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Lukas Eder]

Hi Darren,

I see, thanks for the explanations. What you have in mind for your own platform is perfectly fine with the jOOQ Open Source Edition licensing terms, of course. But I suspect that you will thus not integration-test your application against Oracle or SQL Server, though - only against PostgreSQL, MySQL, etc.?

It is still an interesting project, legally speaking. Your platform's commercial DB users will need to purchase a commercial jOOQ Edition to replace the binaries to work with Oracle / SQL Server. If they write extensions, it is immediately clear how this maps to a developer workstation license. If - however - they do not write extensions and only run your platform, then there are no commercial developer workstations involved. I guess, we'll have to sell server licenses or something similar in that case.

Another option is that you actually purchase the needed commercial licenses for your own integration tests, and then, deliver the binaries according to the rather liberal distribution terms of the jOOQ commercial licenses. That way, your users who do not develop extensions do not need to be licensed, as they are your own end users, subject to your own EULA. As soon as they want to access the jOOQ API from your platform for development, they will need to be licensed again. In a way, you'd "inherit" jOOQ's licensing model.

So, in essence, you have two options, and I've already offered such options to Apache CloudStack and Apache GORA as you know:

1) You remain completely Open Source, probably ASL 2.0 licensed (?) and ship the jOOQ Open Source Edition. That makes it very easy for you and your OSS DB users. However, there will be some open licensing questions for your commercial DB users

2) In addition to the above, you will become a dual-licensed software seller and potentially a jOOQ reseller, shipping a commercial jOOQ edition with a separately built platform of yours. This means you'll have to purchase jOOQ yourself, but you can thus collect license fees from your own commercial DB end users, who will not have to license jOOQ, unless they want to write extensions. You could even sell licenses for your own commercial DB extensions.

While 1) is very simple to achieve, 2) would be more user-friendly for your customers. Of course, 2) can still be implemented at a later stage.

I think, this is a very exciting cooperation, no matter how we settle this little legal challenge.

Cheers

Lukas

2014/1/23 Darren Shepherd <darren.s...@gmail.com>

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.