[AGREEMENT] accept contributions compatible with GPLv3-or-later

oliverpool commented

2023-05-15 11:05:27 +02:00

Member

Many discussions happened regarding accepting copyleft contributions to forgejo:

#20 [MISSION] on Forgejo accepting copyleft contributions
forgejo/discussions#6 Relicensing Forgejo as copyleft
forgejo/meta#86 [Discussion] Relicensing Forgejo as copyleft
forgejo/website#204 Forgejo welcomes copyleft contributions

From my understanding many people are in favor of accepting AGPLv3(+) contributions, while some people object. I compiled the following list of objections:

lot of work/uncertainty to ensure you comply with it forgejo/meta#86 (comment)
some company policy simply ban AGPL-licensed products (see Google policy for instance)

From what I gather, both objections do not hold for a GPL license (as it has been noticed, git is available under GPLv2 and is already used by everyone interacting with Forgejo).

Therefore I propose that Forgejo starts accepting contributions which are compatible with the GPLv3-or-later license.

Why the v3-or-later variant of GPL?

Since Forgejo may later accept AGPL contributions, v3 is necessary (there is no AGPL license compatible with GPLv2 as far as I know).

The -or-later part has been discussed and I believe that this paragraph of the license is protective enough:

The Free Software Foundation may publish revised and/or new versions of the GNU Affero General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.

(it explicitely states that future differences are only permitted to address new problems or concerns)

Since Forgejo is exclusively accessed by the network, what new rights does it provides to its users?

