It's more sensible for free software / open source to be hosted on GitLab especially after the Microsoft inquisition of GitHub. I'm not 100% sure why for this particular case but it can easily...
It's more sensible for free software / open source to be hosted on GitLab especially after the Microsoft inquisition of GitHub. I'm not 100% sure why for this particular case but it can easily fall along those lines.
Publishing code for Tildes before the site itself is open to the public seems liable to result in another instance becoming more popular and killing the original Tildes. At the very least, I'd...
Publishing code for Tildes before the site itself is open to the public seems liable to result in another instance becoming more popular and killing the original Tildes.
Duh? There is not a whole lot of case law or legal precedent even in the Western world for opensource licenses. It was only recently (May of last year) that the Northern District of California...
Duh? There is not a whole lot of case law or legal precedent even in the Western world for opensource licenses. It was only recently (May of last year) that the Northern District of California ruled that the GPL could be treated as a contract and thus a breach of it could potentially warrant damages. But that is only one FOSS license, and a ruling in one Federal district and so the issue is far from totally decided yet. In most Countries whether they are enforceable or not is still up for debate... even Canada, where ~ is located. Which begs the question, why did you only bring up China?
GPL basically has zero effect on hosted stuff. It only deals with distributors and the person running the software (ie, the host). In other words, for something like Tildes, it might as well be...
GPL basically has zero effect on hosted stuff. It only deals with distributors and the person running the software (ie, the host). In other words, for something like Tildes, it might as well be the MIT/BSD licenses.
AGPL grants the usual GPL rights to not only the users who run the software, but also the users who remotely access it. It also requires compliance from people who host the software, not only those who distribute it.
@deimos is leaning towards AGPLv3 not GPLv3. Reasoning is here: https://docs.tildes.net/technical-goals#license Basically AGPLv3 ensures it can never be closed source (like what reddit just did by...
Basically AGPLv3 ensures it can never be closed source (like what reddit just did by closing the source again) and all derivatives must be opensource as well.
Reddit released under CPAL. IANAL but AFAIK that means all the code released up until they closed the source again can still be considered opensource but all code going forward is proprietary....
Reddit released under CPAL. IANAL but AFAIK that means all the code released up until they closed the source again can still be considered opensource but all code going forward is proprietary. AGPLv3 doesn't allow the source to ever get closed off again.
AGPLv3 can, in theory. There is a specific 'Automatic Licensing of Downstream Recipients' clause to address just that. But it's just a theory at this point with no legal precedent to back it up...
AGPLv3 can, in theory. There is a specific 'Automatic Licensing of Downstream Recipients' clause to address just that. But it's just a theory at this point with no legal precedent to back it up since no cases regarding it have been decided yet.
Not once you start taking outside contributions (unless you make them assign copyright to you, which I'm not going to do). Then you can't change the license any more without the assent of everyone...
Not once you start taking outside contributions (unless you make them assign copyright to you, which I'm not going to do). Then you can't change the license any more without the assent of everyone that's contributed code.
You could also do a DCO. Basically everyone submits under MIT or something else permissive so the project owner can relicense if needed, and attests that they have the right to do so. Copyright is...
You could also do a DCO. Basically everyone submits under MIT or something else permissive so the project owner can relicense if needed, and attests that they have the right to do so. Copyright is not assigned.
There are good reasons for when to use a DCO (+ Inbound = Outbound CLA), and there are reasons where a (more complex) CLA (Contributor License Agreement) would be more useful. A full-on CAA...
There are good reasons for when to use a DCO (+ Inbound = Outbound CLA), and there are reasons where a (more complex) CLA (Contributor License Agreement) would be more useful.
A full-on CAA (Copyright Assignment Agreement) though is very rarely needed, if at all.
I gave this a bit more thought, and what you describe is an example of a way how a DCO (without any further CLA) can be (ab)used counter to its initial intent. What the DCO (official link) does,...
I gave this a bit more thought, and what you describe is an example of a way how a DCO (without any further CLA) can be (ab)used counter to its initial intent.
What the DCO (official link) does, as you already said, is just and only that the contributor warrants (that’s not an idle word in legalese, BTW!):
that they are have the appropriate rights to do contribution, and
that the contribution is under the FOSS license in the contributed file
(some stuff about being publicly listed, irrelevant for this discussion)
What happens at what you describe, from the Tildes project’s PoV is that:
dev writes his code and puts MIT as the license in the file(s) dev wrote
dev contributes his code by signing the DCO with the Signed-Off-By git tag when pushing to the Tildes git repo
Tildes receives this code under MIT (i.e. inbound license for Tildes), which grants Tildes very broad rights with little to no obligations
Now there’s two possibilities:
Tildes keeps the license as MIT in the contributed files, which is compatible with (e.g.) AGPL-3.0 as the main (outbound) license of Tildes – that would be the Inbound = Outbound approach.
in that case it may happen that there will eventually be more MIT code in there than AGPL-3.0 code, which might cause questions of changing the license
in any case, others could simply take the bits of code under MIT and close it down in their own projects, regardless that Tildes’ main license is AGPL-3.0
Tildes is very well in the position then to go close source since either they (e.g. @deimos for now) own the rights in the code (e.g. the AGPL-3.0 bits in this example) or it’s under such a permissive license that the inbound license can’t prevent them doing it anyway
what is very likely is that people will contribute (mostly) by editing already existing files, so their contributions will be under the AGPL-3.0 anyway – which is what the proponents of the DCO + I=O approach usually base their reasoning on.
Tildes changes all contributed code’s license to AGPL-3.0 before releasing
which I’m not entirely sure can be done according to how I read the MIT license, but it is probably possible to at least say that although these tiny parts are made available (=i.e. outbound) under MIT, Tildes as a whole is AGPL-3.0
we make it possible by writing it down and saying that all contributions are done in MIT (= inbound license) to Tildes with the express obligation that Tildes will always remain FOSS, currently e.g. AGPL-3.0, but that it reserves the right to change the license in the future … well, and we have just come to a definition of a CLA ;)
Something I notice often is that there is a general confusion between a CLA and a CAA.
A CAA is a Copyright Assignment Agreement, which means that you assign (all) your copyright to someone else. They end up holding everything (apart from perhaps moral rights, where they exist) and you with nothing.
A CLA is a Contributor License Agreement, which means that you give a license (i.e. a subsection of your (copy)rights) to someone else, but you remain the copyright holder. That license can be exclusive (i.e. that someone else is the only person you gave this license) or non-exclusive (i.e. you can give the same rights to others as well). Sometimes this will be further cured by a license back – i.e. you will be given (all?) the rights back that you gave under the CLA. Sometimes a CLA will include obligations for the person/entity you are giving your rights to – e.g. to always remain FOSS or which specific licenses they may release contributions under, what to do if things go wrong, etc.
Both can be summed up by the umbrella term of Contribution Agreements.
Again, that's not true (in theory). Once a piece of code is licensed under AGPLv3 all subsequent works, if they rely on any portion of other code licensed under AGPLv3 (such as code...
Again, that's not true (in theory).
10. Automatic Licensing of Downstream Recipients.
Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work, subject to this License. You are not responsible for enforcing compliance by third parties with this License.
An "entity transaction" is a transaction transferring control of an organization, or substantially all assets of one, or subdividing an organization, or merging organizations. If propagation of a covered work results from an entity transaction, each party to that transaction who receives a copy of the work also receives whatever licenses to the work the party's predecessor in interest had or could give under the previous paragraph, plus a right to possession of the Corresponding Source of the work from the predecessor in interest, if the predecessor has it or can get it with reasonable efforts.
You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License, and you may not initiate litigation (including a cross-claim or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it.
Once a piece of code is licensed under AGPLv3 all subsequent works, if they rely on any portion of other code licensed under AGPLv3 (such as code contributions), whether whole or divided, must also be licensed under AGPLv3.
Sure but AFAIK it's basically reciprocal. Any entity transaction must be AGPLv3, including code contributions which the contributors retain copyright over (unless otherwise specified), and so as...
Sure but AFAIK it's basically reciprocal. Any entity transaction must be AGPLv3, including code contributions which the contributors retain copyright over (unless otherwise specified), and so as soon as a project accepts code contributions (which must also be AGPLv3) the main repo cannot change or revoke the license unless they get permission from every contributor first or remove all the contributions before doing so.
But again, IANAL and have only read other people's interpretations on the AGPLv3 so I could very well be wrong. If you can point me to somewhere that contradicts my understanding I would even appreciate it since I am genuinely trying to understand it to the best of my ability.
Can you link to the interpretation that supports this? I will be happy to look further into this. What you describe is is a (perhaps tacit) Inbound = Outbound CLA in place. But (unless a CLA is...
Can you link to the interpretation that supports this? I will be happy to look further into this.
What you describe is is a (perhaps tacit) Inbound = Outbound CLA in place.
But (unless a CLA is actually on place and enforced) neither copyright law nor the AGPL-3.0 force either the original author of the project or any contributor to contribute under the same license.
E.g.:
a) Code is contributed under MIT, BSD-3-Clause or similar - all fine, permissive and compatible
b) Code is contributed under GPL-3.0 - all fine, the two are compatible
c) Code is contributed without any license mentioned (and no DCO or CLA) - problem
d) Code is contributed under a license incompatible with (A)GPL - potential problem
So you can still end up with a code base of mixed licenses. There are combinations where you could end up with still being able to either close the source or isolate the code you need to keep open, and still comply witj those licenses. Not super easy, but possible.
Which is why just AGPL-3.0 and the DCO are not enough to guarantee the code cannot be closed down. One option is the I=O CLA, but there are others as well, which are slightly more complicated, but solve more issues (e.g. FLA, the Commons Conservancy, etc.).
(I apologise for being terse. I manage FOSS licensing at work. It is weekend morning, and I'm writing from a phone.)
Don't worry, I don't mind terse. ;) I understand people have limited time and so just appreciate you even responding in the first place, especially since you're clearly well versed in the subject....
Don't worry, I don't mind terse. ;) I understand people have limited time and so just appreciate you even responding in the first place, especially since you're clearly well versed in the subject.
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), 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).
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?
Also, if you don't mind sharing a personal opinion: Do you think once contributions start being accepted with various licenses attached to them, 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?
I’m back behind a proper keyboard :) Since this is turning out lengthy, I’ll split it into two parts: Q&A bit Correct. A FOSS (or other) license of a project deals only with the relationship...
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.
Wow. Thanks a ton for that incredibly detailed reply! I don't think I will ever fully understand the legalese in the licenses themselves, but your comment certainly cleared up a lot of my...
Wow. Thanks a ton for that incredibly detailed reply!
I don't think I will ever fully understand the legalese in the licenses themselves, but your comment certainly cleared up a lot of my misunderstanding of them at the basic/conceptual level, at least. Although I suspect I will probably need to reread what you wrote a few times before it all sinks in (which is why I just bookmarked it). ;)
p.s. Thanks for the FSFE and reuse.software links as well, I suspect those will come in handy a lot in the future as I slowly try to understand this stuff.
The Tildes repository is public at https://gitlab.com/tildes/tildes but @deimos hasn't uploaded the code yet.
Does anyone know why gitlab over github
It's more sensible for free software / open source to be hosted on GitLab especially after the Microsoft inquisition of GitHub. I'm not 100% sure why for this particular case but it can easily fall along those lines.
Considering that this repository was setup before the news of the microsoft taking of github I doubt that was a consideration.
Well, I did post this over a week before, saying that I was worried about what would be in GitHub's future because of their VC debt: https://tildes.net/~comp/uo/ask_tildes_what_is_the_best_way_to_get_involved_with_the_development_of_tildes#comment-4la
True, still a great choice nonetheless.
Because Github isn't open source and is owned by Microsoft? There are lots of reasons it could be for.
Also, GitLab has free unlimited private repositories.
Publishing code for Tildes before the site itself is open to the public seems liable to result in another instance becoming more popular and killing the original Tildes.
At the very least, I'd suggest making it AGPL. ;)
Yes, @deimos is leaning towards AGPLv3. Reasoning is here: https://docs.tildes.net/technical-goals#license
Just a note that people in China happily ignore AGPL and there's basically no recourse.
Sorry, but what's your point?
That it's not a guarantee.
Duh? There is not a whole lot of case law or legal precedent even in the Western world for opensource licenses. It was only recently (May of last year) that the Northern District of California ruled that the GPL could be treated as a contract and thus a breach of it could potentially warrant damages. But that is only one FOSS license, and a ruling in one Federal district and so the issue is far from totally decided yet. In most Countries whether they are enforceable or not is still up for debate... even Canada, where ~ is located. Which begs the question, why did you only bring up China?
GPL basically has zero effect on hosted stuff. It only deals with distributors and the person running the software (ie, the host). In other words, for something like Tildes, it might as well be the MIT/BSD licenses.
AGPL grants the usual GPL rights to not only the users who run the software, but also the users who remotely access it. It also requires compliance from people who host the software, not only those who distribute it.
@deimos is leaning towards AGPLv3 not GPLv3. Reasoning is here: https://docs.tildes.net/technical-goals#license
Basically AGPLv3 ensures it can never be closed source (like what reddit just did by closing the source again) and all derivatives must be opensource as well.
Reddit released under CPAL. IANAL but AFAIK that means all the code released up until they closed the source again can still be considered opensource but all code going forward is proprietary. AGPLv3 doesn't allow the source to ever get closed off again.
The copyright holder(s) can always change license terms of new code going forward. No license can prevent that.
AGPLv3 can, in theory. There is a specific 'Automatic Licensing of Downstream Recipients' clause to address just that. But it's just a theory at this point with no legal precedent to back it up since no cases regarding it have been decided yet.
If you're the copyright holder, you can always just stop licensing your new code under AGPLv3...
Not once you start taking outside contributions (unless you make them assign copyright to you, which I'm not going to do). Then you can't change the license any more without the assent of everyone that's contributed code.
You could also do a DCO. Basically everyone submits under MIT or something else permissive so the project owner can relicense if needed, and attests that they have the right to do so. Copyright is not assigned.
There are good reasons for when to use a DCO (+ Inbound = Outbound CLA), and there are reasons where a (more complex) CLA (Contributor License Agreement) would be more useful.
A full-on CAA (Copyright Assignment Agreement) though is very rarely needed, if at all.
I gave this a bit more thought, and what you describe is an example of a way how a DCO (without any further CLA) can be (ab)used counter to its initial intent.
What the DCO (official link) does, as you already said, is just and only that the contributor warrants (that’s not an idle word in legalese, BTW!):
What happens at what you describe, from the Tildes project’s PoV is that:
Signed-Off-Bygit tag when pushing to the Tildes git repoNow there’s two possibilities:
Something I notice often is that there is a general confusion between a CLA and a CAA.
A CAA is a Copyright Assignment Agreement, which means that you assign (all) your copyright to someone else. They end up holding everything (apart from perhaps moral rights, where they exist) and you with nothing.
A CLA is a Contributor License Agreement, which means that you give a license (i.e. a subsection of your (copy)rights) to someone else, but you remain the copyright holder. That license can be exclusive (i.e. that someone else is the only person you gave this license) or non-exclusive (i.e. you can give the same rights to others as well). Sometimes this will be further cured by a license back – i.e. you will be given (all?) the rights back that you gave under the CLA. Sometimes a CLA will include obligations for the person/entity you are giving your rights to – e.g. to always remain FOSS or which specific licenses they may release contributions under, what to do if things go wrong, etc.
Both can be summed up by the umbrella term of Contribution Agreements.
Well, you're no longer the sole copyright holder in that scenario. :)
Again, that's not true (in theory).
Once a piece of code is licensed under AGPLv3 all subsequent works, if they rely on any portion of other code licensed under AGPLv3 (such as code contributions), whether whole or divided, must also be licensed under AGPLv3.
You do realise that "you" in the quoted text refers to the licensee, not the licensor?
Sure but AFAIK it's basically reciprocal. Any entity transaction must be AGPLv3, including code contributions which the contributors retain copyright over (unless otherwise specified), and so as soon as a project accepts code contributions (which must also be AGPLv3) the main repo cannot change or revoke the license unless they get permission from every contributor first or remove all the contributions before doing so.
But again, IANAL and have only read other people's interpretations on the AGPLv3 so I could very well be wrong. If you can point me to somewhere that contradicts my understanding I would even appreciate it since I am genuinely trying to understand it to the best of my ability.
Can you link to the interpretation that supports this? I will be happy to look further into this.
What you describe is is a (perhaps tacit) Inbound = Outbound CLA in place.
But (unless a CLA is actually on place and enforced) neither copyright law nor the AGPL-3.0 force either the original author of the project or any contributor to contribute under the same license.
E.g.:
a) Code is contributed under MIT, BSD-3-Clause or similar - all fine, permissive and compatible
b) Code is contributed under GPL-3.0 - all fine, the two are compatible
c) Code is contributed without any license mentioned (and no DCO or CLA) - problem
d) Code is contributed under a license incompatible with (A)GPL - potential problem
So you can still end up with a code base of mixed licenses. There are combinations where you could end up with still being able to either close the source or isolate the code you need to keep open, and still comply witj those licenses. Not super easy, but possible.
Which is why just AGPL-3.0 and the DCO are not enough to guarantee the code cannot be closed down. One option is the I=O CLA, but there are others as well, which are slightly more complicated, but solve more issues (e.g. FLA, the Commons Conservancy, etc.).
(I apologise for being terse. I manage FOSS licensing at work. It is weekend morning, and I'm writing from a phone.)
Don't worry, I don't mind terse. ;) I understand people have limited time and so just appreciate you even responding in the first place, especially since you're clearly well versed in the subject.
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), 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).
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?
Also, if you don't mind sharing a personal opinion: Do you think once contributions start being accepted with various licenses attached to them, 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?
Thanks again for your time, BTW.
I’m back behind a proper keyboard :)
Since this is turning out lengthy, I’ll split it into two parts:
Q&A bit
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.
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 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:
NOTICE,AUTHORS,README), make sure you keep it.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.
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.
Wow. Thanks a ton for that incredibly detailed reply!
I don't think I will ever fully understand the legalese in the licenses themselves, but your comment certainly cleared up a lot of my misunderstanding of them at the basic/conceptual level, at least. Although I suspect I will probably need to reread what you wrote a few times before it all sinks in (which is why I just bookmarked it). ;)
p.s. Thanks for the FSFE and reuse.software links as well, I suspect those will come in handy a lot in the future as I slowly try to understand this stuff.
Hehe, happy to help :)