Hi Lukas, thanks a lot for insightful response, from the licensing point of view that's the best outcome I could imagine. By the way without JOOQ, the only alternative for parsing DB metadata and SQL is opensource code of Squirrel SQL Client <http://squirrel-sql.sourceforge.net/>, but it is intertwined with Java Swing API and lot of harder to use from the point of API, documentation, support, etc.
I'm assuming you mean the JdbcDatabase from jOOQ-meta? Sorry I made a mistake. I have meant descendants of org.jooq.meta.AbstractDatabase (PostgresDatabase, MySQLDatabase, ...), I checked the code, and these implementations should be more performant than general JdbcDatabase implementation. Thanks once more, I will let you know about any serious progress of this project. Marek pi 26. 7. 2019 o 17:27 Lukas Eder <[email protected]> napísal(a): > Hi Marek, > > Thank you very much for following up. > > On Fri, Jul 26, 2019 at 5:07 PM Marek Gregor <[email protected]> > wrote: > >> Hi Lukas, >> >> thank you, that's amazing I didn't realize before, that this feature is >> also implementable. For my initial use case JdbcDatabase and it's >> descendands is far enough - users of my app will pass JDBC connection >> params, and the app will display database metadata and allow executing >> standardized SQL processed by JOOQ Parser to get data for reports. >> > > I'm assuming you mean the JdbcDatabase from jOOQ-meta? Yes, that should be > sufficient if the schema is not too big. Unfortunately, its backing JDBC > DatabaseMetaData is not the fastest API when schemas get big, so queries > against that meta data might become a bit slow on some systems. > > >> But this brings to my head another question about JOOQ licensing ... >> I know that in standard case, model generation (from metadata) and >> writing parseable SQL is done by developer (therefore I think per developer >> license is reasonable here). But in my case this JOOQ functionality will be >> used by application users and not developers, albeit without directly using >> JOOQ java API. My app takes this case into the extreme, because my Jupiter >> Notebook Kernel will also allow execute standard java code (besides SQL >> execution) to further process SQL results (java code execution will be >> definitely available *without *JOOQ libraries in classpath). Therefore >> the essential question is, if the license cost will be counted per >> developer or per app user for my app. >> > > We have your use-case covered in our licensing FAQ: > https://www.jooq.org/legal/licensing/#faq-commercial > > All developers who use the jOOQ API will need to be licensed. If your > users do not use the jOOQ API directly, they profit from the free, included > distribution right that every license ships with. Even if they write SQL > code that you parse via the jOOQ API, our current license considers such > users non-developers with respect to the jOOQ license and jOOQ API. In a > similar way, frontend developers who only code JavaScript and call services > that use jOOQ behind the scenes do not need a license, if the jOOQ API is > not exposed through the services. > > So, you need as many licenses as there are developers working with jOOQ on > your own software. > > Note, should you need to expose the jOOQ API to your users, we usually > negotiate an OEM license that is not covered by our standard price plans. > Alternatively, you could ship the jOOQ Open Source Edition and let your > users purchase runtime licenses from us directly. > > >> Possibility to create "universal report" (by using standard, translatable >> SQL) executable on any supported database with the same schema is one of >> the amazing features, which are possible to do with JOOQ. There are a lot >> of applications, which support multiple databases (e.g. like JIRA >> internally using Hibernate) and the possibility for company to create >> universal report executable on any db engine is one of the big "sellpoints" >> of my proposal. There are also other nice features possible, like static >> validation of existing SQL queries (reports) when schema is upgraded etc. >> But if it makes any significant change in JOOQ licensing for me I am ready >> to postpone this feature for now and not to present it as planned for first >> version (I am planning to start Kickstarter project for it), and use JOOQ >> only for database metadata analysis tool and native SQL execution wrapper. >> > > I'm happy to hear more about the details of that use case, but as I can > tell right now, this doesn't sound like something that would modify your > licensing situation - as long as your users do not work *directly* with the > jOOQ API. > > *For the avoidance of doubt* (as this is a public mailing list that is > archived), my responses are valid today on July 25, 2019 given the current > jOOQ License and Maintenance Agreement > > https://www.jooq.org/legal/180607_jOOQ_License_and_Maintenance_Agreement.pdf > > > -- > 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/2wPGf6uB5fI/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jooq-user/CAB4ELO7JeJsanzuZazdQdOWK7NRaqhSARr-yoRDFM4Obx0nPwg%40mail.gmail.com > <https://groups.google.com/d/msgid/jooq-user/CAB4ELO7JeJsanzuZazdQdOWK7NRaqhSARr-yoRDFM4Obx0nPwg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/CACtQWuSCNkLifeaXbsPBbbcqdbb00WgQToWokH67r_jzrANiUw%40mail.gmail.com.
