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.
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.