Hi Timm, 2016-01-11 17:41 GMT+01:00 Timm <[email protected]>:
> In the past, Apache projects or Red Hat products concluded with not >> proceeding with a jOOQ integration, because dual licensing was against >> their general strategy / philosophy. This doesn't have to be the case for >> you, though. >> > Dual licensing would not be an option for us either. > May I ask why? Can you disclose the product that you're considering jOOQ for? > Regarding your specific questions: >> >> >> >> - *Compile time requirements: Can oracle specific JOOQ features >> be compiled with the open source version or does this require a commercial >> JOOQ license?* >> >> >> >> This will require a commercial jOOQ license, as most Oracle specific jOOQ >> features are not available from the Open Source edition. >> > >> >> - *Runtime requirements: I guess at least here any contributor >> who would want to run tests with Oracle would require a commercial JOOQ >> license?* >> >> >> >> Yes - although, do note that the commercial license is a floating >> license, not a named user license. I.e. only as many licenses are needed as >> there are contributors developing with *jOOQ at the same time*. >> > > I am not sure how a floating license would be practical in a decentralized > community based development model. > That depends on the community size, indeed. With a large number of contributors, a flat rate might be more suitable. We currently have flat rates for 100+ license volumes: http://www.jooq.org/download/price-plans The volume could be adapted as needed, of course. The only option I can see here would be to use it on a CI server to make > sure that the oracle integration tests still work. > Yes, that's certainly not an usual use-case, and is covered by the free distribution right. > The killer however is the compile time dependency. I wasn't fully sure how > the oracle features were implemented at the moment and I was hoping that > its API would be exposed in the free version and it would simply fail to > load implementations at runtime. This means that any oracle specific code > would need to be completely separated into its own module that would be > separately developed by JOOQ license holders. > Yes, I can see how this causes some technical issues, although the two versions are almost equivalent (including line numbers). Any code section that really needs to be customised for Oracle would need to be separated out of the "main" code base anyway, in some way. If this only happens once or twice, there are workarounds (e.g. jOOQ internally avoids hard ojdbc dependencies via reflection). If, however, you plan to implement a significant PL/SQL integration, there would be no corresponding PostgreSQL equivalent anyway, and factoring out the module in an independent Maven artifact wouldn't be so wrong. In any case, we're very open to discussing possible alternative models. Thus far, I've displayed the default offering. Other options are certainly feasible, too. Did you ever think of making JOOQ freely available for Oracle XE? To me > this sounds like a win win, the open source community could use the > goodness of JOOQ in the development of oracle targeted projects while JOOQ > would sell licenses once people have to deploy them to an oracle production > instance. In other words this would be 1 license per deployer, rather than > 1 license per developer. > This would be a clear win-lose where "lose" is our part. Having free-of-charge commercial versions would mean that many prospects would delay any purchasing decision while using Oracle XE for as long as possible, or develop against XE and ship to Oracle Enterprise Edition. There are two ways to catch up with the lost revenue: 1. Reduce feature scope. We're still evaluating this option. So far, we haven't found a satisfying solution to where we want to remove features. 2. Asking for server license fees. Our competitors in the Scala ecosystem do this (Typesafe with Slick). The costs of going to production with their license is really out of proportion for the value offered in production (as opposed to development). We like our developer workstation licenses. You get value out of jOOQ while developing. Your end users don't get any value out of jOOQ, they will not be interested in paying for a component of their application. Having said so, there are many alternative ways to tailor a custom license agreement with specific projects. In order to better understand your situation, I'd love to learn more about your product, plans, community, and perhaps alternative ideas. Best Regards, Lukas -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