As-is it will only provide more rights to people getting a modified Forgejo for self-hosting (not may people I think. Might be the case for projects like https://www.allspice.io which might propose self-hosting binary). However it prepares the path to eventually migrate to AGPL, once the compliance objection can be addressed.

What licenses are compatibles with GPLv3-or-later?

According to this wikipedia graph, projects having the following licenses can be linked/used in a GPLv3-or-later project (IANAL):

GPLv3-or-later (obviously)
GPLv2-or-later
LGPL (2.1-only, 2.1-or-later, 3.0-only, 3.0-or-later)
MPL-2.0
Apache / MIT / BSD

Proposed timeline if this agreement is accepted

Since this change is significant, I would suggest letting at least 3-4 weeks for any objection I may have missed or incorrectly addressed.

Afterwards:

The proposed blog post can be published
The actual LICENSE of the project can be changed with the first merged PR which is not compatible with the current license
Preparation work can be done to address the AGPL-compliance objection above (i.e.: provide a way for anyone self-hosting forgejo to be AGPL-compliant with the lowest effort possible)
Once the above work has been merged, propose a new agreement to accept AGPL contributions

Many discussions happened regarding accepting copyleft contributions to forgejo: - https://codeberg.org/forgejo/governance/pulls/20 [MISSION] on Forgejo accepting copyleft contributions - https://codeberg.org/forgejo/discussions/issues/6 Relicensing Forgejo as copyleft - https://codeberg.org/forgejo/meta/issues/86 [Discussion] Relicensing Forgejo as copyleft - https://codeberg.org/forgejo/website/pulls/204 Forgejo welcomes copyleft contributions From my understanding many people are in favor of accepting AGPLv3(+) contributions, while some people object. I compiled the following list of objections: - lot of work/uncertainty to ensure you comply with it https://codeberg.org/forgejo/meta/issues/86#issuecomment-819747 - some company policy simply ban AGPL-licensed products (see [Google policy](https://opensource.google/documentation/reference/thirdparty/licenses) for instance) From what I gather, both objections do not hold for a GPL license (as it has been noticed, `git` is available under GPLv2 and is already used by everyone interacting with Forgejo). ## Therefore I propose that Forgejo starts accepting contributions which are compatible with the GPLv3-or-later license. **Why the v3-or-later variant of GPL?** Since Forgejo may later accept AGPL contributions, **v3** is necessary (there is no AGPL license compatible with GPLv2 as far as I know). The **-or-later** part has been discussed and I believe that this paragraph of the license is protective enough: > The Free Software Foundation may publish revised and/or new versions of the GNU Affero General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. (it explicitely states that future differences are only permitted to address **new problems or concerns**) **Since Forgejo is exclusively accessed by the network, what new rights does it provides to its users?** As-is it will only provide more rights to people getting a modified Forgejo for self-hosting (not may people I think. Might be the case for projects like https://www.allspice.io which might propose self-hosting binary). However it prepares the path to eventually migrate to AGPL, once the compliance objection can be addressed. **What licenses are compatibles with GPLv3-or-later?** According to this [wikipedia graph](https://en.wikipedia.org/wiki/License_compatibility#/media/File:Floss-license-slide-image.svg), projects having the following licenses can be linked/used in a GPLv3-or-later project (IANAL): - GPLv3-or-later (obviously) - GPLv2-or-later - LGPL (2.1-only, 2.1-or-later, 3.0-only, 3.0-or-later) - MPL-2.0 - Apache / MIT / BSD ## Proposed timeline if this agreement is accepted Since this change is significant, I would suggest letting at least 3-4 weeks for any objection I may have missed or incorrectly addressed. Afterwards: - The [proposed blog post](https://codeberg.org/forgejo/website/pulls/204) can be published - The actual LICENSE of the project can be changed with the first merged PR which is not compatible with the current license - Preparation work can be done to address the AGPL-compliance objection above (i.e.: provide a way for anyone self-hosting forgejo to be AGPL-compliant with the lowest effort possible) - Once the above work has been merged, propose a new agreement to accept AGPL contributions

👍 2 👎 1

oliverpool added 1 commit

2023-05-15 11:05:29 +02:00

agreement: accept contributions compatible with GPLv3-or-later bcbf058d09

oliverpool referenced this pull request from forgejo/discussions

2023-05-15 11:07:59 +02:00

Relicensing Forgejo as copyleft #6

oliverpool referenced this pull request from forgejo/meta

2023-05-15 11:08:26 +02:00

[Discussion] Relicensing Forgejo as copyleft #86

Ghost commented

2023-05-15 11:17:39 +02:00

I think this is a useful step forward 👍

The proposed blog post can be published

IMHO it can be published before. It would have more impact if a license was proposed but I believe it has value as it is. It is a baby step to explain that Forgejo is amicable to copyleft without going into specifics.

I think this is a useful step forward 👍 > The proposed blog post can be published IMHO it can be published before. It would have more impact if a license was proposed but I believe it has value as it is. It is a baby step to explain that Forgejo is amicable to copyleft without going into specifics.

👎 1

oliverpool added the due date 2023-06-15

2023-05-15 21:15:26 +02:00

oliverpool added the

[Decision] Integrating concerns

label

2023-05-15 21:16:21 +02:00

gwymor commented

2023-05-16 17:52:43 +02:00

First-time contributor

I am concerned about this affecting upstreaming features to Gitea. Does Forgejo want to become a hard fork at some point in the future?

If you want to continue upstreaming features, it seems like Gitea developers are averse to GPL contributions. They do use dependencies under another copyleft license (albeit a weaker one), MPL-2.0 (github.com/6543/go-version, github.com/hashicorp/golang-lru, github.com/go-sql-driver/mysql), so they may be open to having MPL-2.0 code in their codebase itself. MPL-2.0 is explicitly compatible with the GPL, so it wouldn't limit the ability to have GPL code or relicense the MPL code to GPL-3.0-or-later in the future. It may be best to discuss licenses with upstream, if upstreaming is still desired.

Additionally, Forgejo/Gitea has a dependency (elkjs) with an EPL-2.0 license, which appears incompatible with the GPL. This might mean GPL is not an option without removing some functionality.

I am concerned about this affecting upstreaming features to Gitea. Does Forgejo want to become a hard fork at some point in the future? If you want to continue upstreaming features, it seems like Gitea developers are averse to GPL contributions. They do use dependencies under another copyleft license (albeit a weaker one), MPL-2.0 (github.com/6543/go-version, github.com/hashicorp/golang-lru, github.com/go-sql-driver/mysql), so they may be open to having MPL-2.0 code in their codebase itself. MPL-2.0 is explicitly compatible with the GPL, so it wouldn't limit the ability to have GPL code or relicense the MPL code to GPL-3.0-or-later in the future. It may be best to discuss licenses with upstream, if upstreaming is still desired. Additionally, Forgejo/Gitea has a dependency (elkjs) with an EPL-2.0 license, which appears incompatible with the GPL. This might mean GPL is not an option without removing some functionality.

👍 1

Ghost commented

2023-05-16 18:13:44 +02:00

I am concerned about this affecting upstreaming features to Gitea.

Forgejo being copyleft does not prevent developers from contributing to Gitea under another license. Or to the many other Forgejo dependencies that are not copyleft for that matter.

Does Forgejo want to become a hard fork at some point in the future?

There is no plan to do that. There is no competition with Gitea: it is a dependency of Forgejo. Some patches may be found in Forgejo while they are being discussed for inclusion in Gitea. It is the same for patches on ACT etc. But the goal is that they are merged so that the Forgejo changes to Gitea are reduced to the minimum.

Additionally, Forgejo/Gitea has a dependency (elkjs) with an EPL-2.0 license, which appears incompatible with the GPL. This might mean GPL is not an option without removing some functionality.

Good catch, that deserves a closer look.

> I am concerned about this affecting upstreaming features to Gitea. Forgejo being copyleft does not prevent developers from contributing to Gitea under another license. Or to the many other Forgejo dependencies that are not copyleft for that matter. > Does Forgejo want to become a hard fork at some point in the future? There is no plan to do that. There is no competition with Gitea: it is a dependency of Forgejo. Some patches may be found in Forgejo while they are being discussed for inclusion in Gitea. It is the same for patches on ACT etc. But the goal is that they are merged so that the Forgejo changes to Gitea are reduced to the minimum. > Additionally, Forgejo/Gitea has a dependency (elkjs) with an EPL-2.0 license, which appears incompatible with the GPL. This might mean GPL is not an option without removing some functionality. Good catch, that deserves a closer look.

👎 1

Ghost commented

2023-05-16 18:25:36 +02:00

Unless I'm mistaken elkjs is included but not used. It is an alternative to the default rendering engine for mermaid. Removing it for the sake of license compatibility would not remove any functionality.

I suppose someone should also file a bug to mermaid because it is licensed under MIT and some users may not be inclined to agree with the terms of the EPL.

Unless I'm mistaken elkjs is included but not used. It is an alternative to [the default rendering engine](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/defaultConfig.ts#L247-L259) for mermaid. Removing it for the sake of license compatibility would not remove any functionality. I suppose someone should also file a bug to mermaid because it is licensed under MIT and some users may not be inclined to agree with the terms of the EPL.

gwymor commented

2023-05-22 17:10:48 +02:00

First-time contributor

If the goal is for as few patches as possible to stay downstream-only, accepting patches under a license upstream Gitea won't accept seems like only an obstacle to that, creating the opportunity for situations where someone has contributed to Forgejo, who doesn't then contribute upstream under an acceptable license. Only that contributor has the ability to bring it upstream under a different license, and if they don't (e.g. because they don't want to take the time and effort, which is reasonable), that will result in Forgejo diverging more, and increasing the maintenance burden. And if the intention is for patches to be brought upstream under Gitea's MIT license, what is the point in them temporarily having the stronger protections of the GPL?

