Hi Luke, I think it would be interesting to learn about the process you'll follow (or have already followed) to ensure the relicense process is done correctly to avoid problems in the future. I mean that, you probably received improvements and patches from external contributors, and those contribution's copyrights belong to their creators so you wouldn't be able to relicense them without their express consent. This is problematic, but on the other hand by virtue of being GPL in theory a project might receive many more contributions due to the libre spirit that the license infuses to the project, so the project might have benefited to a greater degree from being (A)GPL.

One usual mechanism for this is to require a CLA on all contributions, with a copyright assignment so you become the owner of the contribution (and probably cope with a lower amount of people willing to contribute, as some consider CLAs as harmful to Open Source). But of course this had to be put in place from the beginning, which I don't know if it was.

Other solutions are to reimplement all parts of which you don't own the copyright, or to ask one by one for copyright assignment from all previous contributors. In this HN thread they talk precisely about this: https://news.ycombinator.com/item?id=24954772

In your case the relicense is to Apache 2 instead of proprietary, but I think the same set of issues apply. I think we'd learn a lot if you could tell us about your case, so there are more examples about the fine detail of relicensing Open Source projects.

Yes - as you mention I wrote about it in response to another point. Most of the external contributions to TerminusDB have been to the clients. The python community in particular has contributed extensively to that TDB client. The JS and python clients were always Apache 2 as we thought that people might want to embed.

