Update: Our Plans Regarding MSSQL and Other Proprietary Drivers #1616
Replies: 6 comments 14 replies
-
|
to make it very very clear... is it correct that this will not affect the MariaDB/MySQL OSS or Postgres drivers? |
Beta Was this translation helpful? Give feedback.
-
|
If they do decide to go AGPL it most likely will affect all of SQLx unless they plan to remove MSSQL from the code into its own crate that people can use. My suggestion would be to use Mozilla Public License 2.0 (MPL-2.0) instead which has a lot of the same protections as GPL based license but does not require things using it to be MPL and allows for static linking which GPL is a no go there last I knew. It also allows parts of code to be MPL for those who may copy parts of MPL code into their own code would just need to license the parts as MPL. It is a lot less strict and easier to handle. You wont make any extra money on this but at least people making changes to the code would need to redistribute those changes as open source. though it still allows for re-licensing to corporations so they could make changes private via a paid for license. |
Beta Was this translation helpful? Give feedback.
-
|
my concern is using this in: so i'm really hoping those remain possible, especially as postgres itself is open |
Beta Was this translation helpful? Give feedback.
-
|
Support for MySQL, PostgreSQL and SQLite will remain available under the MIT/Apache-2.0 dual license, free for all. Whatever scheme we end up going with, that's one of the invariants we want to maintain. The AGPL protected code would be behind optional features which should protect users who don't enable them from being subject to the license terms as it won't be compiled into the final binary. I don't think this is a novel approach as I'm pretty sure I've seen examples of other software which changes its license depending on what optional features are enabled or linked in, though I can't think of anything specific right at this moment. However, if that turns out to be legally untenable, a crate structure that completely separates the MIT/Apache code from the AGPL code wouldn't be out of the question. |
Beta Was this translation helpful? Give feedback.
-
|
Addendum: we're restructuring SQLx so that the AGPL code can live in its own source tree, to make things simpler. |
Beta Was this translation helpful? Give feedback.
-
|
Since the fee has not been set just yet for commercial-use / closed-source projects, I have the following questions:
|
Beta Was this translation helpful? Give feedback.
-
|
The MSSQL driver in versions that have already been released would remain available under the existing license, but it will not see any new releases under that license going forward. That said, the existing MSSQL driver is not ideal for production use anyway. While our documentation considers it to be in the same support tier as Postgres et al., it's missing the richness of type integrations that the other drivers enjoy, and it doesn't support TLS or any MSSQL-specific features. We'll be authoring a new driver from scratch. The pricing is still up in the air, but we do want to make sure it is affordable. The goal is to eventually fund full-time development, not to extract maximum profit. By the nature of the AGPL, it would still be open source, so it would be free for all to try. You would only need to pay for a license once you were ready to put your project into production on the public internet, if you don't want to be subject to the source disclosure requirement. |
Beta Was this translation helpful? Give feedback.
-
|
Any update on this? |
Beta Was this translation helpful? Give feedback.
-
|
Hi everyone, this is @tyt2y3, maintainer of SeaORM. I discovered this thread while reading the 0.7 change log. First of all, a big thanks to launchbadge for maintaining SQLx. It's been a while since we had the discussion, but I want to say:
this is my intention too. SeaORM is built on top of SQLx, and it made the task of supporting multiple database backends under the same codebase a lot easier (because SQLx has a nice, high-level API). At the same time, it offers users who wanted a query builder / ORM features an easy path to adopt SeaQuery / SeaORM. So we share mutual interests into growing the async Rust ecosystem. I think a major benefit of AGPL is that we (launchbadge and SeaQL) can collaborate in the open instead of behind closed doors. End users would also have the benefit of accessing all packages via a single source (crates.io). We (SeaQL) have a similar plan of providing integration to proprietary databases under a commercial license, where MSSQL would be a good starting point. As an ecosystem, it's better for us to align our policies and licenses. Such that users would not have the hassle to comply with two licenses. If you are interested in using SQLx / SeaORM + MSSQL in a company project, please let us know your preference. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks. I think a viable solution is just to have a |
Beta Was this translation helpful? Give feedback.
-
|
@tyt2y3 thoughts on MPL, and the shortcoming of AGPL? I happened into this thread, but have always worried about the same and other, similar, points to what @genusistimelord was saying... it would seem unacceptable and totally unreasonable, to me, for example, that if I use SeaORM or SQLx "pro" features in a project, that I would also then have to open-source that project explicitly using the AGPL; and that if I want to be shielded from AGPL "rot" I would have to jump through extraordinary hoops to separate that code into another project that others could incidentally take advantage of the without also being AGPL. Disclosing commercial use of open-source projects reliably, such that you could realistically enforce and seek damages against an infringing commercial use of your AGPL code is already an exercise in faith; many of the companies you seek to target with your commercializations (those operating MSSQL & other servers, that want your drivers) will already be willing to license in good faith or pay you even if you have a fully open-source version available, just for support. If you need to restrict commercial use of your source to paid licensing for economic reasons, why not simply mandate that all commercial products that use the source pay? This, I believe, is what VVVV does (maybe you could ask them how well it's working?). It's all honour system anyways; AGPL increases punishment if you catch the perpetrators of an infringement but it also severely kneecaps the open-source prospects for taking advantage of the code, which is the point of it being open. Sorry for the hastily-worded message: am tired and on phone so I may have jumbled the concepts and arguments up and down the paragraph; but ultimately I'm just questioning the warranty of the restrictiveness of the license being gravitated toward in this case. The AGPL is made to read like one hell of a stormy legal headache with utterly hilarious reach for anyone remotely interested in maintaining autonomy over their code and IP. |
Beta Was this translation helpful? Give feedback.
-
|
The issue mostly is no matter what, unless they allow you to purchase a sub license to override AGPL, their is no Hoop to jump through as anything that touches AGPL must become AGPL. Any middle source also must become AGPL, which in turn links back to your original Client needing to become AGPL. They will however, Offer a purchasable license last I knew though to avoid this. Just not sure how that really will work with AGPL or GPL style licenses since they state you can not sub license them. They will need to use a modified AGPL license which is not accepted by GNU last I checked. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with all the concerns, may be it's simpler to make the commercial library closed source in this case. |
Beta Was this translation helpful? Give feedback.
-
|
its a better idea OR only offering the -pro at a paid for license and no other license available. as i do agree proprietary API's do suck and are hard to maintain without $. I just hope whatever is there is reasonably priced. |
Beta Was this translation helpful? Give feedback.
-
|
Hi there, and good luck with your endeavours! I, for one, have been offering a commercially licensed jOOQ for 10 years this summer, and I haven't looked back a single time.
The Express edition is hardly purchased. It's a "legacy price plan", which I've been trying to re-activate with paid features (e.g. even better PostgreSQL support, for example for PostGIS). It's still not generating too much revenue, because the added value is either unknown to users or only rarely useful (e.g. SQL transformations, embeddables, synthetic objects). Most customers who license the Express edition probably do so because it includes support for Java 8 and 11.
To avoid confusion, the jOOQ Open Source Edition is very feature rich. The commercial only features include only a few power user features, including those from the code generator. Most code generation features are available for free to everyone.
jOOQ doesn't enforce its licensing, technically. It would be quite hard to get right both technically and legally (customers don't like "phoning home" in third parties for obvious reasons). From my experience, most "interesting" customers (see examples here: https://www.jooq.org/customers) are much more interested in compliance than optimising licenses. Money itself is hardly an issue. The process of purchasing costs more than the purchase itself. Just make it as simple as possible. E.g. for jOOQ, the tiered price plans are very convenient. Customers don't have to count the exact number of seats all the time, and update their licensing. Resellers also help manage accounts.
Look also into Flyway, Liquibase, which both run very successful businesses (Flyway has been acquired by Red Gate for a decent sum, for example). Flyway's pricing is more production usage based (per schema, I believe?). Liquibase requires a sales call, meaning it's super expensive and quite arbitrary, probably. There's also LLBLGen Pro by Frans Bouma, which is completely closed source, I believe. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your suggestions! Your endeavour is inspiring to us. I certainly am delighted to see you in this thread :) |
Beta Was this translation helpful? Give feedback.
-
|
What is the status for MSSQL support, is it actively being worked on? I’m about to start a closed-source commercial project soon where I would need to work with MSSQL and would prefer to use sqlx. I would rather pay for sqlx-pro than use any of the forks, but since this thread is the only information I could find, I assume that there are no new developments? |
Beta Was this translation helpful? Give feedback.
-
|
These plans are on indefinite hold due to some organizational changes. I'm not technically a LaunchBadge employee anymore, but we still have a very good working relationship and my current employer gives me time to work on SQLx. Should I leave my current job, my plan is to try working full-time on SQLx supported through Github Sponsors. It would be at that point that we'd consider bringing back the MSSQL driver, but as it stands right now I don't have the bandwidth needed to bring it up to par with the others. There's a fork of 0.6 being maintained by an outside contributor that is not associated with us, it still has the MSSQL driver: https://crates.io/crates/sqlx-oldapi |
Beta Was this translation helpful? Give feedback.
-
|
Thank you, @abonander, for the fast and detailed reply. I will use the fork until then. I fully understand the limitations of developing and maintaining an open source project next to a full-time job. I hope some solution can be achieved to allow the project to move forward, as it's a great library! |
Beta Was this translation helpful? Give feedback.
-
Howdy folks, this is an amendment to our previous announcement at the end of 2020: #909
Our plans didn't exactly materialize last year but I think we still had an excellent year of progress on SQLx, with a handful of new features released and old bugs fixed up. Our 0.5.x release of SQLx is the most popular and feature-complete yet!
Meanwhile at Launchbadge, we grew from a team size in the single digits to around a couple dozen people, and picked up several projects that kept us very busy over the last year. I'm surprised we managed to do everything with SQLx that we did, and I think focusing more on incremental development than flashy new features or large refactors helped us maintain a comfortable pace of releases.
We're still acutely interested in providing some way for the community to support continued development and maintenance of SQLx, and that will likely still involve some sort of paid support plan regarding the MSSQL and other potential drivers for proprietary databases. However, our plans have changed slightly, hopefully for the better.
Sometime after we published the above announcement, the folks who work on SeaORM approached us to suggest a different method of publishing the MSSQL driver. It didn't take much to convince us that this suggested way was the right approach.
What is the New Plan?
Instead of closing up the source of the MSSQL driver (and any other drivers we develop for proprietary databases in the future--I'm treating "the MSSQL driver" as a shorthand for that here), we will likely keep it open-source, but re-license it under the GNU Affero General Public License (AGPL).
The AGPL, in a nutshell, is a superset of the GPL: essentially, any derivative work of a licensed work (so in this context, any project using the MSSQL driver) that is distributed to the public must itself be licensed under the GPL and source must be made available on request. The Affero GPL places an additional stipulation that counts interacting with licensed software over a computer network to be distribution.
Thus, any web application accessible to the public using the AGPL-licensed MSSQL driver (which is the primary intended use case) must also be licensed under the AGPL and provide source upon request.
Any open source project using the MSSQL driver would be free to use it unrestricted, as long as it was also licensed under the AGPL.
Of course, this would preclude projects, which intend to remain closed-source, from using the MSSQL driver. However, for a fee, an organization could obtain a written contract from us exempting them from enforcement of the AGPL. Non-profit organizations would be able to apply for a similar exemption for zero or reduced cost.
This would allow us to keep the code for the driver in the open on Github, and free to try, while still providing a potential revenue stream.
This way, we don't have to deal with figuring out how to distribute a Rust crate in closed-source form, nor work out how to provide exemptions for open-source projects as that's built right into the license. And it would allow the community to continue to contribute to the driver and freely inspect its code.
We haven't worked out the details yet, but the idea is that the paid exemption would also allow closed-source use of integrations built on top of the MSSQL driver, like ORMs, but worded such that it doesn't necessarily bless any particular implementation.
We are also looking into ways that we can use the generated revenue to contribute back to the community that's sprung up around SQLx, but we're not sure what that would look like yet. Maybe just throwing around some developer time?
How Will Contributing to the AGPL-licensed Drivers Work?
We still have to do some further research here. For legal reasons, we may have to require contributors to assign copyright to us for changes made to the code in the differently licensed drivers. To compensate for this, we may have a bug bounty program or something. Feedback is welcome!
Currently, most of the code in the MSSQL driver was written by LaunchBadge employees, with the exception of some broad refactors and a couple of bugfixes by community contributors. We will probably have to hound them down for consent or just remove their code.
What About Pricing?
No idea (still)! There's not many examples of projects in similar situations that we can draw from. The closest one that we know of, which we already reference a lot, is jOOQ, which is a solution similar to Diesel but for Java (and much older).
At the time of writing this (Jan 6, 2021), jOOQ's lowest price is 99 Euro (excluding VAT) per developer per year to use SQL Server Express, Oracle DB, and MS Access, but also includes basic support as well as a bunch of codegen features that aren't included in the FOSS version.
That seems like a pretty fair price but the feature set doesn't directly line up with our intended offering. Our codegen features would not be placed behind a paywall, only the integration with MSSQL. And it's hard to say whether it would be better to have separate offerings per driver or just have a single offering that covers all proprietary drivers.
We already provide basic support to our community for free on a best-effort basis via Discord, our issue tracker and this Discussion board, so it's hard to say what more we could offer there except dedicated support hours and guaranteed responses.
The per-developer part would be difficult to enforce for us and so would rely on the honor system, but that may not be an issue since businesses prefer everything on the up and up.
If you know of an example of a similar product with a different pricing model that we could compare this with, please feel free to share it with us here.
What's the Timeframe on All This?
Not sure! The changeover, of course, will coincide with a major version release in order to not break any existing usage.
We already have a bunch of features earmarked for 0.6.0 that are completely orthogonal to this so it may or may not happen on that release.
We're also going to give some time for the community to give us feedback on this proposal. If you have an opinion on anything mentioned here, please share it with us in this thread!
Beta Was this translation helpful? Give feedback.
All reactions