The best course of action to me seems to be coordinating with Gitea to find a copyleft license that is as strong as it can be while still being acceptable for upstream inclusion. That way, anyone can attempt to bring features upstream, there is little risk of significant divergence increasing Forgejo's maintenance burden, and at no point are these patches covered under the more permissive MIT.

Unless I'm mistaken elkjs is included but not used. It is an alternative to the default rendering engine for mermaid. Removing it for the sake of license compatibility would not remove any functionality.

I see. Thanks for looking into it.

If the goal is for as few patches as possible to stay downstream-only, accepting patches under a license upstream Gitea won't accept seems like only an obstacle to that, creating the opportunity for situations where someone has contributed to Forgejo, who doesn't then contribute upstream under an acceptable license. Only that contributor has the ability to bring it upstream under a different license, and if they don't (e.g. because they don't want to take the time and effort, which is reasonable), that will result in Forgejo diverging more, and increasing the maintenance burden. And if the intention is for patches to be brought upstream under Gitea's MIT license, what is the point in them temporarily having the stronger protections of the GPL? The best course of action to me seems to be coordinating with Gitea to find a copyleft license that is as strong as it can be while still being acceptable for upstream inclusion. That way, anyone can attempt to bring features upstream, there is little risk of significant divergence increasing Forgejo's maintenance burden, and at no point are these patches covered under the more permissive MIT. > Unless I'm mistaken elkjs is included but not used. It is an alternative to the default rendering engine for mermaid. Removing it for the sake of license compatibility would not remove any functionality. I see. Thanks for looking into it.

earl-warren commented

2023-05-22 19:22:39 +02:00

Contributor

