[enhancement]: exclude SEL licensed code from AGPL licensed code

[afontenot]

What happened?

I attempted to build the program after removing code licensed under SEL, in particular the snippet here: https://github.com/stalwartlabs/mail-server/blob/main/crates/directory/src/backend/internal/mod.rs#L101

    // SPDX-SnippetBegin
    // SPDX-FileCopyrightText: 2020 Stalwart Labs Ltd <[email protected]>
    // SPDX-License-Identifier: LicenseRef-SEL

    pub fn has_tenant_access(&self, tenant_id: Option<u32>) -> bool {
        tenant_id.map_or(true, |tenant_id| {
            self.tenant.map_or(false, |t| tenant_id == t)
                || (self.typ == Type::Tenant && self.id == tenant_id)
        })
    }

    // SPDX-SnippetEnd

Quite a bit of code that is AGPL 3.0 licensed in crates/directory/src/backend/internal/manage.rs depends on this function. I'm building without the enterprise --feature and this doesn't make a difference here as the code isn't conditionally compiled.

How can we reproduce the problem?

git clone https://github.com/stalwartlabs/mail-server && cd mail-server
# remove SEL licensed code
perl -i -0pe 's/ *\/\/ SPDX-SnippetBegin[^\n]*\n[^\n]*\n[^\n]*SPDX-License-Identifier: LicenseRef-SEL.*?\/\/ SPDX-SnippetEnd *//gms' crates/**/*.rs
grep -l 'SPDX-License-Identifier: LicenseRef-SEL' crates/**/*.rs | xargs truncate -s0
# build
export RUSTUP_TOOLCHAIN=stable
cargo fetch --locked --target "$(rustc -vV | sed -n 's/host: //p')"
cargo build --frozen --release -p mail-server --no-default-features --features 'rocks'

Version

v0.10.x

What database are you using?

None

What blob storage are you using?

None

Where is your directory located?

None

What operating system are you using?

None

Relevant log output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[afontenot]

Tracking additional issues I encounter after 71c3c06.

The line at

mail-server/crates/directory/src/backend/internal/manage.rs

Line 660 in 71c3c06

PrincipalInfo::new(principal_id, principal.inner.typ, principal.inner.tenant())

calls the tenant() function which is SEL code.

The conditional compiling statement at

mail-server/crates/directory/src/backend/internal/manage.rs

Line 790 in 71c3c06

#[cfg(feature = "enterprise")]

cannot be used when trying to compile only AGPL code because it's included in the SEL license block. (This doesn't actually matter if you literally remove the code from the tree like I'm doing, but it matters if you're e.g. Arch Linux and you want to make sure your build can be licensed AGPL.

[mdecimus]

I'll look into this in a few weeks once OIDC has been implemented.

[afontenot]

Following up on this: I still see an error in the same code as described above, meaning that it's still not possible to use Stalwart under the AGPL at present. Tested version was latest git commit.

While I'm here, a couple of additional things.

I think the Readme is misleading on this subject because it describes Stalwart as "dual-licensed". Usually dual licensing means that the user has a choice of which license agreement to distribute the software under. For example, the Qt project dual licenses under GPL and a proprietary license. It was not obvious to me until digging into the project that the code was not freely licensed, and I think e.g. Arch Linux got tripped up by this as well. One nice way to solve this on a more permanent basis would be to have the automated release system generate AGPL-clean sources and binaries.

Also, I have concerns I previously deferred about the CLA. I believe the CLA predates the relicensing of the code, for one thing, and it is also clear when it states that

We agree to (sub)license the Contribution or any Materials containing, based on or derived from your Contribution under the terms of any licenses the Free Software Foundation classifies as Free Software License and which are approved by the Open Source Initiative as Open Source licenses.

This means that the Stalwart organization has agreed to license the entire Stalwart project (including "proprietary" code) under a free software license in perpetuity - unless every contribution provided under the CLA is removed - meaning that the attempt to re-license the project is likely* invalid. I think a true dual-licensing scheme that earned money exclusively by releasing business customers from the AGPL's requirements could potentially be sustained, but I haven't looked at this in any detail.

* I am not a lawyer and cannot provide legal advice on this point. This reflects my personal opinion based on my interpretation of the CLA.

[benbucksch]

Another way to solve that would be with an addon model. The APIs would need to be sufficient to allow the proprietary code to work. I think for example an authentication method should be easy enough to separate out, given that many projects have pluggable authentication, and there is SASL standard etc.

