[ahnick]

The model we are planning to use for the products at Plyint(https://plyint.com) is basically the "Free Software Product" model in a SaaS format. How this will work is we will release the code with a proprietary license, but then if you want to use it in a product or pure open source fork, then you need to go to the trouble of removing the company name and product references. Once, that is done then the license will become an AGPL license that can be used as one would normally expect and any modifications to that code would need to be released again publicly. (This way any fork is required to contribute their code back to the public domain)

I think this will introduce enough time delay that the SaaS service will establish itself. Plus, the product has to become popular enough for anyone to want to go through that level of effort. Also, any significant fork's code will be open source and we can reincorporate that into the original SaaS service as well.

[teddyh]

> any modifications to that code would need to be released again publicly.

Technically, that is incompatible with the AGPL (and the GPL, for that matter). Private modifications without distribution are permitted by the GPL/AGPL, and if you don’t allow them, you are violating the GPL/AGPL license by adding this additional restriction.

Of course, this might not be a problem, for two reasons: Firstly, you might be the sole copyright holder, in which case you don’t need a license (it is instead you who give licenses to others), and secondly, for a SaaS product, any public use by a third party will make the AGPL kick in and require, from the third party, a release of the modified source.

> Also, any significant fork's code will be open source and we can reincorporate that into the original SaaS service as well.

Sure, but you will then no longer be the sole copyright holder, in which case you do need to adhere to the AGPL license terms, and you can’t require release of any modifications (except when the AGPL requires it; i.e. when the software is available publicly). Also, you can’t then release this code under a proprietary license, which you say is your plan.

Note: If you’re OK with the release of modifications which AGPL requires, then everything is fine. It’s only if you insist on the release of all private modifications that you could run into trouble.

[ahnick]

> Technically, that is incompatible with the AGPL (and the GPL, for that matter). Private modifications without distribution are permitted, and if you don’t allow them, you are violating the license.

Sorry, I should have been more clear. I meant you make a modification AND offer a competing SaaS service. At that point under the AGPL that is considered distribution and would need to be open sourced.

> Sure, but you will then no longer be the sole copyright holder, in which case you do need to adhere to the AGPL license terms, and you can’t require release of any modifications. Also, you can’t then release this code under a proprietary license, like you describe.

Yes, so I was thinking about this as well. Basically what I'd like is an AGPL with a CLA that allows us to incorporate it back into the original service. I guess what would need to happen is specify in the original licensing of the product that the proprietary license converts to AGPL + CLA to Plyint.

[teddyh]

> an AGPL with a CLA

You can’t require a CLA with AGPL. That would be an additional restriction, which AGPL does not allow. You can require a CLA for contributions to be accepted into your own distibution of the software (since you are not required to accept patches), but you can’t require anyone to sign or agree to a CLA if they recieved the software under AGPL.

It wouldn’t be fair either, I think, for you to sell the contributions of third parties as part of your software under a proprietary license. You can’t have your cake and eat it too; either you develop stuff yourself and get to sell it under whatever license you like, or you accept contributions from third parties all over the world under a free license, and you then sell the software to your customers under the AGPL, not a proprietary license.

You might be concerned about your customers then redistributing the AGPL software you sold them, but firstly, you might be able to fix this by requiring your customers to sign a contract with you (as part of the sale), where they agree not to do that, allowing you to sue them for breach of contract if they do. (I am not sure about the legal status of this scheme, however, and IIRC, the text of the GPL seems to want to at least discourage it.) Secondly, Red Hat allows CentOS to exist, and RH still makes a pretty penny selling RHE licenses. So this might not be a problem in practice.

EDIT: See also this post, linked by jboynyc elswhere in this discussion:

https://sfconservancy.org/blog/2020/jan/06/copyleft-equality...

[ahnick]

> You can’t require a CLA with AGPL. That would be an additional restriction, which AGPL does not allow. You can require a CLA for contributions to be accepted into your own distibution of the software (since you are not required to accept patches), but you can’t require anyone to sign or agree to a CLA if they recieved the software under AGPL.

So, the term CLA might be too strong here. What I'm really wanting to do is add an additional term that allows for "any modification of the source code that is contributed back to an open source fork to then be reapplied to the proprietary product." This I don't believe qualifies as a "further restriction", because I'm just granting an additional right to the company to reincorporate the code into the original product and I'm not restricting the rights of the downstream user in anyway. (i.e. they can continue to offer a competing product and use it however they would like)

Section 7 of the AGPL say this at the end...

"Additional terms, permissive or non-permissive, may be stated in the form of a separately written license, or stated as exceptions; the above requirements apply either way.

To me what I'm asking for is a "permissive" additional term that qualifies under this section. Do you disagree?

From a principle perspective, I think as long as developers know up front (based on the licensing) that when they contribute code to and open source project that the code could be incorporated back into the original product, then they would be okay with that.

As I'm writing this, I had the thought that perhaps a simpler approach is simply to just open source it as AGPL from the beginning with the additional restriction to remove the Plyint trademarks from the code. That is fairly clearly spelled out in section 7 as a valid additional term.

[teddyh]

> allows for "any modification of the source code that is contributed back to an open source fork to then be reapplied to the proprietary product."

That’s not an additional permission. That is granting yourself a right; i.e. a requirement imposed (on the legal author of the contribution) to give you this permission.

> Do you disagree?

Yes, I disagree. The author of a patch owns the copyright on that patch. You can’t reasonably believe that requiring this author to give you permission to do something constitutes an “additional permission” which you are giving to that author. It is obviously a restriction imposed on that author, since they would not otherwise be required to give you this permission.

A “permission” can only be something which you grant someone which 1. You are in a position to grant and 2. They would otherwise be not permitted to do. In the case of a software license like the AGPL, you the copyright holder have the sole right to copy the software. The license you give to others to copy the software under certain conditions is a thing which they would not otherwise be permitted to do under copyright law. Therefore, this “permission” that you want to give yourself, regarding copying the code authored by other people, does not qualify as such, since you are not in a position to give this permission, since you do not hold the copyright to the patch.

> From a principle perspective, I think as long as developers know up front (based on the licensing) that when they contribute code to and open source project that the code could be incorporated back into the original product, then they would be okay with that.

Maybe, but you’d have to find some legal way to accomplish this.

> As I'm writing this, I had the thought that perhaps a simpler approach is simply to just open source it as AGPL from the beginning with the additional restriction to remove the Plyint trademarks from the code. That is fairly clearly spelled out in section 7 as a valid additional term.

Oh, I agree completely. This would probably be the best for all involved.

[ahnick]

Thanks for the cogent explanation. That actually makes a lot of sense to me.

> A “permission” can only be something which you grant someone which 1. You are in a position to grant and 2. They would otherwise be not permitted to do.

Did you pull this from somewhere? I would like to read more, if so.

[blackorzar]

Instead of CLA you may consider on requiring the contributions to be dual licensed MIT + AGPL. MIT allows you to use the code in your SAAS version. Your code, the constributions and the entire repo can be kept AGPL only (because MIT doesn't impose a condition on you to release the entire code as MIT).

[ahnick]

If someone contributes back to the repo is that contribution governed by both the MIT and AGPL licenses in a dual license scenario?

[teddyh]

Not necessarily, but that is always true, even for, e.g., GPL-only projects. I.e. a GPL-only project might recieve a patch, but if the patched code does not contain a license covering that patch, the project does not have a licence to the patch and cannot use it. The usual way this is fixed is by having clear descriptions in your developer’s documentation on how to contribute patches and what licenses must be given to recipients in order for you, the software maintainers, to accept the patch into the project.

See further this post:

https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/