The contributors to the server & core, which is more challenging from a getting started perspective (prolog server and Rust triple store), have had fewer active outside contributors. I was looking at these slides (17 - 22 here: https://www.slideshare.net/slidarko/mmadt-a-virtual-machinea...) earlier in the week and remarked on how few devs actually worked on most of the major DB and OSS projects. Tinkerpop is effectively written by 1.5 people! But that largely tallies with our experience. Small number of focused devs keeping a lot of the architecture in their heads while they write the code.

Those that did contribute, and we are eternally grateful to them, were happy to allow their code to be re-licensed. But I wrote to all individually and waited until they had time to think before taking any other steps. If we had been moving to a proprietary license, I think it would have been harder to get sign off, but that is pure speculation!

> If we had been moving to a proprietary license, I think it would have been harder to get sign off, but that is pure speculation!

Well good news for you then: There’s nothing stopping you making all future changes proprietary now that it’s Apache licensed. You can effectively relicense the project however you want now, attribution notwithstanding.

Oh, I just saw that you replied to this effect in another comment - https://news.ycombinator.com/item?id=25348518

Did you think about using dual licensing? GPL + Proprietary for paid users?

We did think about that, but our economic model is to focus on income for SaaS collaboration through TerminusHub. We are a distributed revision control database - so the model is a bit like git and github (only they piggy backed on an already successful open source project and we have to build both open source and hub!).

We really don't like the 'traditional' open source economic model - with a community version and all the good features in a proprietary enterprise edition. The community version is almost necessarily weak and you end up annoying your users. We'd prefer to keep as open as possible and have a commercial SaaS or open core model.

> We'd prefer to keep as open as possible and have a commercial SaaS or open core model

Isn't this opposed to this?

> We really don't like the 'traditional' open source economic model - with a community version and all the good features in a proprietary enterprise edition

This is what I thought open core was, am I wrong?

A commercial SaaS model would make a lot of sense for a project that wants to remain completely free software, though. You are the people who know your code best, and it makes sense to trust and pay you to run it reliably.

We want the database to have 100% of the features and not have to have a proprietary split between the database we offer to enterprise and to our open source community.

We want people to build stuff on our database whether they are companies or individuals and we don't want to encumber this with stumbling blocks.

We intend to do this by having a SaaS revenue model which doesn't require we hobble anything in the database in order to make money.

Kudos to you, I'm not a huge fan of open source products that have proprietary features neither.

I wish you success!

It’s great that you welcome a GPL fork, perhaps there is room for one.

Thanks for being honest and open about all of this.

Nice, I was looking at your project the other day but couldn't use GPL. Now we can give it a try.

That's really good to hear - and it is exactly the sort of situation we had in mind when we started discussing the license shift

Congratulation for choosing a free License like BSD/Apache/MIT.

Only more freedoms to the developers, not end users.

>not end users.

Pff, the have not more freedom with a GPL, unless they are developers. What freedom do you have when you use Linux but never read or change the source-code?

The freedom for the user that comes with using Linux as a result of it being GPL-licensed is that entities have to contribute any changes they make to the kernel back to the community if they intend to distribute their modified, potentially improved kernel. This results in a better end-result as the kernel can integrate changes that others wrote if they provide a better experience in some way.

Really? And whats with all the proprietary blobs? The Modules (like nvidia), for the end-user it changes absolutely nothing, having bad firmware your wifi will not work, the license is absolutely not important for the end-user. Nearly no one cares that most Androids have stoneage Linux kernels, whats important for them is that the Android-Runtime (aka Play-store) can download and execute "Apps".

>potentially improved kernel

Or potentially worsened kernel, which now sits in you closed down IoT device, again the license is NOT important for the normal end-user.

It is wrong that the license is absolutely not important for the end-user. Most users might not directly care about the license of the software they use, especially between free software licenses, but they might care about the consequences even if they are not aware of the causal relation.

You might not know anything about how the engine works in your car but it is still important that it is made correctly. The whole Free Software movement targets end users and works on the assumption that these questions are important for them.

Licenses might look like non significant technical details to most end users, but they are not, and many people not in the field are able to understand the subtleties. We should consider people's ignorance inevitable. This is not a fact we can't do anything about. Software is omnipresent in our societies and as massive effects on them. They have the right to know, should care, and actually often do if you don't push them. I know, I tried.

> all the proprietary blobs

Which ones? Nvidia seems to the exception here, and only concerns Nvidia's hardware anyway. If you think of Android drivers, they are in user space libraries (Had the Linux kernel been in a non-copyleft license, they would probably live in kernel space and working out the shitty situation of Android with the kernel would be far more difficult.

Thanks to the Linux kernel being under GPL, Android vendors and manufacturers are forced to release their kernel sources, which allows projects like Lineage OS and other Android derivatives to exist.

> or potentially worsened kernel

I can't imagine why kernel developers would accept a patch that knowingly worsens the kernel upstream.

The GPL forces shitty hardware makers to release their shitty code but nobody is forced to merge it upstream.

bad closed firmware are unfortunate but I don't know what it has to do with Linux being under the GPL.

> Really? And whats with all the proprietary blobs? The Modules (like nvidia), for the end-user it changes absolutely nothing, having bad firmware your wifi will not work, the license is absolutely not important for the end-user.

I think the sibling comment covered most of this well, but I just wanted to add that relying on closed-source drivers is far from necessary with many setups of modern day Linux. All of the drivers on my computer, save for the processor microcode, are open source and for the most part, bug free. In fact, they are probably mostly bug free because they have so many eyes on them.

> Nearly no one cares that most Androids have stoneage Linux kernels, whats important for them is that the Android-Runtime (aka Play-store) can download and execute "Apps".

While many users might not know this is the reason, I think the copyleft license of Linux has let it become where it is currently, as it forces vendors who might otherwise release proprietary blobs addressing issues must instead release the changes with a license such that it can be improved upstream. This pushes companies who spend the energy to fix the bugs in an otherwise good kernel to give those changes back to the community, similar to how the companies took from the community in order to use the kernel.

> > potentially improved kernel

> Or potentially worsened kernel, which now sits in you closed down IoT device, again the license is NOT important for the normal end-user.

Well I think this is a great argument in favor of GPLv3 over GPLv2, which bans this (see [1]). This is another reason why end users could care about the license used in the code. GPLv3 code guarantees the end user the freedom to modify the code and run it on their device (or apply other people's modifications). Though I will concede that this is less of an end-user-centric idea because it requires a decent level of technical competency.

[1]: https://en.wikipedia.org/wiki/Tivoization

I like to think of it as "permissionless" license vs "permissioned" license.

I was thinking free as NOT "server side" stuff like MongoDB Cockroach and so on, you know as in the Article described.

Like when they say developer freedom is beating code freedom, because it doesn't impose restrictions on the developer? i.e. permission(less)

Have you even read the article? I said it's good to choose a free license and not:

https://www.mongodb.com/licensing/server-side-public-license

I think you are looking for an argument while I'm agreeing with you.

Mongo license would be a permissioned license however