Invalid BSL 1.1 Change Date and Change License

[voxpelli]

To ensure consistent expectations BSL 1.1 enforced limitations on eg Change Date and Change License.

First, we set a cap of four years for the duration of the time window prior to code becoming FOSS. That said, we encourage a shorter window (and for MariaDB MaxScale, the window is between two and three years).

Current change date seems to be 5 years into the future: https://github.com/clockworklabs/SpacetimeDB/blame/8eb1743b75435c7b3b9ea7179c923262105b2b2b/LICENSE.txt#L24

One year more than the max allowed under BSL 1.1

Second, we now require the Change License to be GPL compatible with either GPLv2, GPLv3, or any other license that can be combined properly with GPL software

AGPL 3.0 is set as the change license: https://github.com/clockworklabs/SpacetimeDB/blame/8eb1743b75435c7b3b9ea7179c923262105b2b2b/LICENSE.txt#L26

Though AGPL 3.0 is not a GPL 2.0 compatible license: https://www.gnu.org/licenses/license-list.en.html#AGPLv3.0

Hence violators this part of the BSL 1.1:

software provided under the Change License can be included in a program with software provided under GPL Version 2.0 or a later version

On top of this, you are using a modified AGPL 3.0 license even, which I would highly discourage, as modified licenses by their very nature are not OSI approved and sets unclear expectations and has unclear compatibility with other licenses.

[cloutiertyler]

Hi @voxpelli! Thanks for bringing your concerns to my attention. With respect to the change date, we intentionally set the change date to be 5 years in the future so that it would fall back to the fourth anniversary as specified in the following clause of the BSL 1.1 which is included in the LICENSE.txt file:

Effective on the Change Date, or the fourth anniversary of the first publicly
available distribution of a specific version of the Licensed Work under this
License, whichever comes first, the Licensor hereby grants you rights under
the terms of the Change License, and the rights granted in the paragraph
above terminate.

As you can see, in this case our change date is irrelevant because the fourth anniversary of the first publicly available distribution of SpacetimeDB version 0.6.0 was on August 9th.

With regards to your second point on the AGPLv3.0, the BSL specifies as you note not GPLv2 but GPLv2 or a later version. In this case we are relying on this interpretation from the FSF:

Please note that the GNU AGPL is not compatible with GPLv2. It is also technically not compatible with GPLv3 in a strict sense: you cannot take code released under the GNU AGPL and convey or modify it however you like under the terms of GPLv3, or vice versa. However, you are allowed to combine separate modules or source files released under both of those licenses in a single project, which will provide many programmers with all the permission they need to make the programs they want. See section 13 of both licenses for details.

Furthermore our modified version of the AGPLv3.0 license by way of the linking exception is more permissive, not less, and thus is more in the spirit of the OSI OSS criteria, not less.

I take your point on unclear compatibility with other licenses, but we felt this was the only way to be able to offer our software under a free software license which would both ensure that we get modifications to the source code back (by way of clause 13), while still being permissive enough for people to use SpacetimeDB as a linked library without forcing them to make their own code available under the AGPL.

For these two reasons, we feel that our BSL 1.1 license is valid both in law and in spirit.

I welcome your comments!

[voxpelli]

With respect to the change date, we intentionally set the change date to be 5 years in the future so that it would fall back to the fourth anniversary as specified in the following clause of the BSL 1.1 which is included in the LICENSE.txt file:

Effective on the Change Date, or the fourth anniversary of the first publicly

available distribution of a specific version of the Licensed Work under this

License, whichever comes first, the Licensor hereby grants you rights under

the terms of the Change License, and the rights granted in the paragraph

above terminate.

As you can see, in this case the change date because the fourth anniversary of the first publicly available distribution of SpacetimeDB version 0.6.0 which was August 9th.

Why not specify the anniversary date yourself instead of relying on people knowing the ins and outs of the license?

---

In regards to AGPL 3.0: Have you checked with lawyers and/or MariaDB that your interpretation is valid?

The FSF writes this about AGPL 3.0, emphasis mine:

Please note that the GNU AGPL is not compatible with GPLv2. It is also technically not compatible with GPLv3 in a strict sense: you cannot take code released under the GNU AGPL and convey or modify it however you like under the terms of GPLv3, or vice versa. However, you are allowed to combine separate modules or source files released under both of those licenses in a single project, which will provide many programmers with all the permission they need to make the programs they want.

MariaDB writes, emphasis mine:

where “compatible” means that software provided under the Change License can be included in a program with software provided under GPL Version 2.0 or a later version

So it's a question whether "you are allowed to combine separate modules or source files released under both of those licenses in a single project" matches what MariaDB says when they write "can be included in a program".

The GPLv3 license says, emphasis mine:

13. Use with the GNU Affero General Public License.

Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU Affero General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the special requirements of the GNU Affero General Public License, section 13, concerning interaction through a network will apply to the combination as such.