@gwymor this is well put.

There is an equilibrium to find between accumulating too much technical debt and excluding code from entering the Forgejo codebase. This balance also exists for other reasons besides license incompatibilities.

There is a lot going on in Forgejo regarding the CI and the release pipeline and this work can't be shared with Gitea because it uses an entirely different framework.

The same is true for branding: it is likely to converge eventually into a set of patches allowing white labeling of Forgejo but in the meantime there are dozens of patches carefully managed to do something similar.

In the past few days a discussion started regarding the strategy to manage database migrations and avoid conflicts when rebasing.

When a copyleft library (I'm thinking a significant work and not just a few lines of code which are not worth the burden) enters the Forgejo codebase, it will have to be managed in the same way, keeping it as separated as possible from the dependencies (Gitea but possibly others) that won't accept this contribution because they do not welcome copyleft.

It may seem like a lot of work but I think it is worth my time (others may have a different opinion). It is small compared to the work done by dozens of developers working daily on git, Gitea, Woodpecker CI, ssh, Alpine and the hundreds of other dependencies.

My 2cts.

@gwymor this is well put. There is an equilibrium to find between accumulating too much technical debt and excluding code from entering the Forgejo codebase. This balance also exists for other reasons besides license incompatibilities. There is a lot going on in Forgejo regarding the CI and the release pipeline and this work can't be shared with Gitea because it uses an entirely different framework. The same is true for branding: it is likely to converge eventually into a set of patches allowing white labeling of Forgejo but in the meantime there are dozens of patches carefully managed to do something similar. In the past few days a [discussion started](https://codeberg.org/forgejo/discussions/issues/32) regarding the strategy to manage database migrations and avoid conflicts when rebasing. When a copyleft library (I'm thinking a significant work and not just a few lines of code which are not worth the burden) enters the Forgejo codebase, it will have to be managed in the same way, keeping it as separated as possible from the dependencies (Gitea but possibly others) that won't accept this contribution because they do not welcome copyleft. It may seem like a lot of work but I think it is worth my time (others may have a different opinion). It is small compared to the work done by dozens of developers working daily on git, Gitea, Woodpecker CI, ssh, Alpine and the hundreds of other dependencies. My 2cts.

oliverpool commented

2023-05-24 19:44:53 +02:00

Author

Member

@gwymor thank you for raising this point. I would propose the following guidelines:

There should be only one license for a given "package" (go package / js folder / equivalent unit of code...)
Contribution to the package should be made available under the existing package license

This would mean:

that any file modification or addition within a package keeps the upstream license (eases upstream backporting, except when adding a copyleft dependency without linking exception)
that new licenses can only be introduced with a completely new package/dependency

@earl-warren would it make sense for the F3 forgejo-driver? (this is the only actual usecase that I have in mind)

@gwymor does it seem a sensible solution?

@gwymor thank you for raising this point. I would propose the following guidelines: 1. There should be only one license for a given "package" (go package / js folder / equivalent unit of code...) 2. Contribution to the package should be made available under the existing package license This would mean: - that any file modification or addition within a package keeps the upstream license (eases upstream backporting, except when adding a copyleft dependency without linking exception) - that new licenses can only be introduced with a completely new package/dependency @earl-warren would it make sense for the F3 forgejo-driver? (this is the only actual usecase that I have in mind) @gwymor does it seem a sensible solution?

earl-warren commented

2023-09-10 17:41:11 +02:00

Contributor

@earl-warren would it make sense for the F3 forgejo-driver? (this is the only actual usecase that I have in mind)

I think it would send the wrong message because it is a component that is dedicated to interoperability. I think it would make no difference in practice, but the perception would not be great and it could be characterized as having an attitude that goes against interoperability.

> @earl-warren would it make sense for the F3 forgejo-driver? (this is the only actual usecase that I have in mind) I think it would send the wrong message because it is a component that is dedicated to interoperability. I think it would make no difference in practice, but the perception would not be great and it could be characterized as having an attitude that goes against interoperability.

👍 2

earl-warren commented

2023-10-20 17:49:18 +02:00

Contributor

This PR has been pending for a very long time, but it is also a very important one and I believe it can now be merged. There has been thumbs down from a single user who has not explained or asked anything.

Merging this.

This PR has been pending for a very long time, but it is also a very important one and I believe it can now be merged. There has been thumbs down from a single user who has not explained or asked anything. Merging this.