[mdecimus]

I still see an error in the same code as described above, meaning that it's still not possible to use Stalwart under the AGPL at present. Tested version was latest git commit.

Sorry, this is not a priority at the moment. A lot of people would like to see DAV support in Stalwart for instance. I'll look at this once version 1.0 is released in a few months. If not being able to remove the SEL code entirely is an issue upstream then please ask the affected parties not to include Stalwart's source code until this is addressed.

I believe the CLA predates the relicensing of the code.

You are looking at the current FLA, there was an even more restrictive CLA before. In any case, there are no external contributions to the mail-server repository before the SEL license was added. And even the contributions after SEL are minor, mostly fixes to typos or one liners. Some more meaningful external contributions were received in the Stalwart Labs library repositories but these are MIT/Apache.

This means that the Stalwart organization has agreed to license the entire Stalwart project (including "proprietary" code) under a free software license in perpetuity - unless every contribution provided under the CLA is removed - meaning that the attempt to re-license the project is likely* invalid. I think a true dual-licensing scheme that earned money exclusively by releasing business customers from the AGPL's requirements could potentially be sustained, but I haven't looked at this in any detail.

That is incorrect, the FLA grants Stalwart Labs ownership of the code contributed which allow us to license it under a proprietary license. These rights are automatically revoked and ownership is reverted back to the contributor if Stalwart stops offering the contributed code as open source. But it does allow Stalwart Labs to re-license any contributions under SEL.

I am not a lawyer and cannot provide legal advice on this point. This reflects my personal opinion based on my interpretation of the CLA.

Please seek legal advice if you believe I am wrong but please let's not continue this discussion based on your interpretation of the intellectual property law. I don't mean to be rude, I just have a limited amount of time and I need to focus on developing Stalwart. But if your attorney believes the Stalwart licensing model is broken please do let me know. Thank you.

[afontenot]

That is incorrect, the FLA grants Stalwart Labs ownership of the code contributed which allow us to license it under a proprietary license. These rights are automatically revoked and ownership is reverted back to the contributor if Stalwart stops offering the contributed code as open source.

I do disagree and I'm going to briefly explain why and then leave the issue there, as I intend to stop using Stalwart as I see the legal risks as too great -- if a contributor revokes your right to use their code it could destroy the whole project. You're under no obligation to respond.

The full section I'm quoting from:

We agree to (sub)license the Contribution or any Materials containing, based on or derived from your Contribution under the terms of any licenses the Free Software Foundation classifies as Free Software License and which are approved by the Open Source Initiative as Open Source licenses.

More specifically and in strict accordance with the above paragraph, we agree to (sub)license the Contribution or any Materials containing, based on or derived from the Contribution only under the terms of the following license(s) AGPL-3.0 (including any right to adopt any future version of a license if permitted).

So what Stalwart is agreeing to is not just licensing the Contribution as free software, it's also agreeing to license any software containing, based on, or derived from that software as AGPL 3.0 (or a later version). Stalwart (the full product) is obviously a piece of software that contains the Contribution, therefore it falls under this agreement. You're right (I think) that the CLA gives Stalwart the right to license the Contribution under the SEL as well, but the right to use the code can be terminated if the above agreement isn't met:

This Agreement shall apply for the term of the copyright and patents licensed here. However, You shall have the right to terminate the Agreement if We do not fulfill the obligations as set forth in Section 4. Such termination must be made in writing.

So to the extent that Stalwart is refusing to license SEL code under the AGPL 3.0 as well, I believe any contributor has the right to terminate the agreement.

And actually, if you look up the history of the Fiduciary License Agreement, you'll see that it was intended to do just that:

To tackle this issue, some projects may require a full copyright assignment signed by all contributors. The problem with such assignments is often that they lack check and balances that would protect these contributors from any potential abuse of power from the new copyright holder. ...

What if the Trustee misuses the rights I gave to them, e.g. by re-licensing Free Software as a proprietary one?

An FLA offers a special clause against this kind of situation, in order to protect the Free Software project against potentially malicious intentions of the Trustee. According to this provision, if the Trustee acts against the principles of Free Software, all granted rights and licences return to their original owners. That means that the Trustee will be effectively prevented from continuing any activity which is contrary to the principles of Free Software.

I wish you well. I don't have any ill feelings or intent toward you or the Stalwart project, and I understand that it's difficult to have a career in open source software. I just want the facts to be as clear as I can.