So one can combine AGPL3 with GPL3 but the resulting combination will have to follow AGPL3.

Also, the exception is for AGPL3 specifically, how your modification of the AGPL3 affects this compatibility is a bit unclear to me.

[marvin-hansen]

I really like spacetime db, I believe it's an amazing project, and it's definitely one of the most interesting innovations in the field.

However I would like to raise the question of if the team is aware that many large corporations completely ban AGPL code?

Google being the most vocal one:

https://opensource.google/documentation/reference/using/agpl-policy

Other companies have these bans in place but don't make it public to prevent unwanted publicity.

The CEO of Sagemath has explained the problem quite well.

http://sagemath.blogspot.com/2016/10/rethinkdb-must-relicense-now-what-is.html?m=1

I want SpaceTimeDB to succeed and become a viable alternative to existing databases and I want to see a vibrant community around this project.

However if the AGPL path as laid out now will be executed, I cannot even start building for the exact same reasons Google can't use it. Hence the AGPL license is a complete non-starter for commercial development.

Therefore I would like to ask the team if the decision for AGPL is finalized or are you open to any other licensing option that allows commercial development?

Obviously my decision may not affect anything here, but I have to point out that no larger corporation with a clear open source policy will ever allow AGPL licensed code next to their commercial code. Even GPL with classpath exception is seen more favorable.

Is preventing companies from using your database the actual goal?

I'm asking because I simply cannot believe that any of this has been decided deliberately and maybe there wasn't even awareness of the AGPL ban so please share a bit more insights if the team really wishes to continue the AGPL path.

Thank you
Marvin

[cloutiertyler]

Why not specify the anniversary date yourself instead of relying on people knowing the ins and outs of the license?

@voxpelli The only reason we did this is that we weren't sure the exact date that we'd make it publicly available, and we wanted to do 4 years, so it was just easier to set it once than to have to keep updating it.

We've checked with our own lawyers, but you bring up a good point with respect to MariaDB. It might be worth it to reach out to them to get their opinion on our usage if they have the bandwidth to offer it.

The compatibility question is so tricky. Your analysis makes sense to me, but exactly what is allowed is not so clear.

[cloutiertyler]

Google being the most vocal one:

@marvin-hansen This is the exact reason that we added the linking clause. Google's main complaint with the AGPL is that it converts anything it's linked with. So for example, if a Google engineer created a service linked with an AGPL library, then that entire service would need to be licensed under the AGPL and made public.

They spell out their exact concern clearly:

Using AGPL software requires that anything it links to must also be licensed under the AGPL. Even if you think you aren’t linking to anything important, it still presents a huge risk to Google because of how integrated much of our code is.

Whereas, given SpacetimeDB's linking exception, if that Google engineer made a service which linked with SpacetimeDB, Google would be under no obligation to license the service under the AGPL.

The only point of the AGPL for us is that we want changes to SpacetimeDB back, no matter if you're distributing your modified version of SpacetimeDB or you're running a modified version in your backend. We have no intention or desire to for the AGPL to spread to any other code besides SpacetimeDB itself.

We are, however, open to changing to any open source or free software license which make modified versions of SpacetimeDB available to users/customers. The AGPL with linking exception was quite intentionally chosen for that purpose, but if there's a better one which achieves that goal, please let me know.

[marvin-hansen]

@cloutiertyler Thank you for your elaboration.
The problem is clear:

"By licensing with the AGPL, these companies ensure that no one besides themselves can monetize the project.
The collateral damage in this bargain, however, is developers. Developers want to get stuff done with a minimum of overhead (be it infrastructure or lawyers).."

Don’t believe the hype, AGPL open source licensing is toxic and unpopular

The central point of contention, as stated by voxpelli, is the ludicrous compatibility clause. And frankly, this is what Google didn't say in their explanation. To make the practical problem really clear, if I were to use anything from this project and my work under whatever license gains contributors over the next four years, then when your BSL converts into AGPL, I would have to convert my (derived) work into AGPL license due to the absurd AGPL compatibility clause and that basically gives my work the death-shot by making it toxic and deeply unpopular with contributors. Besides, changing license usually requires approval from all past and current contributors and given how unpopular AGPL is, I may not even be able to get there in the first place complicating matters even more. Also, this is a legal nightmare for those who were using my derived work as I put them in the same ugly spot as I end up in. Why? Because I mixed code with your project.. Not going to happen.

Intent or not, I am forced to decide whether to look like a complete idiot to my stakeholders, or dropping a newcomer project causing all this mess and, well, that's roughly speaking the problem with the AGPL. I don't think anyone wants that.

One of my projects was recently accepted into the Linux Foundation (LF) and they have a truly excellent legal team specialized in OSS so I suggest to talk to the legal team at the LF because they know OSS inside out and work frequently with companies with vested commercial interest.

