⚖️ AGPLv3 exception for Plugins 🚀

[wolfgang-braun]

How to use GitHub

• Please use the 👍 reaction to show that you are interested into the same feature.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

Is your feature request related to a problem? Please describe.
AGPLv3 doesn't really make selling self-developed plugins an option.
This may prevent some developers from creating plugins that could make Nextcloud interesting to even more users.

Describe the solution you'd like
The Shopware project has found a solution to improve this situation while maintaining AGPLv3

We want to give developers the freedom to create plugins for diverse business models without license requirements. For this reason, we allow an exception to the license terms of AGPLv3 for self-written plugins. These plugins have separate license terms – even when the plugin is derived from the class "Shopware_Components_Plugin_Bootstrap" – and do not have to be approved as open source software. For this purpose, the AGPLv3 license text contains the following add-on: Additional permission under AGPLv3, Sec. 7 If you modify this Program, or any covered work, by combining it with Plugins entirely written by you, the licensors of this Program grant you additional permission to convey those Plugins under terms of your choice, provided that those terms do not place additional restrictions on the Program.

Source, section "Plugins"

Can the Nextcloud project also include such an exception in the license conditions?

Describe alternatives you've considered
none

Additional context
A previous discussion of this issue

Solution: ...You can not prohibit that someone sells your work the same way you sell it....

https://help.nextcloud.com/t/noob-question-about-app-licensing/78408

Actual license exception:

Additional permission under AGPLv3, Sec. 7:
If you modify this Program, or any covered work, by combining it
with Plugins entirely written by you, the licensors of this Program
grant you additional permission to convey those Plugins under terms
of your choice, provided that those terms do not place additional
restrictions on the Program.

Source: license.txt

[solracsf]

Noob question, what prevents you to build something where:

1. Your service/app is under any license you want
2. Build a connector under AGPLv3

Some examples: OnlyOffice, ChatGPT, DocuSign...

?

Also :

Can I sell my Nextcloud App?
Yes. Nextcloud is licensed under the GNU AGPLv3. This license only defines the rights you have to give the users of the software, but not how they get the software. You can decide freely if you want to sell the software in an app store or through any other channel, or if you want to make the app publicly available. The only requirement is that you license your app under the AGPLv3 or a compatible license.

About this last point, why not build an app, licence it under AGPLv3, but control it selling a licence key matching the installed domain?

Even Nextcloud do this (or very similar).

[wolfgang-braun]

@solracsf

Proposal 1

Build a connector under AGPLv3

I'm not a lawyer, but this approach seems legally sound.
However I'm not 100% sure AGPLv3 doesn't force to also open source the service that is connected by the adapter?
Isn't that the reason, why software with this license is forbidden in many companies?

Some examples: OnlyOffice, ChatGPT, DocuSign...

I think a distinction makes sense here:

• Either a company provides a standalone service that it would like to integrate into Nextcloud (applies to all of the examples mentioned)
• Or the company has a special solution built specifically for Nextcloud

Of course both cases can be treated the same. Doing so the second case becomes a technical workaround for legal reasons, which results in unnecessary additional complexity.
If a company needs the additional complexity of an adapter, it might probably build the app completely standalone and the Nextcloud integration might then be a nice extra which might never get implemented.
Should the license really be a hurdle here? Wouldn't it be good for Nextcloud to have a plugin ecosystem with more of these deeply integrated custom apps?

Proposal 2

licence it under AGPLv3, but control it selling a licence key

Unless I'm wrong, that means a company has to publish its plugin's source code. The type of plugins I'm talking about usually don't have a service that can be restricted with a key. These are applications that do everything within the Nextcloud system. They use the existing database and files to digitize a wide variety of business processes.
So if the whole value is in the public plugin folder (and not protected by a web API), it's fairly easy to change the one line which checks for the key directly in the plugin code.
Imagine someone forks such a plugin and simply removes the license check...
Investing a lot of time and money in developing a plugin that relies on getting money back makes not much sense in that case.
And even if it's not about selling the software but simply using it: AGPLv3 forces the company to publish all the potentially secret business logic of this plugin, doesn't it?

Proposal license extension

It would be nice if these problems could be solved by just adding a single paragraph to the license. However, I don't know what problems this license change might cause and whether making the plugin system more interesting is even wanted.

[susnux]

Unless I'm wrong, that means a company has to publish its plugin's source code.

As I understand only to your customer and their users of it

[wolfgang-braun]

Unless I'm wrong, that means a company has to publish its plugin's source code.

As I understand only to your customer and their users of it

I think thats right.
And it's still a problem:
Imagine a large company with an IT department developing a plugin for internal use. The code contains a lot of confidential business logic. Should an intern really be allowed to download the source code?

---

There are reasons why e.g. Google restricts usage here:

WARNING: Code licensed under the GNU Affero General Public License (AGPL) MUST NOT be used at Google.

https://opensource.google/documentation/reference/using/agpl-policy

There are reason why e.g. Shopware added the exception to their AGPLv3 license.

The question is whether Nextcloud wants to improve this situation and what it would mean to do so.

[susnux]

Imagine a large company with an IT department developing a plugin for internal use. The code contains a lot of confidential business logic. Should an intern really be allowed to download the source code?

In this case back to @solracsf :

1. Your service/app is under any license you want
2. Build a connector under AGPLv3

But only speaking here as a community member.

[wolfgang-braun]

In this case back to @solracsf :

1. Your service/app is under any license you want

2. Build a connector under AGPLv3

But only speaking here as a community member.

As mentioned before

... becomes a technical workaround for legal reasons, which results in unnecessary additional complexity.

The adapter workaround works and is used if you want to add some features to Nextcloud.

I'm trying to explain how to make Nextcloud more attractive as a platform for developers who don't necessarily need to use Nextcloud.

If a developer who can develop his app completely independently of Nextcloud first has to build an adapter in order to ultimately develop a standalone app, he will not use Nextcloud at all because it is of no use.

If a developer can use Nextcloud users, files, etc. without licensing issues, he may see this as a way to reduce time and complexity.

Nexcloud's potential in this space is destroyed by licensing restrictions on custom apps. I think that's a shame.

[AndyScherzinger]

Can the Nextcloud project also include such an exception in the license conditions?

The short answer: No

The long answer / explanation
The reason for this is that it actually doesn't work. First of all that is not a AGPL3 license anymore, you changed it (!). Secondly you can choose any license you want as long as it is compatible to the AGPLv3. Else you would violate the license. While not being a lawyer but having talked to colleagues in the company who dealt with OSS licenses a bit longer. The shopware section doesn't work - while granting you the right to use another license for your plugin, the general nature of the AGPL will just "overwrite" your license with AGPL. So this is just creating a false sense of "protection" from getting GPL-ed.

• So an adapter approach works when you separate things via ReST - with pure PHP the "same process/thread" aspect would kick in and render it AGPL again
• If it is "just" user internally at your company than this can be mitigated anyways. Just because something is AGPL doesn't want you have to grant everyone access to the code and put it publicly on the internet. Only users of the app would have a right got request the code - however in case of employees you can have them waive that right via a section in the employment contracts.

For Google this doesn't work of course hence their prevention of use of AGPL code because their devs build products publicly available, so anybody could register an account and request the code, hence they don't use it because it is not "employee only"

[AndyScherzinger]

Besides that you can also write apps with the new ecosystem approach where all your apps would plug into Nextcloud via ReST APIs so you can use any license you want. However the currently set of APIs is still less broad than the PHP side of things. So the use cases might be limited but might be enough for your case.