I’m back behind a proper keyboard :)

Since this is turning out lengthy, I’ll split it into two parts:

Q&A bit

So if I am understanding you correctly, no license can force contributors to release under a particular license (as I had mistakenly assumed was the case with AGPLv3) […]

Correct. A FOSS (or other) license of a project deals only with the relationship between the 1) copyright holders / licensees on one side, and 2) the licensees (e.g. users or devs of downstream projects).

That is why this license is referred to as the outbound license.

[…], but the AGPLv3 merely requires the original author respect whatever license said contributor did release their contribution under? Which in your example shows how even doing so, it could still potentially allow the original author licensed under AGPLv3 to close the source again (not easy but still possible).

This has nothing to do with AGPL-3.0 itself, but copyright itself. Without some sort of license (or statutory limitations or exception / fair use), no-one but the author(s) themselves are allowed to do anything with the code.

So in order to copy, use, implement, modify etc. the code from others, the project needs to have have the right rights (i.e. license). And if that license has some obligations attached, to meet them.

In any case you have to meet the basic requirements of copyright law as well. At the very least store the notices of the following two:

• attribution – list the copyright holders and/or authors (esp. in jurisdictions which have moral rights),
• license(s) – since the license is the only thing that gives you the right to use the code, you are very well advised to keep both the license notices and the license text around.

That also strikes me as potentially messy and a lot of extra work for @deimos since IIRC some licenses require attribution... so if a whole load of contributors released them under an attribution license, I assume @deimos would be required to be compliant with every one of those should he accept the contributions?

Attribution is practically unavoidable, because a) most licenses require it anyway, and if that fails b) copyright laws of many jurisdictions require it anyway (e.g. EU).

And if that’s not enough, then there is also c) sometimes you will want to reach the original author(s) of the code for legal or technical reasons, so storing the info makes sense for when things go wrong. Let me tell you, finding the original upstream of a file you found in your codebase and if there’s no names or links in it, is a huge PITA and includes (currently still) expensive specialised software. I would suspect the onus on a FOSS project to be much lower than on a corporation in this case, but still better to put a little effort upfront than to have to do some serious archaeology later.

The good news is that attribution is the author’s right, not obligation. And you are obliged only insofar as they made use of that right. Which means that if the author hasn’t listed themselves, you don’t have to hunt them down individually.

In short:

• If the authors and copyright holders are named in the code (or associated files, e.g. NOTICE, AUTHORS, README), make sure you keep it.
• If authors / copyright holders are not listed, you need to decide, but should be fine if you don’t. You can always add it later. I would err on the side that they want to be listed especially if you copied parts of a code and not e.g. the whole library.
• If there is licensing info, keep it.
• If there is no licensing info, don’t use the code at all, or reach the author/copyright holder (ha, handy now, eh?!) and ask them for a license.

Also, if you don't mind sharing a personal opinion: Do you think once contributions start being accepted with various licenses attached to them, […]

Well, Tildes already includes code with other licenses attached that need to be complied with and authors need to be attributed. Just see the JS scripts.

So the fact is that Tildes will need to cope with different inbound licenses anyway – i.e. licenses that it obtained from its upstream in order to use the upstream software or contributions.

The question is only whether you want to simplify this process at least for the contributions that are made directly to the Tildes project from its own community. And this is what Contribution Agreements and (other) social contracts are for.

[…] that tildes being AGPLv3 is sufficient to show a commitment to permanently remaining opensource, or is the fact it could still potentially be closed again enough to make you doubt the commitment? Basically what I'm asking is should the other solutions you mentioned (I=O CLA, FLA, Commons Conservancy) be looked at instead of AGPLv3 if @deimos wants to truly show his commitment to remaining opensource?

First off, neither AGPL-3.0 nor any other outbound FOSS license can guarantee that the development will continue. If it happens behind closed doors and is not published (or publicly deployed), no-one can ask for source code.

Secondly, and this was mentioned in a different comment, the author(s) can always change the license (if they agree on it). But this is only true for the future releases. E.g. if tildes-2.4 is released under AGPL-3.0, but then all authors agree to change the license to MIT (or even closed source), that will only be true for the next version – e.g. tildes-2.5 or just the commit right after 2.4. All previous, already released/published versions remain under the licenses they were released under.

The inbound and outbound licensing are two separate fronts you have to address.

Back to the initial question

Ultimately, the right question is: “What are the risks you are trying to avoid?”

Do you fear someone might fork Tildes and never contribute “back” (to the community, by releasing FOSS code) ↦ as this is SaaS, go for AGPL as outbound license.

Do you fear the code will not be used much outside of tildes.net and actively want to promote as many Tildes forks as possible and let everyone do whatever they want ↦ go for a permissive outbound license, instead.

Do you fear that in the future you will have to change the license to accommodate for some future change ↦ go for a CLA or, better yet, the FLA.

Do you fear the bus factor and that Tildes would completely die off as key devs disappear ↦ get an organisation to hold to your assets including the keys and passwords to infrastructure, with instructions on when your project is deemed comatose and under which conditions someone else can revive it – for that I would recommend the Commons Conservancy (and use FLA to assign the right to it).

Do you not trust a central entity and fear they go crazy and run away with your code ↦ don’t use CLA; use FLA instead (which forbids this), perhaps with a trusted org as the Commons Conservancy (which is by law forbidden to do this); if even that does not meet your needs, go for the I=O CLA and just swallow the fact that changing the license will be very unlikely in the future.

…there may be other, more case-by-case specific risks, so happy to brainstorm about any you can come up with :)

At the end, most of these issues are questions of governance and as such of social nature. It just happens that writing them down is in the long-term very practical – which is how you come up with policies and agreements.

BTW for best practices – and tools to check and easily implement them! – for (outbound) licensing info, I can very warmly recommend https://reuse.software/.

Full disclosure:
• I am responsible for the FLA-2.0 update, which is based on my LLM thesis, in which I analysed also other contributor agreements. When I started with it, I was employed by the FSFE as their Legal Coordinator, but finished it later as a volunteer.
• I co-wrote the governance documents for The Commons Conservancy and back then recieved a small grant from NLnet for that. Other then that, I am not affiliated with either and do not receive any money from them. I just honestly believe that their service is great and deals with some issues that no-one else tackled before.