[cloutiertyler]

if I were to use anything from this project and my work under whatever license gains contributors over the next four years, then when your BSL converts into AGPL, I would have to convert my (derived) work into AGPL license due to the absurd AGPL compatibility clause and that basically gives my work the death-shot by making it toxic and deeply unpopular with contributors

I suppose I don't understand this. You would only need to do this if you were making a modified version of SpacetimeDB, and in that case, we're just asking that SpacetimeDB itself and no other part of your code be released on the AGPL.

Am I missing something? Why would you need to convert anything other than SpacetimeDB itself? Nothing that you link to it needs be converted. Could you give me a specific example of what you're concerned about?

Could you introduce me to someone at the LF? I would love to speak with them!

[voxpelli]

Using AGPL software requires that anything it links to must also be licensed under the AGPL. Even if you think you aren’t linking to anything important, it still presents a huge risk to Google because of how integrated much of our code is.

Whereas, given SpacetimeDB's linking exception, if that Google engineer made a service which linked with SpacetimeDB, Google would be under no obligation to license the service under the AGPL.

Due to the custom nature of that exception they would have to get special permission from legal instead though, as it doesn't fall under any license that has a blanket permission from legal. And getting special permission from legal is in my experience not very easy to get and for smaller companies also rather costly.

The only reason we did this is that we weren't sure the exact date that we'd make it publicly available, and we wanted to do 4 years, so it was just easier to set it once than to have to keep updating it.

In the FAQ MariaDB explicitly points out that the Change Date can be calculated different for different companies and that there for eg. MariaDB is a new Change Date for every non-patch release.

So leaving it up to users to figure it out leaves room for interpretation and possible disagreements.

We've checked with our own lawyers, but you bring up a good point with respect to MariaDB. It might be worth it to reach out to them to get their opinion on our usage if they have the bandwidth to offer it.

After my post I sent them a general inquiry on there stance on AGPL compatibility as well as Hashicorp's Apache2 usage, but have yet to receive a response. I guess it could be good for you to send one yourself.

[marvin-hansen]

@cloutiertyler

All I initially intended was to use SpaceTimeDB as a backend server for a commercial SaaS system.
Pretty normal except the AGPL license doesn't permit that on ideological copyleft grounds. Complete non-starter.

https://snyk.io/learn/agpl-license/#

I already decided against using SpaceTimeDB and deleted all repos and all code because your licensing is
too restrictive, overly complicated, and only causes 99 legal problems.
I simply don't have the time for that.

I can introduce you to someone on the LF legal team. These guys should help you to come up with a sensible solution that is fair and works for everyone.

Feel free to send me an email and I will get you in you touch with the right person.

http://marvin-hansen.tel/

Update:
Somebody asked what exactly the problem with AGPL & SAAS is all about.

It's AGPLv3 section 13 and specifically the notion of derived work. This is different from modifying the AGPL code itself because modification means ideas changing the code of SpaceTimeDB.

Derived work, however, must be licensed under AGPL. To cite from an interpretation of the clause:

"Scenario: AGPL component becomes part of your program, e.g. by including it as a library. Then your program is a derivative work of the AGPLv3-covered component. While you not have modified that component, the Program as a whole (including the AGPLv3 parts) is still a modified version compared to the original AGPLv3 component. And since users are interacting with your SaaS program, AGPLv3 section 13 triggers. You would be required to provide the Corresponding Source for the entire Program, including the parts that you have written."

https://opensource.stackexchange.com/questions/13256/using-agpl-package-for-a-saas

The exact problem in this case comes from the fact that all WASM code must use certain custom macros, for example, println!, because WASM doesn't have the underlying libC meaning these alternatives are required but if any of those falls under AGPL after a certain number of years, then, here your problems start to propagate.

AGPL was specifically designed for exactly the situation to force SAAS providers to publish their source code.

https://fossa.com/blog/open-source-software-licenses-101-agpl-license/#:~:text=AGPL%20applies%20primarily%20to%20software,licenses%2C%20it%20has%20stringent%20requirements.

I cannot see how the classpath exemption will solve anything here
other than the optics and that is a fundamental problem with very real consequences that makes this project untouchable for SAAS.

[voxpelli]

@marvin-hansen Maybe there should be a separate issue about this general concern with AGPL as this issue points at the possible incompatibility between BSL 1.1 and AGPL3 rather than about the suitability of AGPL3 at large

[marvin-hansen]

@voxpelli True. I agree with you.

Would you please be so kind and open a separate issue for that? You got a good handle on summarizing the key points in a constructive way.

Frankly, I cannot allocate any more time to this thorny licensing issue than I already did.

[voxpelli]

@marvin-hansen I personally try to stay out of whether AGPL is a good license or not, so I'll skip it as well 😌