earl-warren commented 2024年07月17日 16:30:58 +02:00

In June last year an agreement was reached by which:

Forgejo accepts contributions compatible with the GPLv3-or-later license. The license under which Forgejo is distributed will be changed upon the acceptance of such contributions. See the LICENSE file for the current license.

This has not happened yet but there now are three pull requests in flight that have copylefted code in them. Before they can be merged, some preliminary steps must be taken. They are a matter of a few hours of work, they do not require any governance decision. From the top of my head:

• the FAQ must be modified
• license headers of Forgejo that advertise it is MIT as a whole must be changed
• a blog post must be prepared and published to announce this is happening now so noone is taken by surprise

and probably a few more. Once this is done those pull requests can be merged and Forgejo enters a new era of freedom ❤️

---

Update 19 July 2024: the title of the discussion was changed to reflect its shift in focus.

In [June last year](https://codeberg.org/forgejo/governance/pulls/24) an agreement [was reached](https://codeberg.org/forgejo/governance/src/branch/main/AGREEMENTS.md#licensing) by which: > Forgejo accepts contributions compatible with the GPLv3-or-later license. The license under which Forgejo is distributed will be changed upon the acceptance of such contributions. See the LICENSE file for the current license. This has not happened yet but there now are three pull requests in flight that have copylefted code in them. Before they can be merged, some preliminary steps must be taken. They are a matter of a few hours of work, they do not require any governance decision. From the top of my head: * the FAQ must be modified * license headers of Forgejo that advertise it is MIT as a whole must be changed * a blog post must be prepared and published to announce this is happening now so noone is taken by surprise and probably a few more. Once this is done those pull requests can be merged and Forgejo enters a new era of freedom ❤️ --- Update 19 July 2024: the title of the discussion was changed to reflect its shift in focus.

0ko commented 2024年07月17日 17:19:04 +02:00

the FAQ must be modified

FAQ:

As of January 2024, such a contribution has not been made yet.

It can only be updated if such contribution is already merged, it wouldn't make sense otherwise.

license headers of Forgejo that advertise it is MIT as a whole must be changed

Why? License headers are per-file.

a blog post must be prepared and published to announce this is happening now so noone is taken by surprise

So a separate blog post or a next monthly update will do it?
Since copyleft code is already allowed, nobody should be taken by a surprise that copyleft code gets merged.

> the FAQ must be modified FAQ: > As of January 2024, such a contribution has not been made yet. It can only be updated if such contribution is already merged, it wouldn't make sense otherwise. > license headers of Forgejo that advertise it is MIT as a whole must be changed Why? License headers are per-file. > a blog post must be prepared and published to announce this is happening now so noone is taken by surprise So a separate blog post or a next monthly update will do it? Since copyleft code is already allowed, nobody should be taken by a surprise that copyleft code gets merged.

earl-warren commented 2024年07月17日 17:29:33 +02:00

For now AGPL is not agreed upon. It is not compatible with the agreed upon GPLv3+.

https://www.gnu.org/licenses/license-list.en.html#AGPLv3.0

For now AGPL is not agreed upon. It is not compatible with the agreed upon GPLv3+. https://www.gnu.org/licenses/license-list.en.html#AGPLv3.0

0ko commented 2024年07月17日 17:30:30 +02:00

a license compatible with the one agreed upon must be chosen

So AGPL isn't compatible with GPLv3-or-later? What is then?

https://www.gnu.org/licenses/license-list.en.html#AGPLv3.0

It only says that AGPL code can't be converted to GPL code (without authors permissions?). We were not going to do this in the first place, so I don't see this as an incompatibility. If a file is created with AGPL, it stays with AGPL, that's ok, why we would want to change this file to GPL?

...even GNU's site says:

It is also technically not compatible with GPLv3 in a strict sense

Does this strict sense affects us?

> > > a license compatible with the one agreed upon must be chosen > > So AGPL isn't compatible with GPLv3-or-later? What is then? > https://www.gnu.org/licenses/license-list.en.html#AGPLv3.0 It only says that AGPL code can't be converted to GPL code (without authors permissions?). We were not going to do this in the first place, so I don't see this as an incompatibility. If a file is created with AGPL, it stays with AGPL, that's ok, why we would want to change this file to GPL? ...even GNU's site says: > It is also technically not compatible with GPLv3 in a strict sense Does this strict sense affects us?

0ko commented 2024年07月17日 17:31:01 +02:00

We don't have great timings sending messages today. 🙃

We don't have great timings sending messages today. 🙃

earl-warren commented 2024年07月17日 17:31:49 +02:00

license headers of Forgejo that advertise it is MIT as a whole must be changed

Why? License headers are per-file.

I meant the file that applies to Forgejo as a whole, not to each individual file. Sorry for the confusion.

https://codeberg.org/forgejo/forgejo/src/branch/forgejo/LICENSE

> > license headers of Forgejo that advertise it is MIT as a whole must be changed > > Why? License headers are per-file. I meant the file that applies to Forgejo as a whole, not to each individual file. Sorry for the confusion. https://codeberg.org/forgejo/forgejo/src/branch/forgejo/LICENSE

earl-warren commented 2024年07月17日 17:35:26 +02:00

And also

well, you get the idea. There needs to be a little preparation because it is a change that has an impact that goes beyond the single file.

And also https://codeberg.org/forgejo/forgejo/src/commit/a0676486dd03bdf110b52ea906d15b784321d062/Dockerfile#L63 https://codeberg.org/forgejo/forgejo/src/commit/a0676486dd03bdf110b52ea906d15b784321d062/Dockerfile.rootless#L60 well, you get the idea. There needs to be a little preparation because it is a change that has an impact that goes beyond the single file.

0ko commented 2024年07月17日 17:35:50 +02:00

For now AGPL is not agreed upon. It is not compatible with the agreed upon GPLv3+.

It's very important to list the licenses which Forgejo would (or would not) accept instead of saying compatible with the GPLv3-or-later license. Otherwise it causes this confusion where AGPL contributions are created and even merged (by me).

> For now AGPL is not agreed upon. It is not compatible with the agreed upon GPLv3+. It's very important to list the licenses which Forgejo would (or would not) accept instead of saying `compatible with the GPLv3-or-later license`. Otherwise it causes this confusion where AGPL contributions are created and even merged (by me).

Ghost commented 2024年07月17日 17:40:34 +02:00

Agreed. It'll be easier to have a list which one can refer to with license choice/validation. Less ambiguity for reviewers and contributors.

Agreed. It'll be easier to have a list which one can refer to with license choice/validation. Less ambiguity for reviewers and contributors.

earl-warren commented 2024年07月17日 17:42:58 +02:00

Since copyleft code is already allowed, nobody should be taken by a surprise that copyleft code gets merged.

There is no doubt that was well prepared, long in advance. But I think reasonable to assume it was overlooked by most Forgejo users who joined since the decision. This communication is for their benefit.

> Since copyleft code is already allowed, nobody should be taken by a surprise that copyleft code gets merged. There is no doubt that was well prepared, long in advance. But I think reasonable to assume it was overlooked by most Forgejo users who joined since the decision. This communication is for their benefit.

earl-warren commented 2024年07月17日 17:45:52 +02:00

For now AGPL is not agreed upon. It is not compatible with the agreed upon GPLv3+.

It's very important to list the licenses which Forgejo would (or would not) accept instead of saying compatible with the GPLv3-or-later license. Otherwise it causes this confusion where AGPL contributions are created and even merged (by me).

When in doubt you can refer to https://www.gnu.org/licenses/license-list.en.html which is the best list I know. And if there is a doubt using GPLv3+ is the fallback that solves it.

This is a very difficult area to navigate and it may be simpler to just not consider compatible licenses and stick to GPLv3+ since it was agreed upon. That will save valuable time to everyone and avoid the inevitable mistakes.

Let's keep it simple.

> > For now AGPL is not agreed upon. It is not compatible with the agreed upon GPLv3+. > > It's very important to list the licenses which Forgejo would (or would not) accept instead of saying `compatible with the GPLv3-or-later license`. Otherwise it causes this confusion where AGPL contributions are created and even merged (by me). When in doubt you can refer to https://www.gnu.org/licenses/license-list.en.html which is the best list I know. And if there is a doubt using GPLv3+ is the fallback that solves it. This is a very difficult area to navigate and it may be simpler to just not consider compatible licenses and stick to GPLv3+ since it was agreed upon. That will save valuable time to everyone and avoid the inevitable mistakes. Let's keep it simple.

Gusted commented 2024年07月17日 17:55:06 +02:00

If I read this correctly, if you want to contribute copyleft backend code (code that actually gets into the forgejo binary and thus not tests) you can't use the GPL family, as AGPL isn't agreed upon. And you would need to use EUPL for example, is that correct? Using GPL for tests still should be okay as they don't need the extra clause that AGPL provides.

If I read this correctly, if you want to contribute copyleft backend code (code that actually gets into the forgejo binary and thus not tests) you can't use the GPL family, as AGPL isn't agreed upon. And you would need to use EUPL for example, is that correct? Using GPL for tests still should be okay as they don't need the extra clause that AGPL provides.

bramh commented 2024年07月17日 18:03:55 +02:00

This is a very difficult area to navigate and it may be simpler to just not consider compatible licenses and stick to GPLv3+ since it was agreed upon. That will save valuable time to everyone and avoid the inevitable mistakes.

I think this is a good idea. My preference of course goes to AGPL but that is not what was agreed upon. I have no issues with relicensing my contributions to GPLv3+

> This is a very difficult area to navigate and it may be simpler to just not consider compatible licenses and stick to GPLv3+ since it was agreed upon. That will save valuable time to everyone and avoid the inevitable mistakes. I think this is a good idea. My preference of course goes to AGPL but that is not what was agreed upon. I have no issues with relicensing my contributions to GPLv3+

earl-warren commented 2024年07月17日 19:24:18 +02:00

I apologize to @algernon, @bramh and @0ko for stepping in and force their hand to revert the addition of AGPLv3-only code in the source tree. I though it was a bug and treated it like so. And this is because I did not take the time to follow the discussions on the matter in the chatroom or in the pull request. I would have realized that it was a conscious decision that was thought through.

I will step out of this discussion to not cause more confusion. I trust you to make sound legal decisions and should have consulted you instead of jumping to conclusions.

I apologize to @algernon, @bramh and @0ko for stepping in and force their hand to revert the addition of AGPLv3-only code in the source tree. I though it was a bug and treated it like so. And this is because I did not take the time to follow the discussions on the matter in the chatroom or in the pull request. I would have realized that it was a conscious decision that was thought through. I will step out of this discussion to not cause more confusion. I trust you to make sound legal decisions and should have consulted you instead of jumping to conclusions.

0ko commented 2024年07月17日 19:44:10 +02:00

I'm ok (and expect that others are too) that the code is re-added under some GPL3 (that isn't AGPL). This will require an explicit agreement from @bramh and @Gusted (as the author of ContextPopup.test.js). AGPL in Forgejo is still a complicated topic.

I'm ok (and expect that others are too) that the code is re-added under some GPL3 (that isn't AGPL). This will require an explicit agreement from @bramh and @Gusted (as the author of ContextPopup.test.js). AGPL in Forgejo is still a complicated topic.

0ko commented 2024年07月17日 19:50:43 +02:00

I would like to add some info regarding accepted licenses to places like agreements and FAQ, but I actually still don't fully know what we accept and don't accept.
My current assumption is:

• 🔴 AGPLv3 is not compatible with GPLv3
• 🟢 LGPLv3 is compatible with GPLv3
• 🟢 GPLv3 is GPLv3
• 🟢 EUPLv1.2 is compatible with GPLv3

I would like to add some info regarding accepted licenses to places like [agreements](https://codeberg.org/forgejo/governance/src/branch/main/AGREEMENTS.md#licensing) and FAQ, but I actually still don't fully know what we accept and don't accept. My current assumption is: * 🔴 AGPLv3 is not compatible with GPLv3 * 🟢 LGPLv3 is compatible with GPLv3 * 🟢 GPLv3 is GPLv3 * 🟢 EUPLv1.2 is compatible with GPLv3

Beowulf commented 2024年07月17日 19:55:06 +02:00

I think the question is also how we evaluate GPLv3-"or-later". (I'm never a fan of or-later because you never know what the new version will look like.) But if we have that in there, EUPL 1.2 might be out of bounds because it only specifies GPLv2 and GPLv3 presently, but not future versions of GPL. (But I don't want that usage of EUPL is prevented, I also like it and use it...)

Just my "speculative" thought.

I think the question is also how we evaluate GPLv3-"or-later". (I'm never a fan of or-later because you never know what the new version will look like.) But if we have that in there, EUPL 1.2 might be out of bounds because it only specifies GPLv2 and GPLv3 presently, but not future versions of GPL. (But I don't want that usage of EUPL is prevented, I also like it and use it...) Just my "speculative" thought.

bramh commented 2024年07月17日 19:56:17 +02:00

If I interpreted this correctly, EUPLv1.2 is not directly compatible with GPLv3?

If I interpreted [this](https://www.gnu.org/licenses/license-list.en.html#EUPL-1.2) correctly, EUPLv1.2 is not directly compatible with GPLv3?

bramh commented 2024年07月17日 20:00:59 +02:00

I apologize to @algernon, @bramh and @0ko for stepping in and force their hand to revert the addition of AGPLv3-only code in the source tree. I though it was a bug and treated it like so. And this is because I did not take the time to follow the discussions on the matter in the chatroom or in the pull request. I would have realized that it was a conscious decision that was thought through.

I will step out of this discussion to not cause more confusion. I trust you to make sound legal decisions and should have consulted you instead of jumping to conclusions.

FWIW I don't think you acted wrong in any way (don't forget that I initiated the reversal of my contribution by asking you! It wasn't done without my approval). AGPLv3-only was never explicitly agreed upon, and its compatibility with GPLv3 is confusing to say the least.

I don't think its fair to merge any AGPL contributions at this time as that is not what we agreed upon. The proposal is quite clear on it being a potential stepping stone towards AGPL, not a proposal for introducing AGPL-licensed code. If I had read the proposal a bit better I would've realized this before contributing.

> I apologize to @algernon, @bramh and @0ko for stepping in and force their hand to revert the addition of AGPLv3-only code in the source tree. I though it was a bug and treated it like so. And this is because I did not take the time to follow the discussions on the matter in the chatroom or in the pull request. I would have realized that it was a conscious decision that was thought through. > > I will step out of this discussion to not cause more confusion. I trust you to make sound legal decisions and should have consulted you instead of jumping to conclusions. FWIW I don't think you acted wrong in any way (don't forget that I initiated the reversal of my contribution by asking you! It wasn't done without my approval). AGPLv3-only was never explicitly agreed upon, and its compatibility with GPLv3 is confusing to say the least. I don't think its fair to merge any AGPL contributions at this time as that is not what we agreed upon. The proposal is quite clear on it being a potential stepping stone towards AGPL, not a proposal for introducing AGPL-licensed code. If I had read the proposal a bit better I would've realized this before contributing.

Beowulf commented 2024年07月17日 20:01:10 +02:00

Based on the EU strong copyleft does not really exist (in the form GPL defines it), because of the DIRECTIVE 2009/24/EC (Linking
of software is not a copyright-relevant act) - https://joinup.ec.europa.eu/collection/eupl/solution/eupl-freeopen-source-software-licence-european-union & https://joinup.ec.europa.eu/collection/eupl/news/copyleft-or-reciprocal

But as I said, I’m not a lawyer.

(This was intended as a partially answer to #192 (comment))

Based on the EU strong copyleft does not really exist (in the form GPL defines it), because of the [DIRECTIVE 2009/24/EC](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32009L0024&from=EN) (Linking of software is not a copyright-relevant act) - https://joinup.ec.europa.eu/collection/eupl/solution/eupl-freeopen-source-software-licence-european-union & https://joinup.ec.europa.eu/collection/eupl/news/copyleft-or-reciprocal But as I said, I’m not a lawyer. (This was intended as a partially answer to https://codeberg.org/forgejo/discussions/issues/192#issuecomment-2098390)

algernon commented 2024年07月17日 20:23:47 +02:00

No need to apologize to me, I had no intention of proposing AGPL contributions, EUPL was - and remains - my primary choice, would've used AGPL only if I couldn't use EUPL. I have little desire to contribute code under the GPL itself, if I can avoid it.

With that said, another issue I'd like to raise is case of the EUPL. The EUPL is explicitly compatible with GPL3-only. It is not compatible with GPL3-or-later.

I think a clarification would be nice - at least to me: do we require each individual license copyleft code can be submitted under to be GPL3-or-later compatible, or do we require that the effect of combining the MIT code, and the copyleft code result in something that is GPL3-or-later compatible?

My interpretation of the agreement was the latter, that the combination of MIT + copylefted code must be compatible with GPL3-or-later, which the EUPL 1.2 satisfies.

No need to apologize to me, I had no intention of proposing AGPL contributions, EUPL was - and remains - my primary choice, would've used AGPL only if I couldn't use EUPL. I have little desire to contribute code under the GPL itself, if I can avoid it. With that said, another issue I'd like to raise is case of the EUPL. The EUPL is explicitly compatible with `GPL3-only`. It is **not** compatible with `GPL3-or-later`. I think a clarification would be nice - at least to me: do we require each individual license copyleft code can be submitted under to be `GPL3-or-later` compatible, or do we require that the effect of combining the MIT code, and the copyleft code result in something that is `GPL3-or-later` compatible? My interpretation of the agreement was the latter, that the combination of MIT + copylefted code must be compatible with `GPL3-or-later`, which the EUPL 1.2 satisfies.

Gusted commented 2024年07月17日 20:33:06 +02:00

The intention was to allow AGPL as per the PR that added the agreement:

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 addition of -or-later seems like to not have a strong motivation:

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.

Given now that we're actually making use of this agreement, it doesn't seem to live up to the intention of the agreement as it's causing more problems than it should. AGPL should be accepted as a license to be used (we more or less have to, because GPL itself isn't usable for the code that goes into the forgejo binary) and the -or-later may not be compatible with some of the license we want to use such as the EUPL (personal preference).

I think revisiting this agreement and proposing to clarify this agreement to solve these issues would be best way forward, I don't see how we could comply easily with the existing agreement of being compatible with GPLv3-or-later.

The intention was to allow AGPL as [per the PR](https://codeberg.org/forgejo/governance/pulls/24) that added the agreement: > ### 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 addition of `-or-later` seems like to not have a strong motivation: > 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. Given now that we're actually making use of this agreement, it doesn't seem to live up to the intention of the agreement as it's causing more problems than it should. AGPL should be accepted as a license to be used (we more or less have to, because GPL itself isn't usable for the code that goes into the forgejo binary) and the `-or-later` may not be compatible with some of the license we want to use such as the EUPL (personal preference). I think revisiting this agreement and proposing to clarify this agreement to solve these issues would be best way forward, I don't see how we could comply _easily_ with the existing agreement of being compatible with `GPLv3-or-later`.

Ghost commented 2024年07月17日 22:34:26 +02:00

I don't see how we could comply easily with the existing agreement of being compatible with GPLv3-or-later.

https://codeberg.org/forgejo/governance/src/branch/main/AGREEMENTS.md#licensing

Forgejo accepts contributions compatible with the GPLv3-or-later license.

I will choose GPLv3-or-later, this is easy.

> I don't see how we could comply easily with the existing agreement of being compatible with GPLv3-or-later. https://codeberg.org/forgejo/governance/src/branch/main/AGREEMENTS.md#licensing > Forgejo accepts contributions compatible with the GPLv3-or-later license. I will choose GPLv3-or-later, this is easy.

n0toose commented 2024年07月17日 22:35:49 +02:00

AGPL should be accepted as a license to be used (we more or less have to, because GPL itself isn't usable for the code that goes into the forgejo binary) and the -or-later may not be compatible with some of the license we want to use such as the EUPL (personal preference).

Can dual-/triple-licensing (copyleft licenses) work here?

> AGPL should be accepted as a license to be used (we more or less have to, because GPL itself isn't usable for the code that goes into the forgejo binary) and the -or-later may not be compatible with some of the license we want to use such as the EUPL (personal preference). Can dual-/triple-licensing (copyleft licenses) work here?

algernon commented 2024年07月17日 22:38:39 +02:00

AGPL should be accepted as a license to be used (we more or less have to, because GPL itself isn't usable for the code that goes into the forgejo binary) and the -or-later may not be compatible with some of the license we want to use such as the EUPL (personal preference).

Can dual-/triple-licensing (copyleft licenses) work here?

It could, but that further complicates the matter in the long run. It would be easier, and clearer, if we didn't have to resort to that (nor downgrade to gpl3+).

> > AGPL should be accepted as a license to be used (we more or less have to, because GPL itself isn't usable for the code that goes into the forgejo binary) and the -or-later may not be compatible with some of the license we want to use such as the EUPL (personal preference). > > Can dual-/triple-licensing (copyleft licenses) work here? It could, but that further complicates the matter in the long run. It would be easier, and clearer, if we didn't have to resort to that (nor downgrade to gpl3+).

bramh commented 2024年07月18日 01:34:18 +02:00

I'll attempt to summarize some of today's discussions, both here and on Matrix. IANAL, but I'll try to provide as many sources for my reasoning as possible.

GPL-3.0-or-later compatibility

The current agreement, forgejo/governance#24, allows contributions that are compatible with GPL-3.0-or-later. The intention of this agreement seems to be also to allow AGPL-3.0-or-later amongst other copyleft licenses, whether this is allowed in the current form of the agreement is unclear.

Strictly speaking, AGPLv3 is not compatible with GPLv3:

[GNU AGPL] is also technically not compatible with GPLv3 in a strict sense: you cannot take code released under the GNU AGPL and convey or modify it however you like under the terms of GPLv3, or vice versa. (gnu.org)

However, as per section 13 of both licenses, it is possible to use both of them in the same project:

• GPLv3:

  13. Use with the GNU Affero General Public License.

  Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU Affero General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the special requirements of the GNU Affero General Public License, section 13, concerning interaction through a network will apply to the combination as such. (gnu.org)

• AGPLv3:

  13. Remote Network Interaction; Use with the GNU General Public License.

  [...]

  Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License. (gnu.org)

The combined work must therefore comply with both the GPLv3 and AGPLv3 licenses simultaneously, which means the entire project must be licensed under the terms of the more restrictive AGPLv3 license. Individual parts will still be licensed under their respective license.

This is where the issue with the agreement lies. While GPLv3 and AGPLv3 are compatible in the sense that they can coexist within the same codebase, the project cannot be licensed under GPL-3.0-or-later as agreed upon with AGPLv3 licensed code present. There are two possible interpretations of forgejo/governance#24:

1. Forgejo is to be licensed under GPL-3.0-or-later, meaning AGPL-3.0-or-later contributions are not allowed
2. Contributions must be compatible with GPL-3.0-or-later, while Forgejo is to be licensed under AGPL-3.0-or-later allowing for AGPL contributions to be made.

Compatibility with EUPL-1.2

Additionally, the '-or-later' part of the agreed upon GPL-3.0-or-later license is problematic for EUPL-1.2 licensed code:

By itself, [EUPL] has a copyleft comparable to the GPL's, and incompatible with it. [...]

The EUPL allows relicensing to GPLv2 only and GPLv3 only, because those licenses are listed as two of the alternative licenses that users may convert to. (gnu.org)

The exact clause (compatibility clause) is as follows:

Compatibility clause: If the Licensee Distributes or Communicates Derivative Works or copies thereof based upon both the Work and another work licensed under a Compatible Licence, this Distribution or Communication can be done under the terms of this Compatible Licence. For the sake of this clause, 'Compatible Licence' refers to the licences listed in the appendix attached to this Licence. Should the Licensee's obligations under the Compatible Licence conflict with his/her obligations under this Licence, the obligations of the Compatible Licence shall prevail. (europa.eu)

Compatible licenses include GPL-2.0-only, GPL-3.0-only, AGPL-3.0-only. GPL-3.0-or-later is not a compatible license.

As for the '-or-later' part in the agreement, the following reasoning was given:

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) (forgejo/governance#24)

It should be noted that CECILL-2.1 is also a compatible license, which means EUPL-1.2 contributions could be compatible with GPL-3.0-or-later due to the following clause in CECILL-2.1:

5.3.4. COMPATIBILITY WITH OTHER LICENSES

[...]

The Licensee can include the Modified or unmodified Software in a code that is subject to the provisions of one of the versions of the GNU GPL, GNU Affero GPL and/or EUPL and distribute that entire code under the terms of the same version of the GNU GPL, GNU Affero GPL and/or EUPL. (cecill.info)

Though it might be better to avoid this if possible, as it will only complicate things:

To do this two-step relicensing, you need to first write a piece of code which you can license under the CeCILL v2, or find a suitable module already available that way, and add it to the program. Adding that code to the EUPL-covered program provides grounds to relicense it to the CeCILL v2. Then you need to write a piece of code which you can license under the GPLv3+, or find a suitable module already available that way, and add it to the program. Adding that code to the CeCILL-covered program provides grounds to relicense it to GPLv3+. (gnu.org)

I'll attempt to summarize some of today's discussions, both here and on Matrix. IANAL, but I'll try to provide as many sources for my reasoning as possible. # GPL-3.0-or-later compatibility The current agreement, https://codeberg.org/forgejo/governance/pulls/24, allows contributions that are compatible with GPL-3.0-or-later. The intention of this agreement seems to be also to allow AGPL-3.0-or-later amongst other copyleft licenses, whether this is allowed in the current form of the agreement is unclear. Strictly speaking, AGPLv3 is not compatible with GPLv3: > [GNU AGPL] is also technically not compatible with GPLv3 in a strict sense: you cannot take code released under the GNU AGPL and convey or modify it however you like under the terms of GPLv3, or vice versa. ([gnu.org](https://www.gnu.org/licenses/license-list.en.html#AGPLv3.0)) However, as per section 13 of both licenses, it is possible to use both of them in the same project: - GPLv3: > 13\. Use with the GNU Affero General Public License. > > Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU Affero General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the special requirements of the GNU Affero General Public License, section 13, concerning interaction through a network will apply to the combination as such. ([gnu.org](https://www.gnu.org/licenses/gpl-3.0.html)) - AGPLv3: > 13\. Remote Network Interaction; Use with the GNU General Public License. > > [...] > > Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License. ([gnu.org](https://www.gnu.org/licenses/agpl-3.0.html)) The combined work must therefore comply with both the GPLv3 and AGPLv3 licenses simultaneously, which means the entire project must be licensed under the terms of the more restrictive AGPLv3 license. Individual parts will still be licensed under their respective license. This is where the issue with the agreement lies. While GPLv3 and AGPLv3 are compatible in the sense that they can coexist within the same codebase, the project cannot be licensed under GPL-3.0-or-later as agreed upon with AGPLv3 licensed code present. There are two possible interpretations of https://codeberg.org/forgejo/governance/pulls/24: 1. Forgejo is to be licensed under GPL-3.0-or-later, meaning AGPL-3.0-or-later contributions are not allowed 2. Contributions must be compatible with GPL-3.0-or-later, while Forgejo is to be licensed under AGPL-3.0-or-later allowing for AGPL contributions to be made. # Compatibility with EUPL-1.2 Additionally, the '-or-later' part of the agreed upon GPL-3.0-or-later license is problematic for EUPL-1.2 licensed code: > By itself, [EUPL] has a copyleft comparable to the GPL's, and incompatible with it. [...] > > The EUPL allows relicensing to GPLv2 only and GPLv3 only, because those licenses are listed as two of the alternative licenses that users may convert to. ([gnu.org](https://www.gnu.org/licenses/license-list.en.html#EUPL-1.2)) The exact clause (compatibility clause) is as follows: > Compatibility clause: If the Licensee Distributes or Communicates Derivative Works or copies thereof based upon both the Work and another work licensed under a Compatible Licence, this Distribution or Communication can be done under the terms of this Compatible Licence. For the sake of this clause, 'Compatible Licence' refers to the licences listed in the appendix attached to this Licence. Should the Licensee's obligations under the Compatible Licence conflict with his/her obligations under this Licence, the obligations of the Compatible Licence shall prevail. ([europa.eu](https://joinup.ec.europa.eu/sites/default/files/custom-page/attachment/2020-03/EUPL-1.2%20EN.txt)) Compatible licenses include GPL-2.0-only, GPL-3.0-only, AGPL-3.0-only. GPL-3.0-or-later is not a compatible license. As for the '-or-later' part in the agreement, the following reasoning was given: > 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) (https://codeberg.org/forgejo/governance/pulls/24) It should be noted that CECILL-2.1 is also a compatible license, which means EUPL-1.2 contributions could be compatible with GPL-3.0-or-later due to the following clause in CECILL-2.1: > 5.3.4. COMPATIBILITY WITH OTHER LICENSES > > [...] > > The Licensee can include the Modified or unmodified Software in a code that is subject to the provisions of one of the versions of the GNU GPL, GNU Affero GPL and/or EUPL and distribute that entire code under the terms of the same version of the GNU GPL, GNU Affero GPL and/or EUPL. ([cecill.info](http://www.cecill.info/licences/Licence_CeCILL_V2.1-en.html)) Though it might be better to avoid this if possible, as it will only complicate things: > To do this two-step relicensing, you need to first write a piece of code which you can license under the CeCILL v2, or find a suitable module already available that way, and add it to the program. Adding that code to the EUPL-covered program provides grounds to relicense it to the CeCILL v2. Then you need to write a piece of code which you can license under the GPLv3+, or find a suitable module already available that way, and add it to the program. Adding that code to the CeCILL-covered program provides grounds to relicense it to GPLv3+. ([gnu.org](https://www.gnu.org/licenses/license-list.en.html#EUPL-1.2))

bramh commented 2024年07月18日 01:34:25 +02:00

Previous attempts to license Forgejo under AGPL-3.0 have been unproductive: forgejo/meta#86, #6. I would like to make another case for licensing Forgejo under AGPL-3.0-only based on what we've learned from forgejo/governance#24:

1. AGPL-3.0-only allows for a wide range of copyleft licenses to be accepted, such as GPL-3.0-only, AGPL-3.0-only and EUPL-1.2. MIT is of course also accepted.
2. I believe Forgejo would benefit from the additional networking clause, as Forgejo is networked software.
3. People seem to disagree on the '-or-later' part of GPL:

   1. I must admit that I struggle with that ["or later"] clause for works where the FSF is not the copyright holder - I don't see what teeth it has, legally, in that situation.

      • Neil Brown, forgejo/meta#86 (comment)

   2. On balance I'd say GNU-land projects should use AGPL "or later" & others should not. But IANAL!

      • Simon Phipps, forgejo/meta#86 (comment)

Regardless of the chosen license, forgejo/governance#24 will need to be further clarified or superseded. Additionally, I would like to see a list of allowed compatible licenses so that there will not be any further confusion for contributors and reviewers.

Previous attempts to license Forgejo under AGPL-3.0 have been unproductive: https://codeberg.org/forgejo/meta/issues/86, https://codeberg.org/forgejo/discussions/issues/6. I would like to make another case for licensing Forgejo under AGPL-3.0-only based on what we've learned from https://codeberg.org/forgejo/governance/pulls/24: 1. AGPL-3.0-only allows for a wide range of copyleft licenses to be accepted, such as GPL-3.0-only, AGPL-3.0-only and EUPL-1.2. MIT is of course also accepted. 2. I believe Forgejo would benefit from the additional networking clause, as Forgejo is networked software. 3. People seem to disagree on the '-or-later' part of GPL: 1. > I must admit that I struggle with that ["or later"] clause for works where the FSF is not the copyright holder - I don't see what teeth it has, legally, in that situation. * Neil Brown, https://codeberg.org/forgejo/meta/issues/86#issuecomment-780615 2. > On balance I'd say GNU-land projects should use AGPL "or later" & others should not. But IANAL! * Simon Phipps, https://codeberg.org/forgejo/meta/issues/86#issuecomment-784347 Regardless of the chosen license, https://codeberg.org/forgejo/governance/pulls/24 will need to be further clarified or superseded. Additionally, I would like to see a list of allowed compatible licenses so that there will not be any further confusion for contributors and reviewers.

algernon commented 2024年07月18日 09:49:53 +02:00

After a good night's sleep, and reading a couple of sources @Gusted pointed me to last night, I think I'd like to ignore my previous comments, and start again.

License compatibility

forgejo/governance#24 says:

Forgejo accepts contributions compatible with the GPLv3-or-later license.

I'd like to focus on this part first, both the relation to the AGPL, and how -or-later relates to the EUPL.

AGPL

Lets address the AGPL first!

GNU themselves say this:

[...] you are allowed to combine separate modules or source files released under both of those licenses in a single project, which will provide many programmers with all the permission they need to make the programs they want.

Reading section 13 of both licenses, my conclusion here is that combining separate GPL-3.0 and AGPL-3.0 licensed files in one project is fine, and results in the combined work being distributable under the AGPL-3.0. Since GPL-3.0 explicitly permits upgrading to AGPL-3.0 (which is what section 13 of both licenses is about), it is compatible with GPL-3.0.

GNU agrees, and lists the AGPL3 as GPL3 compatible.

EUPL

Moving on to the EUPL: the EUPL allows a combined work to be distributed under GPL-3.0-only. It has no provisions about gpl-3.0-or-later. My initial thought was that this makes it gpl-3.0-only compatible, but not compatible with gpl-3.0-or-later. However! GNU has this to say about combining -only with -or-later:

While you may release under GPLv2-or-later both your original work, and/or modified versions of work you received under GPLv2-or-later, the GPLv2-only code that you're using must remain under GPLv2 only. As long as your project depends on that code, you won't be able to upgrade the license of your own code to GPLv3-or-later, and the work as a whole (any combination of both your project and the other code) can only be conveyed under the terms of GPLv2.

In other words, since the EUPL allows distributing the combined work under gpl-3.0-only, such combination can be incorporated into a gpl-3.0-or-later codebase, making it gpl-3.0-or-later compatible. The combined work then can only be distributed under gpl-3.0-only, but the work can be combined, and this combination can still be combined with gpl-3.0-or-later work. Thus, gpl-3.0-only is compatible with gpl-3.0-or-later, and by extension, so is the EUPL.

On the other hand, GNU also lists the EUPL under the non-GPL-compatible licenses, because the EUPL allows a side-grade to GPL-3.0-only, it is possible to distribute EUPL & GPL-3.0-or-later code as gpl-3.0-only. It is not possible to distribute it under gpl-3.0-or-later, hence GNU listing it as incompatible.

I must also note that the AGPL is not strictly compatible with the GPL either, GNU says:

It is also technically not compatible with GPLv3 in a strict sense: you cannot take code released under the GNU AGPL and convey or modify it however you like under the terms of GPLv3, or vice versa. However, you are allowed to combine separate modules or source files released under both of those licenses in a single project, which will provide many programmers with all the permission they need to make the programs they want. See section 13 of both licenses for details.

I believe the same kind of combination should apply to EUPL too, because the footnote referenced above does suggest that you can combine -or-later and -only into -only.

Summary

With the above in mind, I believe both AGPL and EUPL satisfy the requirements of forgejo/governance#24. The AGPL case is the easier, because GNU themselves classify them as compatible.

The EUPL case is harder, because GNU classifies them as incompatible, due to the combined work not being distributable under gpl-3.0-or-later, only under gpl-3.0-only. However, the agreement says that the incoming license must be gpl-3.0-or-later compatible (which the EUPL is), it does not say that the combined work must also be gpl-3.0-or-later. Even if it did say that the combined work must also be gpl-3.0-or-later compatible, that'd still render the EUPL fine, because gpl-3.0-only is compatible.

What the EUPL does not allow is distributing the combined work under gpl-3.0-or-later, but that's not a requirement of the agreement.

The combined license

The agreement doesn't say anything about the license Forgejo will be distributed under, after accepting a gpl-3.0-or-later compatible copyleft licensed contribution. It just says that the license under which Forgejo can be distributed will be changed, it does not say what it will be changed to. Obviously, to a license the combined work is distributable under.

The agreement does not say that the license Forgejo will be distributed under has to be gpl-3.0-or-later.

Suggestions

While I believe my assessment above to be correct, I am not a lawyer, and I have been wrong before (just a couple of comments back, too!). The two areas of confusion are the AGPL and EUPL situation. I think the former's easier to conclude, as GNU themselves list AGPL as GPL compatible, thus, in this regard, the agreement should not need further clarification.

The EUPL situation is a tiny bit harder, but as mentioned above, I believe that requiring the incoming license to be gpl-3.0-or-later compatible, without requiring the combiend license to be gpl-3.0-or-later is enough to make the EUPL an acceptable license too.

Nevertheless, to avoid further confusion, the agreement could - and probably should - be updated to list a non-exhaustive list of acceptable copyleft licenses. I'd suggest that list to include GPL3+, AGPL3+, EUPL1.2+, and MPL2.0.

Alternatively, we could amend the agreement to remove the gpl-3.0-or-later compatibility requirement, and instead require that the combined work remain distributable under an open source license. It seems to me, that the wording of the original agreement was to prevent Forgejo becoming AGPL immediately, but due to the AGPL being GPL compatible, the current wording does not achieve that. Since there was - and I believe still is - a consensus that copyleft contributions are fine, we could just... remove any barriers.

Or, as another alternative, we might consider asking an actual lawyer with copyleft experience, to help clarify the situation, and perhaps propose a way forward.

After a good night's sleep, and reading a couple of sources @Gusted pointed me to last night, I think I'd like to ignore my previous comments, and start again. ## License compatibility forgejo/governance#24 says: > Forgejo accepts contributions compatible with the [GPLv3-or-later](https://spdx.org/licenses/GPL-3.0-or-later.html) license. I'd like to focus on this part first, both the relation to the AGPL, and how `-or-later` relates to the EUPL. ### AGPL Lets address the AGPL first! GNU themselves [say this](https://www.gnu.org/licenses/license-list.en.html#AGPL): > [...] you are allowed to combine separate modules or source files released under both of those licenses in a single project, which will provide many programmers with all the permission they need to make the programs they want. Reading section 13 of both licenses, my conclusion here is that combining separate GPL-3.0 and AGPL-3.0 licensed files in one project is fine, and results in the combined work being distributable under the AGPL-3.0. Since GPL-3.0 explicitly permits upgrading to AGPL-3.0 (which is what section 13 of both licenses is about), it *is* compatible with GPL-3.0. GNU [agrees](https://www.gnu.org/licenses/license-list.en.html#AGPL), and lists the AGPL3 as GPL3 compatible. ### EUPL Moving on to the EUPL: the EUPL allows a combined work to be distributed under GPL-3.0-only. It has no provisions about gpl-3.0-or-later. My initial thought was that this makes it gpl-3.0-only compatible, but not compatible with gpl-3.0-or-later. However! GNU has [this to say](https://www.gnu.org/licenses/gpl-faq.html#compat-matrix-footnote-2) about combining `-only` with `-or-later`: > While you may release under GPLv2-or-later both your original work, and/or modified versions of work you received under GPLv2-or-later, the GPLv2-only code that you're using must remain under GPLv2 only. As long as your project depends on that code, you won't be able to upgrade the license of your own code to GPLv3-or-later, and the work as a whole (any combination of both your project and the other code) can only be conveyed under the terms of GPLv2. In other words, since the EUPL allows distributing the combined work under gpl-3.0-only, such combination can be incorporated into a gpl-3.0-or-later codebase, making it gpl-3.0-or-later compatible. The combined work then can only be distributed under gpl-3.0-only, but the work can be combined, and *this* combination can still be combined with gpl-3.0-or-later work. Thus, gpl-3.0-only *is* compatible with gpl-3.0-or-later, and by extension, so is the EUPL. On the other hand, GNU [also lists](https://www.gnu.org/licenses/license-list.html#EUPL-1.2) the EUPL under the non-GPL-compatible licenses, because the EUPL allows a side-grade to GPL-3.0-only, it is possible to distribute EUPL & GPL-3.0-or-later code as gpl-3.0-only. It is not possible to distribute it under gpl-3.0-or-later, hence GNU listing it as incompatible. I must also note that the AGPL is not strictly compatible with the GPL either, GNU [says](https://www.gnu.org/licenses/license-list.en.html#AGPL): > It is also technically not compatible with GPLv3 in a strict sense: you cannot take code released under the GNU AGPL and convey or modify it however you like under the terms of GPLv3, or vice versa. However, you are allowed to combine separate modules or source files released under both of those licenses in a single project, which will provide many programmers with all the permission they need to make the programs they want. See section 13 of both licenses for details. I believe the same kind of combination should apply to EUPL too, because the footnote referenced above does suggest that you can combine `-or-later` and `-only` into `-only`. ### Summary With the above in mind, I believe both AGPL and EUPL satisfy the requirements of forgejo/governance#24. The AGPL case is the easier, because GNU themselves classify them as compatible. The EUPL case is harder, because GNU classifies them as incompatible, due to the combined work not being distributable under gpl-3.0-or-later, only under gpl-3.0-only. However, the agreement says that the *incoming* license must be gpl-3.0-or-later compatible (which the EUPL is), it does *not* say that the *combined work* must *also* be gpl-3.0-or-later. Even if it did say that the combined work must also be gpl-3.0-or-later *compatible*, that'd still render the EUPL fine, because gpl-3.0-only is compatible. What the EUPL does not allow is distributing the combined work under gpl-3.0-or-later, but that's not a requirement of the agreement. ## The combined license The agreement doesn't say anything about the license Forgejo will be distributed under, after accepting a gpl-3.0-or-later compatible copyleft licensed contribution. It just says that the license under which Forgejo can be distributed will be changed, it does not say what it will be changed to. Obviously, to a license the combined work is distributable under. The agreement does not say that the license Forgejo will be distributed under has to be gpl-3.0-or-later. ## Suggestions While I believe my assessment above to be correct, I am not a lawyer, and I have been wrong before (just a couple of comments back, too!). The two areas of confusion are the AGPL and EUPL situation. I think the former's easier to conclude, as GNU themselves list AGPL as GPL compatible, thus, in this regard, the agreement should not need further clarification. The EUPL situation is a tiny bit harder, but as mentioned above, I believe that requiring the *incoming* license to be gpl-3.0-or-later compatible, without requiring the combiend license to *be* gpl-3.0-or-later is enough to make the EUPL an acceptable license too. Nevertheless, to avoid further confusion, the agreement could - and probably should - be updated to list a non-exhaustive list of acceptable copyleft licenses. I'd suggest that list to include GPL3+, AGPL3+, EUPL1.2+, and MPL2.0. Alternatively, we could amend the agreement to remove the gpl-3.0-or-later compatibility requirement, and instead require that the combined work remain distributable under an open source license. It seems to me, that the wording of the original agreement was to prevent Forgejo becoming AGPL immediately, but due to the AGPL being GPL compatible, the current wording does not achieve that. Since there was - and I believe still is - a consensus that copyleft contributions are fine, we could just... remove any barriers. Or, as another alternative, we might consider asking an actual lawyer with copyleft experience, to help clarify the situation, and perhaps propose a way forward.

fnetX commented 2024年07月18日 10:52:24 +02:00

One comment on EUPL: The European Commission is also allowed to publish newer versions of that license. In a sense, EUPLv1.2 is also EUPLv1.2-or-later as far as I can see. In my opinion, this makes it very likely that the license will be made compatible with future GPL licenses, as long as it is possible.

There is no guarantee, but the actual problem of being stuck with an old license version which does not reflect a more recent legal situation is probably void.

---

I see two ways forward. I am under the impression that a move to EUPL is a no-brainer. Two enterprise users of Forgejo indicated to me that they'd "likely be fine" with this move. So we can probably go ahead with EUPL.

However, changing licenses twice in short succession might be leading to confusion. So if we think that we want a stronger copyleft protection on our work, we should make this a careful process. In my role in user research, I propose we do a poll to assess the impact on our users. Let me know if I should prepare this?

The poll should not be taken as a "vote". The final say will follow our decision-making process. But it gives us an idea how our users will react to this, if we loose certain user groups etc.

One comment on EUPL: The European Commission is also allowed to publish newer versions of that license. In a sense, EUPLv1.2 is also EUPLv1.2-or-later as far as I can see. In my opinion, this makes it very likely that the license will be made compatible with future GPL licenses, as long as it is possible. There is no guarantee, but the actual problem of being stuck with an old license version which does not reflect a more recent legal situation is probably void. --- I see two ways forward. I am under the impression that a move to EUPL is a no-brainer. Two enterprise users of Forgejo indicated to me that they'd "likely be fine" with this move. So we can probably go ahead with EUPL. However, changing licenses twice in short succession might be leading to confusion. So if we think that we want a stronger copyleft protection on our work, we should make this a careful process. In my role in user research, I propose we do a poll to assess the impact on our users. Let me know if I should prepare this? The poll should not be taken as a "vote". The final say will follow our decision-making process. But it gives us an idea how our users will react to this, if we loose certain user groups etc.

Beowulf commented 2024年07月18日 11:43:26 +02:00

I am not the biggest fan of the GPL because it results in different rights for the licensee depending on the location (e.g. in the EU linking software is not a copyright relevant act, in the US it is). The EUPL, for example, solves this by always requiring jurisdiction in the EU.

I'm still fine with GPL3.0, but if I contribute code, I'd rather license it under the EUPL than under the GPL. But that's difficult with the "-or-later". My thought was, would it be possible to specify/limit the "-or-later" e.g. in the license? So, GPL-3.0-or-later with the condition: The newer versions must be compatible with the EUPL according to Article 5 of the EUPL (so it must be listed in the appendix).
So if GPL-4.0 comes out, you could also license the project under GPL-4.0 if it is compatible with the EUPL. (Whether this is possible at all, or whether it will be too complicated 🤷 ).

I am not the biggest fan of the GPL because it results in different rights for the licensee depending on the location (e.g. in the EU linking software is not a copyright relevant act, in the US it is). The EUPL, for example, solves this by always requiring jurisdiction in the EU. I'm still fine with GPL3.0, but if I contribute code, I'd rather license it under the EUPL than under the GPL. But that's difficult with the "-or-later". My thought was, would it be possible to specify/limit the "-or-later" e.g. in the license? So, GPL-3.0-or-later with the condition: The newer versions must be compatible with the EUPL according to Article 5 of the EUPL (so it must be listed in the appendix). So if GPL-4.0 comes out, you could also license the project under GPL-4.0 if it is compatible with the EUPL. (Whether this is possible at all, or whether it will be too complicated 🤷 ).

Beowulf commented 2024年07月18日 11:46:21 +02:00

One comment on EUPL: The European Commission is also allowed to publish newer versions of that license. In a sense, EUPLv1.2 is also EUPLv1.2-or-later as far as I can see. In my opinion, this makes it very likely that the license will be made compatible with future GPL licenses, as long as it is possible.

The appendix with the compatible licenses can always be updated with new compatible licenses:

The European Commission may update this Appendix to later versions of the above licences without producing
a new version of the EUPL, as long as they provide the rights granted in Article 2 of this Licence and protect the
covered Source Code from exclusive appropriation.

All other changes or additions to this Appendix require the production of a new EUPL version.

> One comment on EUPL: The European Commission is also allowed to publish newer versions of that license. In a sense, EUPLv1.2 is also EUPLv1.2-or-later as far as I can see. In my opinion, this makes it very likely that the license will be made compatible with future GPL licenses, as long as it is possible. The appendix with the compatible licenses can always be updated with new compatible licenses: > The European Commission may update this Appendix to later versions of the above licences without producing a new version of the EUPL, as long as they provide the rights granted in Article 2 of this Licence and protect the covered Source Code from exclusive appropriation. > > All other changes or additions to this Appendix require the production of a new EUPL version.

algernon commented 2024年07月18日 12:11:29 +02:00

I'm still fine with GPL3.0, but if I contribute code, I'd rather license it under the EUPL than under the GPL. But that's difficult with the "-or-later".

My view is that in this case, -or-later does not matter. The agreement only requires the incoming license to be gpl-3.0-or-later compatible. Since EUPL can be combined with gpl-3.0-or-later code, this requirement is satisfied. It will end up with a license resolved to gpl-3.0-only, but we can combine gpl-3.0-or-later and gpl-3.0-only (as per the footnote on GNU's license compatibility matrix, referenced a few comments back), thus, by extension, gpl-3.0-or-later and eupl-1.2 too. We can't convert either to the other, but that's not what we're doing, and not what the agreement asks us, either. We combine them, not convert them, and combining is allowed.

The agreement does not say anything about the resolved license, apart from it having to be update. Its compatibility requirement is only for the incoming license, not for the license of the combined work. As such, I believe the EUPL satisfies this requirement, and so does the AGPL.

> I'm still fine with GPL3.0, but if I contribute code, I'd rather license it under the EUPL than under the GPL. But that's difficult with the "-or-later". My view is that in *this* case, `-or-later` does not matter. The agreement *only* requires the incoming license to be `gpl-3.0-or-later` *compatible*. Since EUPL can be combined with `gpl-3.0-or-later` code, this requirement is satisfied. It *will* end up with a license resolved to `gpl-3.0-only`, but we *can* combine `gpl-3.0-or-later` and `gpl-3.0-only` (as per the footnote on GNU's license compatibility matrix, referenced a few comments back), thus, by extension, `gpl-3.0-or-later` and `eupl-1.2` too. We can't convert either to the other, but that's not what we're doing, and not what the agreement asks us, either. We combine them, not convert them, and combining is allowed. The agreement does *not* say anything about the resolved license, apart from it having to be update. Its compatibility requirement is only for the incoming license, not for the license of the combined work. As such, I believe the EUPL satisfies this requirement, and so does the AGPL.

Beowulf commented 2024年07月18日 12:19:11 +02:00

The agreement does not say anything about the resolved license

So we need a new agreement under which license forgejo would be licensed because the old agreement does not cover this?

> The agreement does not say anything about the resolved license So we need a new agreement under which license forgejo would be licensed because the old agreement does not cover this?

algernon commented 2024年07月18日 12:31:34 +02:00

The agreement does not say anything about the resolved license

So we need a new agreement under which license forgejo would be licensed because the old agreement does not cover this?

I don't think it needs to cover it. The current requirement of a gpl3+ compatible incoming license already guarantees that the result will also be gpl3+ compatible. What it resolves to... that's pretty much determined by the licenses used.

If we combine MIT + EUPL, that'll resolve to EUPL. If we combine MIT + AGPL, that'll be AGPL. If we combine MIT + EUPL + AGPL, it will be AGPL. All of those are gpl3 compatible, because all of those allow combining the work as a whole with a separate gpl3-or-later licensed body of work.

> > The agreement does not say anything about the resolved license > > So we need a new agreement under which license forgejo would be licensed because the old agreement does not cover this? I don't think it needs to cover it. The current requirement of a gpl3+ compatible incoming license already guarantees that the result will also be gpl3+ compatible. What it resolves to... that's pretty much determined by the licenses used. If we combine MIT + EUPL, that'll resolve to EUPL. If we combine MIT + AGPL, that'll be AGPL. If we combine MIT + EUPL + AGPL, it will be AGPL. All of those are gpl3 compatible, because all of those allow combining the work as a whole with a separate gpl3-or-later licensed body of work.

bramh commented 2024年07月18日 12:37:48 +02:00

Should there still not be an agreement on what license Forgejo is distributed under, to prevent changing the license multiple times within a short time period? If I understood correctly, if EUPL-1.2, GPL-3.0-or-later and AGPL-3.0-only contributions are added in that order the resolved license changes three times.

Is it possible to immediately license Forgejo under something as AGPL-3.0-only to prevent this?

Should there still not be an agreement on what license Forgejo is distributed under, to prevent changing the license multiple times within a short time period? If I understood correctly, if EUPL-1.2, GPL-3.0-or-later and AGPL-3.0-only contributions are added in that order the resolved license changes three times. Is it possible to immediately license Forgejo under something as AGPL-3.0-only to prevent this?

algernon commented 2024年07月18日 12:58:56 +02:00

Should there still not be an agreement on what the resolved license should be, to prevent changing the license multiple times within a short time period? If I understood correctly, if EUPL-1.2, GPL-3.0-or-later and AGPL-3.0-only contributions are added in that order the resolved license changes three times.

Well... it's complicated! It depends on how and where those EUPL/GPL/AGPL parts are introduced, and what kind of distribution we're looking for.

For example, if we have the current MIT base, accept EUPL tests, then the combined license of the source will be EUPL, but the combined license of the compiled forgejo binary will remain MIT, because it does not include the tests.

If we have the current MIT base, accept EUPL tests, and AGPL code in the frontend, then the source will be AGPL, the compiled binary (without bindata) will remain MIT, the frontend will be AGPL. But if we compile the binary with bindata, then the frontend is embedded in it, and will have to be AGPL.

FWIW, the binaries we currently distribute are non compliant, because we build with bindata, and our frontend dependencies include a whole lot of licenses that prevent publishing the combined work under MIT. They can be combined with MIT, but the combined work cannot be MIT.

Since the JS dependencies already include copylefted deps, including licenses such as MPL-2.0, LGPL-3.0-only, building a forgejo binary with bindata, or using the forgejo frontend is already using copyleft code, and should be considered to be under a copyleft license. Which one? Well. That's hard to tell!

That's the hard part of this: we can't easily tell the license of the resulting work. It depends on which parts are used to make it. So the best we can do, is document the licensed used within the codebase, and in our dependencies, and defer the license compliance check to those who end up using it. Because due to bindata embedding a whole lot of differently licensed dependencies, we kinda already do that.

> Should there still not be an agreement on what the resolved license should be, to prevent changing the license multiple times within a short time period? If I understood correctly, if EUPL-1.2, GPL-3.0-or-later and AGPL-3.0-only contributions are added in that order the resolved license changes three times. Well... it's complicated! It depends on how and where those EUPL/GPL/AGPL parts are introduced, and what kind of distribution we're looking for. For example, if we have the current MIT base, accept EUPL tests, then the combined license of the *source* will be EUPL, but the combined license of the compiled forgejo binary will remain MIT, because it does not include the tests. If we have the current MIT base, accept EUPL tests, and AGPL code in the frontend, then the source will be AGPL, the compiled binary (without bindata) will remain MIT, the frontend will be AGPL. But if we compile the binary with `bindata`, then the frontend is embedded in it, and will have to be AGPL. FWIW, the binaries we currently distribute are **non compliant**, because we build with `bindata`, and our frontend dependencies include a whole lot of licenses that prevent publishing the combined work under MIT. They *can* be combined with MIT, but the combined work cannot be MIT. Since the JS dependencies already include copylefted deps, including licenses such as MPL-2.0, LGPL-3.0-only, building a forgejo binary with `bindata`, or using the forgejo frontend is already using copyleft code, and should be considered to be under a copyleft license. Which one? Well. That's hard to tell! That's the hard part of this: we can't easily tell the license of the resulting work. It depends on which parts are used to make it. So the best we can do, is document the licensed used within the codebase, and in our dependencies, and defer the license compliance check to those who end up using it. Because due to `bindata` embedding a whole lot of differently licensed dependencies, we kinda already do that.

bramh commented 2024年07月18日 14:54:54 +02:00

FWIW, the binaries we currently distribute are non compliant, because we build with bindata, and our frontend dependencies include a whole lot of licenses that prevent publishing the combined work under MIT. They can be combined with MIT, but the combined work cannot be MIT.

A quick license check of the frontend results in the following (output cleaned up a bit by hand in case of dual licensing and unrecognized licenses):

$ license-checker | grep -o "licenses: .*" | cut -c 10-| sort | uniq -c | sort -rn`
 777 MIT
 98 ISC
 53 Apache-2.0
 28 BSD-2-Clause
 25 BSD-3-Clause
 5 CC0-1.0
 4 Unlicense
 4 0BSD
 3 MIT-0
 3 BlueOak-1.0.0
 1 Python-2.0
 1 MPL-2.0
 1 LGPL-3.0-only
 1 EPL-2.0
 1 AGPL-3.0-or-later
 1 CC-BY-4.0
 1 CC-BY-3.0
 1 "No Charge" GreenSock License 

The following of which are compatible with GPLv3 as per gnu.org: MIT (X11License), ISC, Apache-2.0, BSD-2-Clause (FreeBSD), BSD-3-Clause (ModifiedBSD), CC0-1.0, Unlicense, Python-2.0, MPL-2.0, LGPL-3.0-only, AGPL-3.0-or-later

The following are not mentioned but are also compatible: 0BSD (BSD-2-Clause w/o copyright notice), MIT-0 (MIT w/o attribution), BlueOak (source)

The following licenses are not compatible: EPL-2.0 (source), "No Charge" GreenSock License (source)

Noteworthy is the '"No Charge" GreenSock License', a non-free license(!) that puts a restriction on charging end users. This license is pulled in through vue-bar-graph > GSAP. EPL-2.0 is pulled in by mermaid > elkjs.

---

This is the part where I'm way out of my depth, but to me it looks like the binaries should be distributed under AGPL-3.0-or-later if the non GPLv3-compliant dependencies were to be removed.

> FWIW, the binaries we currently distribute are non compliant, because we build with bindata, and our frontend dependencies include a whole lot of licenses that prevent publishing the combined work under MIT. They can be combined with MIT, but the combined work cannot be MIT. A quick license check of the frontend results in the following (output cleaned up a bit by hand in case of dual licensing and unrecognized licenses): ``` $ license-checker | grep -o "licenses: .*" | cut -c 10-| sort | uniq -c | sort -rn` 777 MIT 98 ISC 53 Apache-2.0 28 BSD-2-Clause 25 BSD-3-Clause 5 CC0-1.0 4 Unlicense 4 0BSD 3 MIT-0 3 BlueOak-1.0.0 1 Python-2.0 1 MPL-2.0 1 LGPL-3.0-only 1 EPL-2.0 1 AGPL-3.0-or-later 1 CC-BY-4.0 1 CC-BY-3.0 1 "No Charge" GreenSock License ``` The following of which are compatible with GPLv3 as per [gnu.org](https://www.gnu.org/licenses/license-list.html): MIT (X11License), ISC, Apache-2.0, BSD-2-Clause (FreeBSD), BSD-3-Clause (ModifiedBSD), CC0-1.0, Unlicense, Python-2.0, MPL-2.0, LGPL-3.0-only, AGPL-3.0-or-later The following are not mentioned but are also compatible: 0BSD (BSD-2-Clause w/o copyright notice), MIT-0 (MIT w/o attribution), BlueOak ([source](https://blueoakcouncil.org/license-faq)) The following licenses are not compatible: EPL-2.0 ([source](https://www.gnu.org/licenses/license-list.html#EPL2)), "No Charge" GreenSock License ([source](https://gsap.com/community/standard-license/)) Noteworthy is the '"No Charge" GreenSock License', a non-free license(!) that puts a restriction on charging end users. This license is pulled in through [vue-bar-graph](https://github.com/lafriks/vue-bar-graph) > [GSAP](https://github.com/greensock/GSAP). EPL-2.0 is pulled in by [mermaid](https://github.com/mermaid-js/mermaid) > [elkjs](https://github.com/kieler/elkjs). --- This is the part where I'm way out of my depth, but to me it looks like the binaries should be distributed under AGPL-3.0-or-later if the non GPLv3-compliant dependencies were to be removed.

Beowulf commented 2024年07月18日 15:07:52 +02:00

vue-bar-graph is only used for this graph: https://codeberg.org/forgejo/forgejo/activity . I think it is no big thing to replace it (or just remove GSAP from it) - GSAP seems to be used for the animation 🤔

vue-bar-graph is only used for this graph: https://codeberg.org/forgejo/forgejo/activity . I think it is no big thing to replace it (or just remove GSAP from it) - GSAP seems to be used for the animation 🤔

Ghost commented 2024年07月18日 15:37:38 +02:00

Can this topic be renamed: "Finding a new agreement on copyleft licensing"?

Can this topic be renamed: "Finding a new agreement on copyleft licensing"?

Ghost commented 2024年07月18日 15:39:53 +02:00

If I send a pull request today with code under GPLv3-or-later (including updates to LICENSES etc.), it will be merged or is there a problem with that?

If I send a pull request today with code under GPLv3-or-later (including updates to LICENSES etc.), it will be merged or is there a problem with that?

Gusted commented 2024年07月18日 15:55:13 +02:00

If I send a pull request today with code under GPLv3-or-later (including updates to LICENSES etc.), it will be merged or is there a problem with that?

It wouldn't be merged until we all can agree on a clarification of the agreement (under which such license would be allowed), GPLv3 itself is also a problem, unless it's for tests you really should use AGPLv3 because of the network clause it contains.

> If I send a pull request today with code under GPLv3-or-later (including updates to LICENSES etc.), it will be merged or is there a problem with that? It wouldn't be merged until we all can agree on a clarification of the agreement (under which such license would be allowed), GPLv3 itself is also a problem, unless it's for tests you really should use AGPLv3 because of the network clause it contains.

n0toose commented 2024年07月18日 16:09:27 +02:00

license headers of Forgejo that advertise it is MIT as a whole must be changed

Sidenote: I don't think this is necessary, the individual files can be copied under the terms of the MIT license but the entire composite work may not.

Second sidenote: Have we considered https://reuse.software? I'd be interested in pouring in some effort in that over the next few months.

> license headers of Forgejo that advertise it is MIT as a whole must be changed Sidenote: I don't think this is necessary, the individual files can be copied under the terms of the MIT license but the entire composite work may not. Second sidenote: Have we considered `https://reuse.software`? I'd be interested in pouring in some effort in that over the next few months.

bramh commented 2024年07月18日 16:10:51 +02:00

license headers of Forgejo that advertise it is MIT as a whole must be changed

Sidenote: I don't think this is necessary, the individual files can be copied under the terms of the MIT license but the entire composite work may not.

See #192 (comment) for clarification

> > license headers of Forgejo that advertise it is MIT as a whole must be changed > > Sidenote: I don't think this is necessary, the individual files can be copied under the terms of the MIT license but the entire composite work may not. See https://codeberg.org/forgejo/discussions/issues/192#issuecomment-2098196 for clarification

n0toose commented 2024年07月18日 16:12:36 +02:00

Ahhhhh, thank you. @bramh

It's becoming a bit hard to keep track or not sidetrack the conversation.

Ahhhhh, thank you. @bramh It's becoming a bit hard to keep track or *not* sidetrack the conversation.

Gusted commented 2024年07月18日 16:13:25 +02:00

FYI - I'm working on a clarification draft of the current agreement that should resolve this issue.

FYI - I'm working on a clarification draft of the current agreement that should resolve this issue.

bramh commented 2024年07月18日 16:24:19 +02:00

vue-bar-graph is only used for this graph: https://codeberg.org/forgejo/forgejo/activity . I think it is no big thing to replace it (or just remove GSAP from it) - GSAP seems to be used for the animation 🤔

I have created an issue for this (forgejo/forgejo#4569) as I do not have the frontend experience to do this myself

> vue-bar-graph is only used for this graph: https://codeberg.org/forgejo/forgejo/activity . I think it is no big thing to replace it (or just remove GSAP from it) - GSAP seems to be used for the animation 🤔 I have created an issue for this (https://codeberg.org/forgejo/forgejo/issues/4569) as I do not have the frontend experience to do this myself

algernon commented 2024年07月18日 21:22:54 +02:00

fwiw, I pinged a few acquaintance with floss licensing experience for input. I hope that'll help clarify things, and help us decide how to proceed. Will share what I learn as soon as I can.

fwiw, I pinged a few acquaintance with floss licensing experience for input. I hope that'll help clarify things, and help us decide how to proceed. Will share what I learn as soon as I can.

Ghost commented 2024年07月25日 11:57:46 +02:00

I hold the following opinions on this:

1. Or later clause is a bad idea as it allows for self updating license by a major version with no evaluation or intervention. I don't think anyone likes ToS and EULAs which can be changed at any given time to be completely different and I hold the same view here.
2. EUPLv1.2 is not directly compatible with or later and as such I don't think it should be allowed in GPLv3+ codebase, especially given my point 3.
3. I fundamentally disagree with how GNU project handles the compatibility between only and or later.
   Here's my take on GPLv3 based compatibility:

   \	only	or-later
   only	only	only
   or-later	only	or-later

I hold the opinion that a more restrictive license here should be the one that the entire codebase should resolve to since GPLv3+ is compatible with GPLv3 only (due to the fact that is must be), but the opposite might not always be true (take for example a case where GPLv3 only code combined with GPLv3+ one and user picks the license as GPLv4).

I hold the following opinions on this: 1. Or later clause is a bad idea as it allows for self updating license by a major version with no evaluation or intervention. I don't think anyone likes ToS and EULAs which can be changed at any given time to be completely different and I hold the same view here. 2. EUPLv1.2 is not directly compatible with `or later` and as such I don't think it should be allowed in GPLv3+ codebase, especially given my point 3. 3. I fundamentally disagree with how GNU project handles the compatibility between `only` and `or later`. Here's my take on GPLv3 based compatibility: | \ | only | or-later | |---|---|---| | only | only | only | | or-later | only | or-later | I hold the opinion that a more restrictive license here should be the one that the entire codebase should resolve to since `GPLv3+` is compatible with `GPLv3 only` (due to the fact that is must be), but the opposite might not always be true (take for example a case where GPLv3 only code combined with GPLv3+ one and user picks the license as GPLv4).

bramh commented 2024年07月25日 12:46:20 +02:00

@earl-warren moving this here to not derail #201 futher.

there has been a standing agreement that allows for GPLv3+ to enter the Forgejo codebase for over a year. It is unambiguous and clear in that regard.

If someone wants to use a license and has reason to believe it is not compatible with GPLv3+, it certainly is a discussion worth having and #192 is a good forum for that. But it is not a compelling reason to block GPLv3+ code from entering Forgejo and go back on an existing agreement. Specially given how many weeks it took to reach this agreement.

I sense not everyone is on the same wavelength about this. My interpretation of the agreement (forgejo/governance#24) is that any GPL-3.0-or-later compatible contributions are allowed. Some licenses that are compatible with GPL-3.0-or-later are (non-exhaustive list):

• GPL-3.0-only (gnu.org (compatibility matrix))
• AGPL-3.0-only/AGPL-3.0-or-later (gnu.org (AGPL))
• EUPL-1.2 (europa.eu (compatibility clause))

However, by combining GPL-3.0-or-later licensed code with any of the above licenses, the resolved license of the combined work will not be GPL-3.0-or-later. The agreement says nothing about the resolved license, so ending up with GPL-3.0-only or AGPL-3.0-only as the resolved license is not against the agreement.

So while I agree that the decision to allow GPL-3.0-or-later compatible contributions is unambiguous, I think the agreement failed to consider the 'consequences' of combining different GPL-3.0-or-later compatible licenses. This is, at least imo, the cause of all of the confusion.

I am of the opinion that licensing the combined work as AGPL-3.0-only allows for a good selection of licenses (MIT, EUPL, GPLv3(+), AGPLv3(+) are amongst them). Doing this proactively means the license only changes once, instead of multiple times within a short period. Changing the license to GPLv3+ right now is merely symbolic, and as soon as any EUPL/AGPL/GPLv3-only code is merged (which again, I believe are not violating the agreement) it will have to be changed again.

@earl-warren moving this here to not derail #201 futher. > there has been a standing agreement that allows for GPLv3+ to enter the Forgejo codebase for over a year. It is unambiguous and clear in that regard. > > If someone wants to use a license and has reason to believe it is not compatible with GPLv3+, it certainly is a discussion worth having and #192 is a good forum for that. But it is not a compelling reason to block GPLv3+ code from entering Forgejo and go back on an existing agreement. Specially given how many weeks it took to reach this agreement. I sense not everyone is on the same wavelength about this. My interpretation of the agreement (https://codeberg.org/forgejo/governance/pulls/24) is that any `GPL-3.0-or-later` compatible contributions are allowed. Some licenses that are compatible with `GPL-3.0-or-later` are (non-exhaustive list): * `GPL-3.0-only` ([gnu.org (compatibility matrix)](https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility)) * `AGPL-3.0-only/AGPL-3.0-or-later` ([gnu.org (AGPL)](https://www.gnu.org/licenses/license-list.html#AGPLv3.0)) * `EUPL-1.2` ([europa.eu (compatibility clause)](https://joinup.ec.europa.eu/sites/default/files/custom-page/attachment/2020-03/EUPL-1.2%20EN.txt)) However, by combining `GPL-3.0-or-later` licensed code with any of the above licenses, the resolved license of the combined work will not be `GPL-3.0-or-later`. The agreement says nothing about the resolved license, so ending up with `GPL-3.0-only` or `AGPL-3.0-only` as the resolved license is not against the agreement. So while I agree that the decision to allow `GPL-3.0-or-later` compatible contributions is unambiguous, I think the agreement failed to consider the 'consequences' of combining different `GPL-3.0-or-later` compatible licenses. This is, at least imo, the cause of all of the confusion. I am of the opinion that licensing the combined work as `AGPL-3.0-only` allows for a good selection of licenses (MIT, EUPL, GPLv3(+), AGPLv3(+) are amongst them). Doing this proactively means the license only changes once, instead of multiple times within a short period. Changing the license to GPLv3+ right now is merely symbolic, and as soon as any EUPL/AGPL/GPLv3-only code is merged (which again, I believe are not violating the agreement) it will have to be changed again.

mahlzahn commented 2024年07月25日 13:07:34 +02:00

I was sceptical about using the AGPL-3.0 because GPL-3.0 is widely known and used and AGPL-3.0 not. But after reading The fundamentals of the AGPLv3 (FSF) and Why the Affero GPL (FSF) I think that AGPL-3.0 is a better fit than GPL-3.0 for Forgejo as it is indeed served on web servers. And I’d like to enforce entities using and modifying Forgejo to share their code. Else, they could implement nice features or simply bug fixes on top of Forgejo and run a web-server with this without giving back these code changes to the community.

I was sceptical about using the `AGPL-3.0` because `GPL-3.0` is widely known and used and `AGPL-3.0` not. But after reading [The fundamentals of the AGPLv3 (FSF)](https://www.fsf.org/bulletin/2021/fall/the-fundamentals-of-the-agplv3) and [Why the Affero GPL (FSF)](https://www.gnu.org/licenses/why-affero-gpl.en.html) I think that `AGPL-3.0` is a better fit than `GPL-3.0` for Forgejo as it is indeed served on web servers. And I’d like to enforce entities using and modifying Forgejo to share their code. Else, they could implement nice features or simply bug fixes on top of Forgejo and run a web-server with this without giving back these code changes to the community.

fnetX commented 2024年07月25日 22:19:03 +02:00

Let's add one more batch of opinions to the pool.

First of all, I agree that the past licensing agreement needs to be improved. I appreciate that we have this, so we don't have to discuss the "if" in depth. But it is clear that we didn't consider all ins and outs and some details back then, and it was made by different people. I think we should decide the way forward with the people that are here now, today, and that want to make use of that agreement to actually land copyleft code in Forgejo.

I see that there are different pros and cons about multiple license choices. And I think we should take the time now to make an informed and good decision. I know that there are currently some people watching Forgejo closely, being concerned about our licensing debate. They are waiting for clarity, and I don't think we should postpone the discussion. But we should make an informed decision, so that we can give them some clear path going forward.

That said, I believe that changing the license twice in short succession is among the worst things. It can happen for reasons in the future. But if we know that it is likely to happen, because we are taking a shortcut now, this is a careless approach that our users don't deserve.

Also, note that the outcome does not only affect our users and potential users. In the first place, it affects Forgejo developers today. Reading some of the discussions around, I fear that this is disturbing the productive and healthy environment that we created due to heated discussions and the rush to make this a quick thing. Let's take some time to navigate through this carefully.

Let's add one more batch of opinions to the pool. First of all, I agree that **the past licensing agreement needs to be improved**. I appreciate that we have this, so we don't have to discuss the "if" in depth. But it is clear that we didn't consider all ins and outs and some details back then, and it was made by different people. I think we should **decide the way forward with the people that are here now, today**, and that want to make use of that agreement to actually land copyleft code in Forgejo. I see that there are different pros and cons about multiple license choices. And I think we should **take the time now to make an informed and good decision**. I know that there are currently some people watching Forgejo closely, being concerned about our licensing debate. They are waiting for clarity, and I don't think we should postpone the discussion. But we should make an informed decision, so that we can give them some clear path going forward. That said, I believe that **changing the license twice in short succession** is among the worst things. It can happen for reasons in the future. But if we know that it is likely to happen, because we are taking a shortcut now, this is a careless approach that our users don't deserve. Also, note that the outcome does not only affect our users and potential users. In the first place, **it affects Forgejo developers today**. Reading some of the discussions around, I fear that this is disturbing the productive and healthy environment that we created due to heated discussions and the rush to make this a quick thing. Let's take some time to navigate through this carefully.

fnetX commented 2024年07月25日 22:27:27 +02:00

Or later clause is a bad idea as it allows for self updating license by a major version with no evaluation or intervention

@thefox I disagree to your evaluation here. First of all, updating the terms is restricted to functional similarities and not for arbitrary changes. Secondly, I believe it is okay do delegate a certain level of trust to the makers of a license. And finally, jurisdiction can change, and licenses need to adapt. Unfortunately, a -only license variant means you are basically stuck with these terms forever, no matter if they make sense or not. In the worst case, this might mean that a license just stops doing what it was supposed to do, and you have no convenient option to convert it.

TOS changes etc can make a lot of sense, and from my experience at Codeberg I can say: They are necessary from time to time. Of course, it would be better if you have a chance to to review the changes first, similar to how you can make educated changes whether to upgrade a software or not. However, if you now have the choice to never receive updates again, I'd pick the update route.

> Or later clause is a bad idea as it allows for self updating license by a major version with no evaluation or intervention @thefox I disagree to your evaluation here. First of all, updating the terms is restricted to functional similarities and not for arbitrary changes. Secondly, I believe it is okay do delegate a certain level of trust to the makers of a license. And finally, **jurisdiction can change, and licenses need to adapt**. Unfortunately, a -only license variant means you are basically stuck with these terms forever, no matter if they make sense or not. In the worst case, this might mean that a license just stops doing what it was supposed to do, and you have no convenient option to convert it. TOS changes etc can make a lot of sense, and from my experience at Codeberg I can say: They are necessary from time to time. Of course, it would be better if you have a chance to to review the changes first, similar to how you can make educated changes whether to upgrade a software or not. However, if you now have the choice to never receive updates again, I'd pick the update route.

Ghost commented 2024年07月25日 23:27:38 +02:00

I don't think we'll find a common ground here - mainly because we differ in the level of trust in the makers of the license. The GNU project can claim that the hypothetical next license will be as similar in scope and nature to the current one - but that's the extend of it. Those are only claims and promises, which I can trust or not, but I can't act on them in the event that they will be broken. Because ultimately that is what they are - promises.

And finally, jurisdiction can change, and licenses need to adapt. Unfortunately, a -only license variant means you are basically stuck with these terms forever, no matter if they make sense or not.

Licenses do need to have a way to adapt and on that I agree. But seeing a new defacto major version of the license and blindly accepting it before even reading it is... bizarre to me.

In the worst case, this might mean that a license just stops doing what it was supposed to do, and you have no convenient option to convert it.

Or the newer version of the license is a complete negation of the previous one.

ToS changes aren't inherently bad - forceful acceptance of them is. I might've oversimplified a bit.

Of course, it would be better if you have a chance to to review the changes first, similar to how you can make educated changes whether to upgrade a software or not. However, if you now have the choice to never receive updates again, I'd pick the update route.

Consider my stance on the license update akin to unattended update from VeryImportantProject v1.0.0 to VeryImportantProject v2.0.0. It might be fine... or you might get 50 angry emails per second about downtime. Or the Hashicorp situation with the relicense.

If I have a choice of freezing the license to a major version in semver terms or have an at least v3 requirement, I'd pick frozen option.

---

Regardless of my stance on this topic, I'm not opposed to INCLUDING GPLv3+ contributions.
I'm against having a overall license as GPLv3+ as it is closing a lot of doors for contributions.

I don't think we'll find a common ground here - mainly because we differ in the level of trust in the makers of the license. The GNU project can claim that the hypothetical next license will be as similar in scope and nature to the current one - but that's the extend of it. Those are only claims and promises, which I can trust or not, but I can't act on them in the event that they will be broken. Because ultimately that is what they are - promises. > And finally, jurisdiction can change, and licenses need to adapt. Unfortunately, a -only license variant means you are basically stuck with these terms forever, no matter if they make sense or not. Licenses do need to have a way to adapt and on that I agree. But seeing a new defacto major version of the license and blindly accepting it before even reading it is... bizarre to me. > In the worst case, this might mean that a license just stops doing what it was supposed to do, and you have no convenient option to convert it. Or the newer version of the license is a complete negation of the previous one. ToS changes aren't inherently bad - forceful acceptance of them is. I might've oversimplified a bit. > Of course, it would be better if you have a chance to to review the changes first, similar to how you can make educated changes whether to upgrade a software or not. However, if you now have the choice to never receive updates again, I'd pick the update route. Consider my stance on the license update akin to unattended update from VeryImportantProject v1.0.0 to VeryImportantProject v2.0.0. It might be fine... or you might get 50 angry emails per second about downtime. Or the Hashicorp situation with the relicense. If I have a choice of freezing the license to a major version in semver terms or have an `at least v3` requirement, I'd pick frozen option. --- Regardless of my stance on this topic, I'm not opposed to INCLUDING GPLv3+ contributions. I'm against having a overall license as GPLv3+ as it is closing a lot of doors for contributions.

earl-warren commented 2024年07月25日 23:36:47 +02:00

That said, I believe that changing the license twice in short succession is among the worst things.

I agree.

It can happen for reasons in the future.

And it will.

But if we know that it is likely to happen, because we are taking a shortcut now, this is a careless approach that our users don't deserve.

But we don't.

• I think the most likely outcome is AGPLv3+ which is a license upgrade, a path forward, an improvement rather than a license change comparable to switching to an incompatible license.
• If one takes the time read through the months long debates that happened last year and was concluded by the agreement that currently stands as well as the current discussion, a new agreement will take a very long time, if it ever happens. There will be no shortcut.

I am in favor of discussing a revised licensing agreement, absolutely. But the vibe I'm getting which is that the current agreement is null and void, I do not get. What is the point of discussing anything if the outcome cannot be relied on I wonder? I think the Forgejo decision making process is solid and one of the best thing this project has. Let's stick with it and respect the process.

> That said, I believe that changing the license twice in short succession is among the worst things. I agree. > It can happen for reasons in the future. And it will. > But if we know that it is likely to happen, because we are taking a shortcut now, this is a careless approach that our users don't deserve. But we don't. * I think the most likely outcome is AGPLv3+ which is a license upgrade, a path forward, an improvement rather than a license change comparable to switching to an incompatible license. * If one takes the time read through the months long debates that happened last year and was concluded by the agreement that currently stands as well as the current discussion, a new agreement will take a very long time, if it ever happens. There will be no shortcut. I am in favor of discussing a revised licensing agreement, absolutely. But the vibe I'm getting which is that the **current agreement is null and void**, I do not get. What is the point of discussing anything if the outcome cannot be relied on I wonder? I think the Forgejo decision making process is solid and one of the best thing this project has. Let's stick with it and respect the process.

earl-warren commented 2024年07月25日 23:41:35 +02:00

Regardless of my stance on this topic, I'm not opposed to INCLUDING GPLv3+ contributions.
I'm against having a overall license as GPLv3+ as it is closing a lot of doors for contributions.

That's not possible. If there is a GPLv3+ piece of code in Forgejo binary, the Forgejo binary is GPLv3+.

> Regardless of my stance on this topic, I'm not opposed to INCLUDING GPLv3+ contributions. > I'm against having a overall license as GPLv3+ as it is closing a lot of doors for contributions. That's not possible. If there is a GPLv3+ piece of code in Forgejo binary, the Forgejo binary is GPLv3+.

Beowulf commented 2024年07月25日 23:43:01 +02:00

That's not possible. If there is a GPLv3+ piece of code in Forgejo binary, the Forgejo binary is GPLv3+.

If there is a GPLv3+ piece of code in Forgejo, the binary can still be GPLv3 but the other way around is not possible 🤔

> That's not possible. If there is a GPLv3+ piece of code in Forgejo binary, the Forgejo binary is GPLv3+. If there is a GPLv3+ piece of code in Forgejo, the binary can still be GPLv3 but the other way around is not possible 🤔

fnetX commented 2024年07月25日 23:49:00 +02:00

Let's take a step back and appreciate this one thing: So far, everyone is somehow on the copyleft side. There is no strong argument against the merits of copyleft, we don't have people completely blocking the discussion, I haven't seen someone recommend to "just stick to MIT". This is a positive thing, and I think this is thanks to the agreement we already have. It is not void, but not perfect either.

We are now talking about ways to move forward, considering potential negative impact on the development and our users. The issues are:

• the longer the process takes, the longer valuable development is prevented from being merged
• the quick path might make us change the license twice in short succession, and it might annoy users

So we need a balance between the concerns and needs of developers and users, ideally finding a good match. That's the goal. Isn't it?

Let's take a step back and appreciate this one thing: So far, everyone is somehow on the copyleft side. There is no strong argument against the merits of copyleft, we don't have people completely blocking the discussion, I haven't seen someone recommend to "just stick to MIT". This is a positive thing, and I think this is thanks to the agreement we already have. It is not void, but not perfect either. We are now talking about ways to move forward, considering potential negative impact on the development and our users. The issues are: - the longer the process takes, the longer valuable development is prevented from being merged - the quick path might make us change the license twice in short succession, and it might annoy users So we need a balance between the concerns and needs of developers and users, ideally finding a good match. That's the goal. Isn't it?

bramh commented 2024年07月25日 23:49:59 +02:00

I am in favor of discussing a revised licensing agreement, absolutely. But the vibe I'm getting which is that the current agreement is null and void, I do not get. What is the point of discussing anything if the outcome cannot be relied on I wonder? I think the Forgejo decision making process is solid and one of the best thing this project has. Let's stick with it and respect the process.

@earl-warren could you elaborate your POV further? I believe none of us disagree with the current agreement, but it took us a while to fully understand what the agreement meant (and more importantly, what it did not mean).

> I am in favor of discussing a revised licensing agreement, absolutely. But the vibe I'm getting which is that the **current agreement is null and void**, I do not get. What is the point of discussing anything if the outcome cannot be relied on I wonder? I think the Forgejo decision making process is solid and one of the best thing this project has. Let's stick with it and respect the process. @earl-warren could you elaborate your POV further? I believe none of us disagree with the current agreement, but it took us a while to fully understand what the agreement meant (and more importantly, what it did not mean).

Beowulf commented 2024年07月25日 23:54:03 +02:00

But the vibe I'm getting which is that the current agreement is null and void, I do not get. What is the point of discussing anything if the outcome cannot be relied on I wonder? I think the Forgejo decision making process is solid and one of the best thing this project has. Let's stick with it and respect the process.

You can rely on it, the point is only it is very likely that a new agreement will be made and for this reason it would make sense to delay the public communication. (If it is your wish to communicate GPLv3+ now and then possibly communicate something new in a few months, then I would say that would be possible, "we" (me and other people in this discussion) just don't recommend it.)

And doing a new agreement is always possible and must be possible. Otherwise we would no longer be allowed to adapt and improve anything that has already been "defined".

> But the vibe I'm getting which is that the current agreement is null and void, I do not get. What is the point of discussing anything if the outcome cannot be relied on I wonder? I think the Forgejo decision making process is solid and one of the best thing this project has. Let's stick with it and respect the process. You can rely on it, the point is only it is very likely that a new agreement will be made and for this reason it would make sense to delay the public communication. (If it is your wish to communicate GPLv3+ now and then possibly communicate something new in a few months, then I would say that would be possible, "we" (me and other people in this discussion) just don't recommend it.) And doing a new agreement is always possible and must be possible. Otherwise we would no longer be allowed to adapt and improve anything that has already been "defined".

earl-warren commented 2024年07月25日 23:57:20 +02:00

I believe none of us disagree with the current agreement...

I may have missed someone who agrees to act according to the current agreement. All I read is that it must be revised and must not be used because X, Y, Z.

> I believe none of us disagree with the current agreement... I may have missed someone who agrees to act according to the current agreement. All I read is that it must be revised and must not be used because X, Y, Z.

Ghost commented 2024年07月26日 00:05:16 +02:00

Direct quote from gnu gpl matrix footnote

While you may release under GPLv2-or-later both your original work, and/or modified versions of work you received under GPLv2-or-later, the GPLv2-only code that you're using must remain under GPLv2 only. As long as your project depends on that code, you won't be able to upgrade the license of your own code to GPLv3-or-later, and the work as a whole (any combination of both your project and the other code) can only be conveyed under the terms of GPLv2.

This is in context of including GPLv2 only in GPLv2+ application.

As such the inclusion of any GPLv3-only compatible code (such as EUPLv1.2) with GPLv3+ codebase, would resolve the codebase to GPLv3-only.

I'd also would like to retract that I disagree with how gnu handles the -only/-or-later suffixes. I misunderstood the matrix and skipped the footnote to it which does support my point.

---

I second what Beowulf and bramh said before me. I don't think We disagree with the spirit of the agreement. But the practical application showed that GPLv3+ allows for:

• MIT
• GPLv3+

and that's about it..?

Direct quote from [gnu gpl matrix footnote](https://www.gnu.org/licenses/gpl-faq.html#compat-matrix-footnote-2) > While you may release under GPLv2-or-later both your original work, and/or modified versions of work you received under GPLv2-or-later, the GPLv2-only code that you're using must remain under GPLv2 only. As long as your project depends on that code, you won't be able to upgrade the license of your own code to GPLv3-or-later, and the work as a whole (any combination of both your project and the other code) can only be conveyed under the terms of GPLv2. This is in context of including GPLv2 only in GPLv2+ application. As such the inclusion of any GPLv3-only compatible code (such as EUPLv1.2) with GPLv3+ codebase, would resolve the codebase to GPLv3-only. I'd also would like to retract that I disagree with how gnu handles the `-only/-or-later` suffixes. I misunderstood the matrix and skipped the footnote to it which does support my point. --- I second what Beowulf and bramh said before me. I don't think We disagree with the spirit of the agreement. But the practical application showed that GPLv3+ allows for: - MIT - GPLv3+ and that's about it..?

bramh commented 2024年07月26日 00:09:41 +02:00

I may have missed someone who agrees to act according to the current agreement. All I read is that it must be revised and must not be used because X, Y, Z.

I can see where you're coming from, and I'm probably guilty of that as well. I think calling the current agreement null and void is not entirely correct, as it seems we all agree with the goal it is trying to achieve. I promise I'm not being annoying just for the sake of it, I genuinely believe the current agreement is lacking important details, making it not practical and confusing. I think the statement "GPL-3.0-or-later compatible" in itself is already confusing.

My interpretation of the agreement is that any contributions which are compatible with GPL-3.0-or-later are welcome. Under this agreement I believe that we are allowed to contribute EUPL and AGPL licensed code (#192 (comment), #192 (comment)), but I think the current agreement fails to recognize the consequences of this as it can cause the license to potentially change twice or thrice if we do not act accordingly. At the moment there are PRs open that contribute EUPL and AGPL code, so I do think this is a real concern.

The other way to interpret the agreement is to say that Forgejo should be licensed under GPL-3.0-later, and only contributions that comply with that license are allowed. I do not think this is what the agreement tries to say, and that seems to be the consensus in this discussion as far as I can tell.

Assuming the first interpretation: If the license is resolved based on contributions, contributing GPLv3+, EUPL and AGPL code in that order would induce 3 license changes for the source code. This is not optimal.

Personally, I would like to see clarification to this agreement for the following points:

• The (initial) license of the distributed binary, so that it does not have to be changed every N weeks or months.
• A concrete list of allowed licenses. GPL-3.0-or-later compatible allows for many funny licenses to be used. At the bare minimum I would like to see licenses that at least have a SPDX identifier (this isn't the case for the frontend dependencies, so I'd argue this is a real concern), ideally the list would be narrowed down to 5-10 licenses for the sake of simplicity. This is not blocking for me, but it should be discussed at one point.

---

A late addition from me:

I think the most likely outcome is AGPLv3+ which is a license upgrade, a path forward, an improvement rather than a license change comparable to switching to an incompatible license.

From my POV it certainly seems like an upgrade, but to others AGPLv3 is very scary. It is a whole different beast compared to GPLv3, and has consequences for people hosting Forgejo instances. imo it isn't too different from switching to an incompatible license.

> I may have missed someone who agrees to act according to the current agreement. All I read is that it must be revised and must not be used because X, Y, Z. I can see where you're coming from, and I'm probably guilty of that as well. I think calling the current agreement *null and void* is not entirely correct, as it seems we all agree with the goal it is trying to achieve. I promise I'm not being annoying just for the sake of it, I genuinely believe the current agreement is lacking important details, making it not practical and confusing. I think the statement "GPL-3.0-or-later compatible" in itself is already confusing. My interpretation of the agreement is that any contributions which are compatible with GPL-3.0-or-later are welcome. Under this agreement I believe that we are allowed to contribute EUPL and AGPL licensed code (https://codeberg.org/forgejo/discussions/issues/192#issuecomment-2099254, https://codeberg.org/forgejo/discussions/issues/192#issuecomment-2112111), but I think the current agreement fails to recognize the consequences of this as it can cause the license to potentially change twice or thrice if we do not act accordingly. At the moment there are PRs open that contribute EUPL and AGPL code, so I do think this is a real concern. The other way to interpret the agreement is to say that Forgejo should be licensed under GPL-3.0-later, and only contributions that comply with that license are allowed. I do not think this is what the agreement tries to say, and that seems to be the consensus in this discussion as far as I can tell. Assuming the first interpretation: If the license is resolved based on contributions, contributing GPLv3+, EUPL and AGPL code in that order would induce 3 license changes for the source code. This is not optimal. Personally, I would like to see clarification to this agreement for the following points: - The (initial) license of the distributed binary, so that it does not have to be changed every N weeks or months. - A concrete list of allowed licenses. GPL-3.0-or-later compatible allows for many funny licenses to be used. At the bare minimum I would like to see licenses that at least have a SPDX identifier (this isn't the case for the frontend dependencies, so I'd argue this is a real concern), ideally the list would be narrowed down to 5-10 licenses for the sake of simplicity. This is not blocking for me, but it should be discussed at one point. --- A late addition from me: > I think the most likely outcome is AGPLv3+ which is a license upgrade, a path forward, an improvement rather than a license change comparable to switching to an incompatible license. From my POV it certainly seems like an upgrade, but to others AGPLv3 is very scary. It is a whole different beast compared to GPLv3, and has consequences for people hosting Forgejo instances. imo it isn't too different from switching to an incompatible license.

mahlzahn commented 2024年07月26日 01:31:20 +02:00

[...] to others AGPLv3 is very scary.

Is this true?

It is a whole different beast compared to GPLv3, and has consequences for people hosting Forgejo instances.

As long as the forgejo binary is not modified a simple link to the source code of the forgejo repo should be sufficient. That should be already the default for anyone hosting an instance. Only if modifications are done (with compilation of the binary?) the source code of the modified version must be made downloadable. But that's what a copyleft license is done for. The concerning part of the AGPLv3 starts prominently with "if you modify the Program".

> [...] to others AGPLv3 is very scary. Is this true? > It is a whole different beast compared to GPLv3, and has consequences for people hosting Forgejo instances. As long as the forgejo binary is not modified a simple link to the source code of the forgejo repo should be sufficient. That should be already the default for anyone hosting an instance. Only if modifications are done (with compilation of the binary?) the source code of the modified version must be made downloadable. But that's what a copyleft license is done for. The concerning part of the AGPLv3 starts prominently with "if you modify the Program".

bramh commented 2024年07月26日 01:54:49 +02:00

Is this true?

The famous example is Google banning AGPL dependencies, and making it difficult to use AGPL software:

Do not attempt to check AGPL-licensed code into google3 or use it in a Google product in any way.

Do not install AGPL-licensed programs on your workstation, Google-issued laptop, or Google-issued phone without explicit authorization from the Open Source Programs Office. (source)

They are not the only company with these restrictions in place.

Only if modifications are done (with compilation of the binary?) the source code of the modified version must be made downloadable. But that's what a copyleft license is done for. The concerning part of the AGPLv3 starts prominently with "if you modify the Program".

In broad lines this is true, but there is more nuance to it. I will preface this by saying that IANAL.

Sources of modified works should indeed be accessible to all users of the instance, either public or on request. imo this is good, not everyone agrees.

Derivative works are also affected. These are external works that heavily depend on Forgejo, where Forgejo is not linked (e.g. instead the web api is used) and cannot be trivially replaced by a different service. There is some room for interpretation here. Derivative works will also have to be licensed under AGPL. I think release-notes-assistant might be a good example of this, but again IANAL and the definition of a derivative work is not very concrete.

My concern is not that publishing sources is difficult, but it is an additional step some users have to do and in some cases may not agree to. I think that because of this going from GPL to AGPL is a "breaking" change

> Is this true? The famous example is Google banning AGPL dependencies, and making it difficult to use AGPL software: > Do not attempt to check AGPL-licensed code into google3 or use it in a Google product in any way. > > Do not install AGPL-licensed programs on your workstation, Google-issued laptop, or Google-issued phone without explicit authorization from the Open Source Programs Office. ([source](https://opensource.google/documentation/reference/using/agpl-policy)) They are not the only company with these restrictions in place. > Only if modifications are done (with compilation of the binary?) the source code of the modified version must be made downloadable. But that's what a copyleft license is done for. The concerning part of the AGPLv3 starts prominently with "if you modify the Program". In broad lines this is true, but there is more nuance to it. I will preface this by saying that IANAL. Sources of modified works should indeed be accessible to all users of the instance, either public or on request. imo this is good, not everyone agrees. Derivative works are also affected. These are external works that heavily depend on Forgejo, where Forgejo is not linked (e.g. instead the web api is used) and cannot be trivially replaced by a different service. There is some room for interpretation here. Derivative works will also have to be licensed under AGPL. I think [release-notes-assistant](https://code.forgejo.org/forgejo/release-notes-assistant) might be a good example of this, but again IANAL and the definition of a derivative work is not very concrete. My concern is not that publishing sources is difficult, but it is an additional step some users have to do and in some cases may not agree to. I think that because of this going from GPL to AGPL is a "breaking" change

fnetX commented 2024年07月26日 02:11:26 +02:00

@mahlzahn your comment #192 (comment) touches upon what I mean in #201 (comment)

Copyleft might sound easy and "cool" if you understand your rights and implications. But it needs education, and I think we should do our best to explain. The MIT license is super easy to read and understand. Everyone can do this easily. The same is not true for most copyleft licenses. That alone is a big factor.

Finally, there are also cases where AGPL does have consequences, basically for everyone who needs to patch Forgejo (and many do!). You want to hot-patch your instance? Add some easter-egg that is not known to users? Think twice how you do this in a fully compliant way.

AGPL sounds especially dangerous for enterprises, because it forbids certain business practices. It is of course appealing to prevent companies from taking your product, spicing it up, and selling a modified enterprice edition as a SaaSS. However, you need to consider the impact loosing them as customers has. And see if you even loose companies that would be "cool and transparent" in general, but would still like to have this option B in case their fancy free-software-first business model doesn't work out as expected.

@mahlzahn your comment https://codeberg.org/forgejo/discussions/issues/192#issuecomment-2113872 touches upon what I mean in https://codeberg.org/forgejo/discussions/issues/201#issuecomment-2113218 Copyleft might sound easy and "cool" if you understand your rights and implications. But it needs education, and I think we should do our best to explain. The MIT license is super easy to read and understand. Everyone can do this easily. The same is not true for most copyleft licenses. That alone is a big factor. Finally, there are also cases where AGPL does have consequences, basically for everyone who needs to patch Forgejo (and many do!). You want to hot-patch your instance? Add some easter-egg that is not known to users? Think twice how you do this in a fully compliant way. AGPL sounds especially dangerous for enterprises, because it forbids certain business practices. It is of course appealing to prevent companies from taking your product, spicing it up, and selling a modified enterprice edition as a SaaSS. However, you need to consider the impact loosing them as customers has. And see if you even loose companies that would be "cool and transparent" in general, but would still like to have this option B in case their fancy free-software-first business model doesn't work out as expected.

Ghost commented 2024年07月28日 15:29:37 +02:00

To maybe move this forward a bit so we don't get stuck here:
@fnetX during User Research and talks with administrators or people looking at forgejo to deploy it (as SaaS or not), would they consider it a major issue if forgejo would be AGPL/EUPL? I realize it wasn't a target of UR but you probably would have the most insight into this.

Copyleft might sound easy and "cool" if you understand your rights and implications. But it needs education, and I think we should do our best to explain. The MIT license is super easy to read and understand. Everyone can do this easily. The same is not true for most copyleft licenses. That alone is a big factor.

I think this can be handled on docs/website - many laws are not enforced to a written letter but judged if they violate the spirit of the regulation (happened with GDPR I think). So as long as we explain that's the idea behind the license choice - to protect forgejo from being taken over and used in a SaaS environment with no benefit for the main codebase (IMO) it will be quite clear what we would even try to enforce our copyright on and what wouldn't be a part of it.

---

In any case as a starting point I'd like to propose a change to the current agreement which drops or later suffix.

Personally, I would like to see clarification to this agreement for the following points:

• The (initial) license of the distributed binary, so that it does not have to be changed every N weeks or months.
• A concrete list of allowed licenses. GPL-3.0-or-later compatible allows for many funny licenses to be used. At the bare minimum I would like to see licenses that at least have a SPDX identifier (this isn't the case for the frontend dependencies, so I'd argue this is a real concern), ideally the list would be narrowed down to 5-10 licenses for the sake of simplicity. This is not blocking for me, but it should be discussed at one point.

Binary to be distributed under GPL-3.0-only.

Accepted licenses: GPL-3.0-only, GPL-3.0-or-later, GPL2.0-or later, MIT, EUPL-1.2, Apache-2.0 (apache I'm basing on gnu license list)
Not accepted licenses: AGPL-3.0-or-later,AGPL-3.0-only - due to the fact the binary license would have to be changed.

Motivation behind this:

• It unlocks the EUPL-1.2 license and contributions basing or wanting to add it.
• It kind of preserves the existing agreement (dropping only the +)

Main and only drawback is ban on AGPL3.0 IMO.

to make a non-binding vote for the option: 🚀

---

Alternative 2:

Binary to be distributed under AGPL-3.0-only.

Accepted licenses: AGPL-3.0-or-later,AGPL-3.0-only, GPL-3.0-only, GPL-3.0-or-later, GPL2.0-or later, MIT, EUPL-1.2, Apache-2.0 (apache I'm basing on gnu license list).

Motivation behind this:

• Same as option 1 + AGPL inclusion which offers protection from reusing forgejo in SaaS without making the source available.

vote option: 👀

---

Alternative 3:

Binary to be distributed under EUPL-1.2.

Accepted licenses: MIT, EUPL-1.2
Others I'm not sure of so I'm not including them - I'm pretty sure that GPL cannot be converted into EUPL though.

Motivation behind this:

• Same as option 2 + AGPL level of protection + forced jurisdiction.

vote option: ❤️

---

Voting is non binding in any way

It's just there as a support probe. Nothing more.

To maybe move this forward a bit so we don't get stuck here: @fnetX during User Research and talks with administrators or people looking at forgejo to deploy it (as SaaS or not), would they consider it a major issue if forgejo would be AGPL/EUPL? I realize it wasn't a target of UR but you probably would have the most insight into this. > Copyleft might sound easy and "cool" if you understand your rights and implications. But it needs education, and I think we should do our best to explain. The MIT license is super easy to read and understand. Everyone can do this easily. The same is not true for most copyleft licenses. That alone is a big factor. I think this can be handled on docs/website - many laws are not enforced to a written letter but judged if they violate the spirit of the regulation (happened with GDPR I think). So as long as we explain that's the idea behind the license choice - to protect forgejo from being taken over and used in a SaaS environment with no benefit for the main codebase (IMO) it will be quite clear what we would even try to enforce our copyright on and what wouldn't be a part of it. --- In any case as a starting point I'd like to propose a change to the current agreement which drops `or later` suffix. > Personally, I would like to see clarification to this agreement for the following points: > - The (initial) license of the distributed binary, so that it does not have to be changed every N weeks or months. > - A concrete list of allowed licenses. GPL-3.0-or-later compatible allows for many funny licenses to be used. At the bare minimum I would like to see licenses that at least have a SPDX identifier (this isn't the case for the frontend dependencies, so I'd argue this is a real concern), ideally the list would be narrowed down to 5-10 licenses for the sake of simplicity. This is not blocking for me, but it should be discussed at one point. Binary to be distributed under `GPL-3.0-only`. Accepted licenses: `GPL-3.0-only`, `GPL-3.0-or-later`, `GPL2.0-or later`, `MIT`, `EUPL-1.2`, `Apache-2.0` (apache I'm basing on [gnu license list](https://www.gnu.org/licenses/license-list.en.html#apache2)) Not accepted licenses: `AGPL-3.0-or-later`,`AGPL-3.0-only` - due to the fact the binary license would have to be changed. Motivation behind this: - It unlocks the EUPL-1.2 license and contributions basing or wanting to add it. - It kind of preserves the existing agreement (dropping only the `+`) Main and only drawback is ban on AGPL3.0 IMO. to make a non-binding vote for the option: 🚀 --- Alternative 2: Binary to be distributed under `AGPL-3.0-only`. Accepted licenses: `AGPL-3.0-or-later`,`AGPL-3.0-only`, `GPL-3.0-only`, `GPL-3.0-or-later`, `GPL2.0-or later`, `MIT`, `EUPL-1.2`, `Apache-2.0` (apache I'm basing on [gnu license list](https://www.gnu.org/licenses/license-list.en.html#apache2)). Motivation behind this: - Same as option 1 + AGPL inclusion which offers protection from reusing forgejo in SaaS without making the source available. vote option: 👀 --- Alternative 3: Binary to be distributed under `EUPL-1.2`. Accepted licenses: `MIT`, `EUPL-1.2` Others I'm not sure of so I'm not including them - I'm pretty sure that GPL cannot be converted into EUPL though. Motivation behind this: - Same as option 2 + AGPL level of protection + forced jurisdiction. vote option: ❤️ --- **Voting is non binding in any way** It's just there as a support probe. Nothing more.

jthvai commented 2024年07月29日 09:55:23 +02:00

Without taking a particular stance on the license choice itself, and briefly;

[...] many laws are not enforced to a written letter but judged if they violate the spirit of the regulation [...] it will be quite clear what we would even try to enforce our copyright on and what wouldn't be a part of it.

the reason we¹ have precise written agreements (contracts, if you will, though technically the license isn't one) is so that we need not extend that kind of trust to organisations, whose representative individuals and therefore incentives are ever changing² . I think expecting or requiring users to do so without the necessary knowledge is against the spirit of open source at best³ .

Edit: to be clear, I'm implying that we⁴ should educate more, not pick a weaker license for the sake of simplicity.

Without taking a particular stance on the license choice itself, and briefly; > [...] many laws are not enforced to a written letter but judged if they violate the spirit of the regulation [...] it will be quite clear what we would even try to enforce our copyright on and what wouldn't be a part of it. the reason we[^1] have precise written agreements (contracts, if you will, though technically the license isn't one) is so that we _need not_ extend that kind of trust to organisations, whose representative individuals and therefore incentives are ever changing[^2]. I think _expecting_ or _requiring_ users to do so without the necessary knowledge is against the spirit of open source at best[^3]. Edit: to be clear, I'm implying that we[^4] should educate more, not pick a weaker license for the sake of simplicity. [^1]: The set of all people. [^2]: Particularly, corporate entities often will not be willing to take that kind of risk. I also personally would not be comfortable taking that kind of risk, had I little knowledge of what the license entails. [^3]: It is rather similar to companies using a complicated proprietary license but assuring users that they'd never enforce the most unreasonable clauses. [^4]: Forgejo.

Ghost commented 2024年07月29日 10:15:37 +02:00

I meant that the user adding an easter-egg to their instance wouldn't be violating the spirit of the agreement while a SaaS which added a feature did violate it (when not releasing the source to public or on a request).
I don't think the "spirit way" is the best course of action here - just thought I mention it as it is a very useful way of dealing with "malicious compliance" - when the end user/org complies to the written letter of law but is in breach of the idea behind the letter which did help with enforcing some EU regulations.

I also think that the best course of action would be to add a document in docs listing what you can and can't do with the code and how to make changes to be in compliance with the license so the end user won't get reach misunderstanding of "I have to publish my entire filesystem if I am standing near forgejo" levels.

I meant that the user adding an easter-egg to their instance wouldn't be violating the spirit of the agreement while a SaaS which added a feature did violate it (when not releasing the source to public or on a request). I don't think the "spirit way" is the best course of action here - just thought I mention it as it is a very useful way of dealing with "malicious compliance" - when the end user/org complies to the written letter of law but is in breach of the idea behind the letter which did help with enforcing some EU regulations. I also think that the best course of action would be to add a document in docs listing what you can and can't do with the code and how to make changes to be in compliance with the license so the end user won't get reach misunderstanding of "I have to publish my entire filesystem if I am standing near forgejo" levels.

mahlzahn commented 2024年07月29日 11:04:49 +02:00

I meant that the user adding an easter-egg to their instance wouldn't be violating the spirit of the agreement while a SaaS which added a feature did violate it (when not releasing the source to public or on a request).

Although I understand your intention, I don’t think that this is a good idea, because it cannot be enforced by the Forgejo community. Any contributor of AGPL code (or contributor of an included AGPL package) could in theory sue the "violator" of the AGPL. If there is / was a plugin possibility without modification of the binary, maybe easter eggs, etc. can be otherwise added on top of forgejo which could be even closed source (but unfortunately IANAL). Maybe that is already technically doable.

> I meant that the user adding an easter-egg to their instance wouldn't be violating the spirit of the agreement while a SaaS which added a feature did violate it (when not releasing the source to public or on a request). Although I understand your intention, I don’t think that this is a good idea, because it cannot be enforced by the Forgejo community. Any contributor of AGPL code (or contributor of an included AGPL package) could in theory sue the "violator" of the AGPL. If there is / was a plugin possibility without modification of the binary, maybe easter eggs, etc. can be otherwise added on top of forgejo which could be even closed source (but unfortunately IANAL). Maybe that is already technically doable.

dallyger commented 2024年07月29日 12:29:57 +02:00

add a document in docs listing what you can and can't do [...] to be in
compliance with the license so the end user won't get reach misunderstanding
of "I have to publish my entire filesystem if I am standing near forgejo"

That is the exact situation I'm currently in and would help a lot!

Derivative works are also affected. These are external works that heavily
depend on Forgejo, where Forgejo is not linked (e.g. instead the web api is
used) and cannot be trivially replaced by a different service. There is some
room for interpretation here. Derivative works will also have to be licensed
under AGPL. -- #192 (comment)

The "There is some room for interpretation" is what I'm currently struggling
with. What exactly is the consequence for me, who manages a publicly accessible
but for internal use only (no registration allowed) instance, when Forgejo
migrates away from MIT? From the AGPL license:

A "covered work" means [...] a work based on the Program.

Does that include something like a Docker compose file to start an instance?
Must it be licensed as (A)GPL too then? And if it's in a project with multiple
unrelated compose files, do they have to be licensed as such too?
What about "infrastructure as code" in general?

Or another case: a CLI tool, that interacts with the Forgejo API, but does
other things as well?

If the Forgejo license applies to those scenarios too, we may have to migrate
away from it. The overhead of building and maintaining additional tooling /
infrastructure for this one service is not worth it for us.

Sorry if this is the wrong place to ask, but this thread sparked those questions.

> add a document in docs listing what you can and can't do [...] to be in > compliance with the license so the end user won't get reach misunderstanding > of "I have to publish my entire filesystem if I am standing near forgejo" That is the exact situation I'm currently in and would help a lot! > Derivative works are also affected. These are external works that heavily > depend on Forgejo, where Forgejo is not linked (e.g. instead the web api is > used) and cannot be trivially replaced by a different service. There is some > room for interpretation here. Derivative works will also have to be licensed > under AGPL. -- https://codeberg.org/forgejo/discussions/issues/192#issuecomment-2113883 The "There is some room for interpretation" is what I'm currently struggling with. What exactly is the consequence for me, who manages a publicly accessible but for internal use only (no registration allowed) instance, when Forgejo migrates away from MIT? From the AGPL license: > A "covered work" means [...] a work based on the Program. Does that include something like a Docker compose file to start an instance? Must it be licensed as (A)GPL too then? And if it's in a project with multiple unrelated compose files, do they have to be licensed as such too? What about "infrastructure as code" in general? Or another case: a CLI tool, that interacts with the Forgejo API, but does other things as well? If the Forgejo license applies to those scenarios too, we may have to migrate away from it. The overhead of building and maintaining additional tooling / infrastructure for this one service is not worth it for us. Sorry if this is the wrong place to ask, but this thread sparked those questions.

caesar commented 2024年07月29日 16:53:48 +02:00

EUPL-1.2 [...] AGPL level of protection

So far as I can tell this is not correct. It is approximately GPL (not AGPL) level of protection (which is why the code can be relicensed as GPL). There is no clause that I can see which requires source code to be distributed when the code is run on a public-facing server, it only has to be distributed if the binary is distributed.

That's my understanding but please correct me if I've missed something!

forced jurisdiction

I really like this aspect of EUPL, but I'm not sure if it's worth not being able to use GPL-licensed code.
(Also, it has a get-out clause, because EUPL code can be relicensed as GPL which doesn't have that forced jurisdiction.)

> EUPL-1.2 [...] AGPL level of protection So far as I can tell this is not correct. It is approximately GPL (not AGPL) level of protection (which is why the code can be relicensed as GPL). There is no clause that I can see which requires source code to be distributed when the code is run on a public-facing server, it only has to be distributed if the binary is distributed. That's my understanding but please correct me if I've missed something! > forced jurisdiction I really like this aspect of EUPL, but I'm not sure if it's worth not being able to use GPL-licensed code. (Also, it has a get-out clause, because EUPL code can be relicensed as GPL which doesn't have that forced jurisdiction.)

caesar commented 2024年07月29日 17:00:21 +02:00

Does that include something like a Docker compose file to start an instance?
Must it be licensed as (A)GPL too then? And if it's in a project with multiple
unrelated compose files, do they have to be licensed as such too?
What about "infrastructure as code" in general?

Or another case: a CLI tool, that interacts with the Forgejo API, but does
other things as well?

@dallyger I believe the answer to both questions is that they are not derivative works. In some jurisdictions there is an ambiguity about linking, but I'm not aware of any case where interacting with an API would be covered.

(That said, I know that in the past Automattic have tried to argue that all WordPress plugins must be GPL because they interact with the WordPress plugin API. In my opinion that argument is incorrect given the license text – and also given legal precedent in several jurisdictions that APIs can't be copyrighted – but I am not a lawyer. So far as I am aware their argument has never been tested in court.)

In the case of the Docker file, Docker and docker-compose are Apache-licensed which is also copyleft but that doesn't mean your docker compose files (or all docker images for example) have to be Apache-licensed.

> Does that include something like a Docker compose file to start an instance? > Must it be licensed as (A)GPL too then? And if it's in a project with multiple > unrelated compose files, do they have to be licensed as such too? > What about "infrastructure as code" in general? > > Or another case: a CLI tool, that interacts with the Forgejo API, but does > other things as well? @dallyger I believe the answer to both questions is that they are not derivative works. In some jurisdictions there is an ambiguity about linking, but I'm not aware of any case where interacting with an API would be covered. (That said, I know that in the past Automattic have tried to argue that all WordPress plugins must be GPL because they interact with the WordPress plugin API. In my opinion that argument is incorrect given the license text – and also given legal precedent in several jurisdictions that APIs can't be copyrighted – but I am not a lawyer. So far as I am aware their argument has never been tested in court.) In the case of the Docker file, Docker and docker-compose are Apache-licensed which is also copyleft but that doesn't mean your docker compose files (or all docker images for example) have to be Apache-licensed.

bramh commented 2024年07月29日 17:27:53 +02:00

So far as I can tell this is not correct. It is approximately GPL (not AGPL) level of protection (which is why the code can be relicensed as GPL). There is no clause that I can see which requires source code to be distributed when the code is run on a public-facing server, it only has to be distributed if the binary is distributed.

@caesar EUPL defines distribution as follows:

any act of selling, giving, lending, renting, distributing, communicating, transmitting, or otherwise making available, online or offline, copies of the Work or providing access to its essential functionalities at the disposal of any other natural or legal person.

It is stated more explicitly in the case of AGPL (section 13), but I believe in the end this definition is similar to the one used in AGPL. The FAQ also elaborates on this:

Does the EUPL close the SaaS/ASP loophole?

Yes: the definitions in article 1 of the EUPL (unmodified in all EUPL versions so far) assimilates "communication to the public" to "distribution" and therefore targets and covers SaaS (software as a service) and the ASP (application service provider) activity.
[...]
Therefore on this specific point, the EUPL is similar to the AGPL.

and

Can I provide services on Internet, based on EUPL licensed software?

Yes you can. Indeed, Article 2 of the EUPL provides you the right to "communicate to the public, including the right to make available or display the Work or copies thereof to the public and perform publicly, as the case may be, the Work".

Therefore, the deployment of the EUPL licensed software via Internet or via any similar public network is considered as a case of «distribution» according to the licence. This remains true even if the end-users perceive (for example through their Internet browser) only a selection of functionalities and not the whole software itself.

As soon such communication of EUPL software is done, the licence covers it (because – according to Article 10, the licence is accepted by exercising any rights granted by Article 2). However, this means also that, if you modify or improve some EUPL licensed software and use it to provide your services on line to the general public, you have to make your modified source code available on a repository, in order to allow the original author as well as other members of the «developers community » to benefit from your contributions, as the case could be.

> So far as I can tell this is not correct. It is approximately GPL (not AGPL) level of protection (which is why the code can be relicensed as GPL). There is no clause that I can see which requires source code to be distributed when the code is run on a public-facing server, it only has to be distributed if the binary is distributed. @caesar EUPL defines distribution as follows: > any act of selling, giving, lending, renting, distributing, communicating, transmitting, or otherwise making available, online or offline, copies of the Work or providing access to its essential functionalities at the disposal of any other natural or legal person. It is stated more explicitly in the case of AGPL (section 13), but I believe in the end this definition is similar to the one used in AGPL. The [FAQ](https://joinup.ec.europa.eu/collection/eupl/how-use-eupl) also elaborates on this: > Does the EUPL close the SaaS/ASP loophole? > > Yes: the definitions in article 1 of the EUPL (unmodified in all EUPL versions so far) assimilates "communication to the public" to "distribution" and therefore targets and covers SaaS (software as a service) and the ASP (application service provider) activity. > [...] > Therefore on this specific point, the EUPL is similar to the AGPL. and > Can I provide services on Internet, based on EUPL licensed software? > > Yes you can. Indeed, Article 2 of the EUPL provides you the right to "communicate to the public, including the right to make available or display the Work or copies thereof to the public and perform publicly, as the case may be, the Work". > > Therefore, the deployment of the EUPL licensed software via Internet or via any similar public network is considered as a case of «distribution» according to the licence. This remains true even if the end-users perceive (for example through their Internet browser) only a selection of functionalities and not the whole software itself. > > As soon such communication of EUPL software is done, the licence covers it (because – according to Article 10, the licence is accepted by exercising any rights granted by Article 2). However, this means also that, if you modify or improve some EUPL licensed software and use it to provide your services on line to the general public, you have to make your modified source code available on a repository, in order to allow the original author as well as other members of the «developers community » to benefit from your contributions, as the case could be.

Ghost commented 2024年07月29日 18:22:04 +02:00

You beat me to the answer :D

Additionally in the same FAQ:

Is the use of a compatible licence a "re-licensing"?

No. The original code will stay covered by the EUPL. It is the combined work only that could be, when needed, covered by the compatible licence. In this framework, a combined work results from merging functional codes covered by two (or more) different licenses. The simple action of "linking" does not merge functional codes and in such case the various linked parts will keep their primary licences. This is resulting from the European law, since Directive 2009/24/EC states that interfaces (APIs, data structures etc.) needed for making two programs interoperable can be freely reproduced/used in the various source codes, as an exception to strict copyright rules.

To be legitimate, the use of the compatibility clause must result from necessity: using it for the sole purpose of relicensing a copy of the original work would be a copyright infringement.

Which would make EUPL use in code okay because the license change comes from a necessity. (This also partially addresses @dallyger questions).

Some of the listed compatible licences, like the MPL or the EPL are known to be "less copyleft" or "less reciprocal" than the EUPL. Is there a risk to reduce the EUPL reciprocity (obligation to provide the source code) or the EUPL coverage (since "communication to the public" covers the remote performance of software through a network, also known as SaaS)?

The EUPL states that in case the compatibility clause is used legitimately, "Should the Licensee’s obligations under the Compatible Licence conflict with their obligations under this (EUPL) Licence, the obligations of the Compatible Licence shall prevail." Yes, but other obligations, in particular resulting from the definition of Distribution (Article 1 of the EUPL related to the coverage of Communication to the public or SaaS, like the AGPL) and the obligation to provide access to the source code will persist in addition to those of the Compatible Licence, because none of the compatible licenses are in conflict with the EUPL on these specific points: for example, the GPL does not mandate to provide access to the source code in case the software is performed remotely, but it does not prohibit it.

So the reciprocal/copyleft effect of the EUPL, even if like the LGPL it is not viral in the case of linking, is stronger than it may appear at first reading when the compatibility clause is legitimately used.

So the code would be covered by network clause.

---

Does that include something like a Docker compose file to start an instance? Must it be licensed as (A)GPL too then? And if it's in a project with multiple unrelated compose files, do they have to be licensed as such too? What about "infrastructure as code" in general?

It doesn't have to as it's not directly touching the codebase. You only use the binary which would be licensed under AGPL and your only obligation is to point to the http://codeberg.org/forgejo/forgejo as the source code repository.

Or another case: a CLI tool, that interacts with the Forgejo API, but does other things as well?

Even if it interacts with the API it's not required to be AGPL or even open source.

If the Forgejo license applies to those scenarios too, we may have to migrate away from it. The overhead of building and maintaining additional tooling / infrastructure for this one service is not worth it for us.

Then I'm happy to say that you misunderstood the AGPL license :) It only covers the Work (forgejo) not the whatever thing you build to support your instance.

Sorry if this is the wrong place to ask, but this thread sparked those questions.

Good, those might help make more informed decision.

You beat me to the answer :D Additionally in the same FAQ: >> Is the use of a compatible licence a "re-licensing"? > > No. The original code will stay covered by the EUPL. It is the combined work only that could be, when needed, covered by the compatible licence. In this framework, a combined work results from merging functional codes covered by two (or more) different licenses. The simple action of "linking" does not merge functional codes and in such case the various linked parts will keep their primary licences. This is resulting from the European law, since Directive 2009/24/EC states that interfaces (APIs, data structures etc.) needed for making two programs interoperable can be freely reproduced/used in the various source codes, as an exception to strict copyright rules. > > To be legitimate, the use of the compatibility clause must result from necessity: using it for the sole purpose of relicensing a copy of the original work would be a copyright infringement. Which would make EUPL use in code okay because the license change comes from a necessity. (This also partially addresses @dallyger questions). > Some of the listed compatible licences, like the MPL or the EPL are known to be "less copyleft" or "less reciprocal" than the EUPL. Is there a risk to reduce the EUPL reciprocity (obligation to provide the source code) or the EUPL coverage (since "communication to the public" covers the remote performance of software through a network, also known as SaaS)? > > The EUPL states that in case the compatibility clause is used legitimately, "Should the Licensee’s obligations under the Compatible Licence conflict with their obligations under this (EUPL) Licence, the obligations of the Compatible Licence shall prevail." Yes, but other obligations, in particular resulting from the definition of Distribution (Article 1 of the EUPL related to the coverage of Communication to the public or SaaS, like the AGPL) and the obligation to provide access to the source code will persist in addition to those of the Compatible Licence, because none of the compatible licenses are in conflict with the EUPL on these specific points: for example, the GPL does not mandate to provide access to the source code in case the software is performed remotely, but it does not prohibit it. > > So the reciprocal/copyleft effect of the EUPL, even if like the LGPL it is not viral in the case of linking, is stronger than it may appear at first reading when the compatibility clause is legitimately used. So the code would be covered by network clause. --- > Does that include something like a Docker compose file to start an instance? Must it be licensed as (A)GPL too then? And if it's in a project with multiple unrelated compose files, do they have to be licensed as such too? What about "infrastructure as code" in general? It doesn't have to as it's not directly touching the codebase. You only use the binary which would be licensed under AGPL and your only obligation is to point to the http://codeberg.org/forgejo/forgejo as the source code repository. > Or another case: a CLI tool, that interacts with the Forgejo API, but does other things as well? Even if it interacts with the API it's not required to be AGPL or even open source. > If the Forgejo license applies to those scenarios too, we may have to migrate away from it. The overhead of building and maintaining additional tooling / infrastructure for this one service is not worth it for us. Then I'm happy to say that you misunderstood the AGPL license :) It only covers the Work (forgejo) not the whatever thing you build to support your instance. > Sorry if this is the wrong place to ask, but this thread sparked those questions. Good, those might help make more informed decision.

fnetX commented 2024年07月29日 18:28:06 +02:00

@dallyger

Does that include something like a Docker compose file to start an instance?

It was answered, but only for reference: There was a case where a license tried to force this (publication of deployment support etc). Note that OSI did not consider this an Open Source but rather a "fauxpen" license.

@dallyger > Does that include something like a Docker compose file to start an instance? It was answered, but only for reference: There was a case [where a license tried to force this](https://en.wikipedia.org/wiki/Server_Side_Public_License) (publication of deployment support etc). Note that OSI did not consider this an Open Source but rather a "fauxpen" license.

jerger commented 2024年07月29日 19:25:13 +02:00

I did not follow closely through the whole discussion. But AGPL was mentioned very often.

I personally never felt the motivation to contribute to AGPL projects. If this will change here I would have either to change my mind (I am slightly opinionated) or stopping to contribute here.

So if you plan to switch the Forgejo to AGPL I ask to make a dedicated discussion about this by its own.

I did not follow closely through the whole discussion. But AGPL was mentioned very often. I personally never felt the motivation to contribute to AGPL projects. If this will change here I would have either to change my mind (I am slightly opinionated) or stopping to contribute here. So if you plan to switch the Forgejo to AGPL I ask to make a dedicated discussion about this by its own.

n0toose commented 2024年07月29日 19:43:53 +02:00

I think that a balance between staying "friendly" towards different use cases and stakeholders (as in, people that actually contribute back, and the people that could potentially contribute back - not in the current SaaS style) is crucial, and we should avoid giving people that just want to make a private instance with minor modifications headaches. My argument so far behind the usage of the MIT license is that there's possibly more to software freedom than just the license, and putting people - perhaps not the large companies that would take this work and "not give anything back". If we find a middle ground to let as many users as possible, including companies, stop relying on GitLab and GitHub, that would mean that we have achieved a philosophical goal that would otherwise be very hard to reach. But where is the balance?

Think about it: Is, say, Amazon taking our source code and creating a million dollar product without giving anything back more important than letting, say, GitLab, somehow incorporate our code into their million dollar product? People use Forgejo for the sake "of just installing it, hosting code and spreading it further" without relying on a fully closed-sourced platform - that includes avoiding headaches. I think that by arguing about definitions and making people take absolute decisions, we collectively have to take a step back and consider why we want to do this, what are we looking to prevent, and are there any better / worse ways of achieving our goals? Through large paragraphs like the one I'm typing, there is not much of a way to reach consensus here - but this is a call for us to take a step back.

We should ask questions like this: Do we want to make it harder for SaaS services to not give anything back? I had heard of an idea about using a less permissive license on tests - the binary would not be "tainted", which means that the user could continue using Forgejo, but a fork developer would have to release their source code. Would trademark enforcement work better?

I think that a balance between staying "friendly" towards different use cases and stakeholders (as in, people that actually contribute back, and the people that *could* potentially contribute back - not in the current SaaS style) is crucial, and we should avoid giving people that just want to make a private instance with minor modifications headaches. My argument so far behind the usage of the MIT license is that there's *possibly* more to software freedom than ***just*** the license, and putting *people* - perhaps not the large companies that would take this work and "not give anything back". If we find a *middle ground* to let as many users as possible, including companies, stop relying on GitLab and GitHub, that would mean that we have achieved a philosophical goal that would otherwise be very hard to reach. But where is the balance? Think about it: Is, say, Amazon taking our source code and creating a million dollar product without giving anything back *more* important than letting, say, GitLab, somehow incorporate our code into their million dollar product? People use Forgejo for the sake "of just installing it, hosting code and spreading it further" without relying on a fully closed-sourced platform - that includes avoiding headaches. I think that by arguing about definitions and making people take absolute decisions, we collectively have to take a step back and consider why we want to do this, what are we looking to prevent, and are there any better / *worse* ways of achieving our goals? Through large paragraphs like the one I'm typing, there is not much of a way to reach consensus here - but this is a call for us to take a step back. We should ask questions like this: Do we want to make it harder for SaaS services to not give anything back? I had heard of an idea about using a less permissive license on tests - the binary would not be "tainted", which means that the user could continue using Forgejo, but a fork developer would have to release their source code. Would trademark enforcement work better?

n0toose commented 2024年07月29日 19:46:20 +02:00

Like, I don't know, instead of making absolute binary decisions without explaining why, and putting people in a position where they have to become even more absolute, is not very productive. Like, personally, I am not strictly against either of the options mentioned above, but we're discussing what the user would be able to do depending on the final decision but we're not strategizing in any capacity or necessarily thoroughly explaining what change we want to achieve, and at what expense.

Does anybody else agree that something with the current debate has to change and that we have to figure out a better way to solve this problem as part of a collective?

Like, I don't know, instead of making absolute binary decisions without explaining why, and putting people in a position where they have to become even more absolute, is not very productive. Like, personally, I am not strictly against either of the options mentioned above, but we're discussing what the user *would* be able to do depending on the final decision but we're not strategizing in any capacity or necessarily thoroughly explaining what change we want to achieve, and *at what expense*. Does anybody else agree that something with the current debate has to change and that we have to figure out a better way to solve this problem as part of a collective?

bramh commented 2024年07月29日 20:42:52 +02:00

I personally never felt the motivation to contribute to AGPL projects. If this will change here I would have either to change my mind (I am slightly opinionated) or stopping to contribute here.

@jerger There is an agreement to allow GPL-3.0-or-later-compatible contributions (forgejo/governance#24 and related blog post), which means the license of Forgejo will have to change to something that allows these contributions. AGPL is not the only option, which license would have your preference? I think it's worth considering all our options.

> I personally never felt the motivation to contribute to AGPL projects. If this will change here I would have either to change my mind (I am slightly opinionated) or stopping to contribute here. @jerger There is an agreement to allow `GPL-3.0-or-later`-compatible contributions (https://codeberg.org/forgejo/governance/pulls/24 and [related blog post](https://forgejo.org/2023-06-copyleft/)), which means the license of Forgejo will have to change to something that allows these contributions. AGPL is not the only option, which license would have your preference? I think it's worth considering all our options.

earl-warren commented 2024年07月29日 21:07:58 +02:00

On thing came to mind today, just sharing. There are people who prefer that Forgejo is:

• MIT
• Copyleft (GPLv3 style, more or less equivalent to MIT when it comes to server software)
• Copyleft (AGPLv3 style, share-alike when it comes to server software)

At the moment these three groups are represented in Forgejo users, admins and contributors:

• MIT is not an issue (if it was, those people would not use Forgejo)
• Copyleft (GPLv3 style) will be an issue for those who prefer MIT for $reasons and there will be a lot of discussions
• Copyleft (AGPLv3 style) will be an issue for those who prefer MIT and for those who prefer copyleft (GPLv3 style) for $reseaons and there will be a lot more discussions

As time passes and the number of people using, running and contributing to Forgejo grows, the resistance to a license change will also grow, at least linearly. I'm not sure what to do with that realization but I'm sure of one thing: the longer it takes for Forgejo to actually make a move to one of those steps, the harder it will be.

On thing came to mind today, just sharing. There are people who prefer that Forgejo is: * MIT * Copyleft (GPLv3 style, more or less equivalent to MIT when it comes to server software) * Copyleft (AGPLv3 style, share-alike when it comes to server software) At the moment these three groups are represented in Forgejo users, admins and contributors: * MIT is not an issue (if it was, those people would not use Forgejo) * Copyleft (GPLv3 style) will be an issue for those who prefer MIT for $reasons and there will be a **lot** of discussions * Copyleft (AGPLv3 style) will be an issue for those who prefer MIT **and** for those who prefer copyleft (GPLv3 style) for $reseaons and there will be a **lot** more discussions As time passes and the number of people using, running and contributing to Forgejo grows, the resistance to a license change will also grow, at least linearly. I'm not sure what to do with that realization but I'm sure of one thing: the longer it takes for Forgejo to actually make a move to one of those steps, the harder it will be.

fnetX commented 2024年07月30日 01:37:10 +02:00

I created a poll that can be sent out to endusers and admins to learn more. https://cryptpad.fr/form/#/2/form/view/mPtfT0YiWOQzUe9LuNKeJQxOC64LdGTvT7JXRlfl1Pk/

If there are no objections, I recommend that we share this (will use Codeberg's socialmedia channels, and would appreciate Matrix+Mastodon on Forgejo's side).

We can focus on the v8 release, bugfixing, the dependency licensing issue ... and come back in one week to see if this generated any meaningful input.

I hope that it confirms we are on the right track and whatever we decide for will be supported by most of our users.

I would appreciate if we could learn about @jerger 's concerns and address them.

I created a poll that can be sent out to endusers and admins to learn more. https://cryptpad.fr/form/#/2/form/view/mPtfT0YiWOQzUe9LuNKeJQxOC64LdGTvT7JXRlfl1Pk/ If there are no objections, I recommend that we share this (will use Codeberg's socialmedia channels, and would appreciate Matrix+Mastodon on Forgejo's side). We can focus on the v8 release, bugfixing, the dependency licensing issue ... and come back in one week to see if this generated any meaningful input. I hope that it confirms we are on the right track and whatever we decide for will be supported by most of our users. I would appreciate if we could learn about @jerger 's concerns and address them.

caesar commented 2024年07月30日 01:49:23 +02:00

Thanks @bramh and @thefox for correcting me on EUPL, it is more like AGPL than I realised due to the phrase providing access to its essential functionalities.

That said, in the end the entire strength depends on the interpretation of what is a "legitimate" justification to redistribute the code under a weaker license.

The EUPL states that in case the compatibility clause is used legitimately, "Should the Licensee’s obligations under the Compatible Licence conflict with their obligations under this (EUPL) Licence, the obligations of the Compatible Licence shall prevail." Yes, but other obligations, in particular resulting from the definition of Distribution (Article 1 of the EUPL related to the coverage of Communication to the public or SaaS, like the AGPL) and the obligation to provide access to the source code will persist in addition to those of the Compatible Licence, because none of the compatible licenses are in conflict with the EUPL on these specific points: for example, the GPL does not mandate to provide access to the source code in case the software is performed remotely, but it does not prohibit it.

This is a strange form of "compatibility", because if read literally (and note that this is explanatory text, not part of the license), it would mean derivative works can be distributed under a a kind of mish-mash of the two licenses, but not entirely under GPL.

Thanks @bramh and @thefox for correcting me on EUPL, it is more like AGPL than I realised due to the phrase `providing access to its essential functionalities`. That said, in the end the entire strength depends on the interpretation of what is a "legitimate" justification to redistribute the code under a weaker license. > The EUPL states that in case the compatibility clause is used legitimately, "Should the Licensee’s obligations under the Compatible Licence conflict with their obligations under this (EUPL) Licence, the obligations of the Compatible Licence shall prevail." Yes, but other obligations, in particular resulting from the definition of Distribution (Article 1 of the EUPL related to the coverage of Communication to the public or SaaS, like the AGPL) and the obligation to provide access to the source code will persist in addition to those of the Compatible Licence, because none of the compatible licenses are in conflict with the EUPL on these specific points: for example, the GPL does not mandate to provide access to the source code in case the software is performed remotely, but it does not prohibit it. This is a strange form of "compatibility", because if read literally (and note that this is explanatory text, not part of the license), it would mean derivative works can be distributed under a a kind of mish-mash of the two licenses, but not entirely under GPL.

jthvai commented 2024年07月30日 06:58:48 +02:00

I created a poll that can be sent out to endusers and admins to learn more. https://cryptpad.fr/form/#/2/form/view/mPtfT0YiWOQzUe9LuNKeJQxOC64LdGTvT7JXRlfl1Pk/

@fnetX I don't feel like "-only or -later" should be combined into one option in the matrix, as that seems to be one of the biggest disagreements here.

> I created a poll that can be sent out to endusers and admins to learn more. https://cryptpad.fr/form/#/2/form/view/mPtfT0YiWOQzUe9LuNKeJQxOC64LdGTvT7JXRlfl1Pk/ @fnetX I don't feel like "-only or -later" should be combined into one option in the matrix, as that seems to be one of the biggest disagreements here.

jerger commented 2024年07月30日 08:13:20 +02:00

@jerger There is an agreement to allow GPL-3.0-or-later-compatible contributions (forgejo/governance#24 and related blog post), which means the license of Forgejo will have to change to something that allows these contributions. AGPL is not the only option, which license would have your preference? I think it's worth considering all our options.

I contribute to OpenSource because it is open and it is easy to cooperate between very different actors all over the world.

As more constraints we put on top as less free it is. So in the question of "make saas impossible <-> freedom" I will vote for freedom.

I think if amazon is building a saas service out of Forgejo the will make money out of our work - but this will also be a sign of our success, isn't it ?

So lets solve the saas issue when ever it occurs and concentrate for now on our sustainable growth.

For myself I prefer the apache2 license, LGPL / MIT is fine, GPL-* I can agree on.

EUPL I do not know ...

> @jerger There is an agreement to allow `GPL-3.0-or-later`-compatible contributions (https://codeberg.org/forgejo/governance/pulls/24 and [related blog post](https://forgejo.org/2023-06-copyleft/)), which means the license of Forgejo will have to change to something that allows these contributions. AGPL is not the only option, which license would have your preference? I think it's worth considering all our options. I contribute to OpenSource because it is open and it is easy to cooperate between very different actors all over the world. As more constraints we put on top as less free it is. So in the question of "make saas impossible <-> freedom" I will vote for freedom. I think if amazon is building a saas service out of Forgejo the will make money out of our work - but this will also be a sign of our success, isn't it ? So lets solve the saas issue when ever it occurs and concentrate for now on our sustainable growth. For myself I prefer the apache2 license, LGPL / MIT is fine, GPL-* I can agree on. EUPL I do not know ...

caesar commented 2024年07月30日 09:56:17 +02:00

make saas impossible

AGPL does not make SAAS impossible, it just means SAAS providers (such as Codeberg, Codey, or VSHN) will have to share the code for any modifications they make, just as those who distribute binary versions would have to under GPL.

For example, it wouldn't make a Forgejo-based Allspice impossible, but it would mean it had to be open source, whereas GPL does not require that.

> make saas impossible AGPL does not make SAAS impossible, it just means SAAS providers (such as Codeberg, [Codey](https://www.codey.ch/), or [VSHN](https://products.vshn.ch/appcat/forgejo.html)) will have to share the code for any modifications they make, just as those who distribute binary versions would have to under GPL. For example, it wouldn't make a Forgejo-based [Allspice](https://allspice.io/) impossible, but it would mean it had to be open source, whereas GPL does not require that.

bramh commented 2024年07月30日 11:54:11 +02:00

This is a strange form of "compatibility", because if read literally (and note that this is explanatory text, not part of the license), it would mean derivative works can be distributed under a a kind of mish-mash of the two licenses, but not entirely under GPL.

I have no idea if their reasoning is legally binding (IANAL, and I couldn't find an existing case related to this), but I think this is just confusing for all parties involved. If I understand correctly, it will say GPLv3 on the tin (as per the compatibility clause), but extra limitations apply to the entire binary. This means that users now have to familiarize themselves with two licenses (and how they differ in compatible ways), if they can even figure out that the EUPL is in effect too. I don't think this makes anyone's life easier.

> This is a strange form of "compatibility", because if read literally (and note that this is explanatory text, not part of the license), it would mean derivative works can be distributed under a a kind of mish-mash of the two licenses, but not entirely under GPL. I have no idea if their reasoning is legally binding (IANAL, and I couldn't find an existing case related to this), but I think this is just confusing for all parties involved. If I understand correctly, it will say GPLv3 on the tin (as per the compatibility clause), but extra limitations apply to the entire binary. This means that users now have to familiarize themselves with two licenses (and how they differ in compatible ways), if they can even figure out that the EUPL is in effect too. I don't think this makes anyone's life easier.

earl-warren commented 2024年07月30日 12:57:25 +02:00

I think if amazon is building a saas service out of Forgejo the will make money out of our work - but this will also be a sign of our success, isn't it ?

It will take years before that happens but it is not impossible. In all cases it will be a acknowledgement that Forgejo meets the need of a large number of users. But calling it a success highly depends on Forgejo's legal protection.

To take a known example, VLC, its license was changed from GPL to LGPL. It allowed it to be embedded in hundred of millions of devices (internet provider devices installed in user's home, plane seats, you name it) without any mention of it ever existing. And nowadays, more than a decade later, VLC is still maintained by a tiny company of two dozen people. They are doing an amazing job, I don't dispute that. But the resources at their disposal is out of proportion compared to how wide spread the product is. Their choice of license essentially ensured that predatory behavior from large corporations was allowed and welcome. And there was no need to tell them twice: they went for it.

I don't want the same fate for Forgejo and I will work to add a feature (it was suggested last year, IIRC, by @oliverpool ) that makes it possible to download Forgejo's source code from a running instance. Such a feature can be removed under the terms of the current GPLv3+ license and is not legally binding. But when it is included in Forgejo's version, complying in spirit with the terms of the AGPL will be trivial. And then I will advocate for a change of license to switch to AGPL.

At least that's more or less what I have in mind now and I suspect it will take at least another year or two before it happens... if it happens at all. My priority is to forge federation. Maybe someone else will find another path, easier and faster. But in any case I'll keep advocating for some legal protection in this direction.

> I think if amazon is building a saas service out of Forgejo the will make money out of our work - but this will also be a sign of our success, isn't it ? It will take years before that happens but it is not impossible. In all cases it will be a acknowledgement that Forgejo meets the need of a large number of users. But calling it a success highly depends on Forgejo's legal protection. To take a known example, VLC, its license was changed from GPL to LGPL. It allowed it to be embedded in hundred of millions of devices (internet provider devices installed in user's home, plane seats, you name it) without any mention of it ever existing. And nowadays, more than a decade later, VLC is still maintained by a tiny company of two dozen people. They are doing an amazing job, I don't dispute that. But the resources at their disposal is out of proportion compared to how wide spread the product is. Their choice of license essentially ensured that predatory behavior from large corporations was allowed and welcome. And there was no need to tell them twice: they went for it. I don't want the same fate for Forgejo and I will work to add a feature (it was suggested last year, IIRC, by @oliverpool ) that makes it possible to download Forgejo's source code from a running instance. Such a feature can be removed under the terms of the current GPLv3+ license and is not legally binding. But when it is included in Forgejo's version, complying in spirit with the terms of the AGPL will be trivial. And then I will advocate for a change of license to switch to AGPL. At least that's more or less what I have in mind now and I suspect it will take at least another year or two before it happens... if it happens at all. My priority is to forge federation. Maybe someone else will find another path, easier and faster. But in any case I'll keep advocating for some legal protection in this direction.

fnetX commented 2024年07月30日 12:59:13 +02:00

@jthvai #192 (comment)

I focused the poll on license families that are likely relevant to endusers. It does supplement how they would react to it.

The -only vs -or-later discussion is in my eyes only relevant to Forgejo contributors, thinking about long-term implications of their decisions.

@jthvai https://codeberg.org/forgejo/discussions/issues/192#issuecomment-2122486 I focused the poll on license families that are likely relevant to endusers. It does supplement how they would react to it. The -only vs -or-later discussion is in my eyes only relevant to Forgejo contributors, thinking about long-term implications of their decisions.

fnetX commented 2024年07月30日 13:32:53 +02:00

I am trying to summarize the motivations for and against changes and what they require. I hope I didn't miss anything in my summary below. Please suggest changes and I'll apply them to the comment.

No proprietary binaries

Currently, someone could go ahead and create a proprietary Forgejo fork ("Forge++ Enterprice Edition" for example).
Impact: Very low, there is no such case known yet.
Benefit: Medium, Forgejo is copyleft and allows inclusion of weak copyleft dependencies, but there are few practical consequences of this
Requires: any copyleft license.

No proprietary SaaS

Someone could go ahead and create a proprietary SaaS offering without disclosing Forgejo. It could even be white-labelled.
Impact: High, it requires service providers currently looking into Forgejo not to build a business model on proprietary code, but to disclose all their work as free software. Given Allspice exists based on Gitea, chances for this are real. It also has an impact on everyone who patches Forgejo slightly and requires publishing the patches, too.
Benefit: Such service providers might not be Forgejo customers and might reduce our development power and financial contribution. On the other hand, it is a positive change for users, because they cannot get locked in by proprietary offerings, and any service provider would need to work on Forgejo as free/libre software only.
Requires: AGPLv3-only, -or-later or EUPLv1.2

No inspiration without credits

There have been cases reported where code was surprisingly similar to code written for Forgejo, without copyright. While the MIT license already prevents this, it is harder to enforce in practice, because consequences are low (naming the original author is enough). Copyleft licenses discourage people to copy code, because if it is discovered, it would mean the code must be removed / rewritten in a different way, and versions containing it would need to change license to copyleft in addition to naming the original author.
Impact: Low for end-users, but high for others getting inspired by Forgejo without credit.
Benefit: Since such cases were claimed, it is likely they would be prevented.
Requires: any copyleft license.

License clarity for end-users

Copyleft licenses are usually much longer and harder to understand for end-users. It was argued that the EUPL is easier to understand and it has the benefit of having official translations in many more languages.
Impact: ?
Benefit: Forgejo users are more likely to accept the change.
Requires: EUPLv1.2

Including copyleft dependencies

Forgejo used copyleft code in the past, that was removed recently after being discovered. To get the most functionality into Forgejo, it would be beneficial to not limit ourselves to "permissively" licensed libraries but also allow including copyleft upstream dependencies.
Impact: Since there were copyleft dependencies in the past, this has real impact on Forgejo.
Benefit: More freedom when choosing dependencies.
Requires: the stronger the copyleft, the more available dependencies. This dependency and maybe more are AGPLv3(+), so would only be possible to include with this license (or CPAL for the record)

Avoid license changes in succession

Some people fear that repeated license changes can be confusing to end-users and put us in a bad light ("they don't know what they are doing"-style). Further, users could fear more license changes.
Impact: Users would need to read and understand multiple legal texts to assess if it requires changes.
Benefit: Less work for Forgejo, less confusion among users.
Requires: Holding back copyleft code until we agree on a license for the foreseeable future.

No locked license version

Some contributors feared that choosing -only license variants over -or-later would lock us to a version that does not reflect changes in jurisdiction around the earth. -or-later variants allow for the license creators to publish updated versions that address legal issues with the past license text.
Impact: Unknown, depends on external factors.
Benefit: Unknown, too. Choosing upgradable licenses likely mean Forgejo is safer for the (very) long-term future, but it might not matter on a horizon of 10 to 20 years.

---

There are also contra positions to some of the above, namely:

• go ahead quickly to allow copyleft code (works against "Avoid license changes in succession", "License clarity for end-users")
• do not limit the possibility for proprietary SaaS (works against "No proprietary SaaS" and partially against "Including copyleft dependencies", too)
• freeze license versions (obviously works against "No locked license version")

I am trying to summarize the motivations for and against changes and what they require. I hope I didn't miss anything in my summary below. Please suggest changes and I'll apply them to the comment. ### No proprietary binaries Currently, someone could go ahead and create a proprietary Forgejo fork ("Forge++ Enterprice Edition" for example). **Impact:** Very low, there is no such case known yet. **Benefit:** Medium, Forgejo is copyleft and allows inclusion of weak copyleft dependencies, but there are few practical consequences of this **Requires:** any copyleft license. ### No proprietary SaaS Someone could go ahead and create a proprietary SaaS offering without disclosing Forgejo. It could even be white-labelled. **Impact:** High, it requires service providers currently looking into Forgejo not to build a business model on proprietary code, but to disclose all their work as free software. Given [Allspice](https://allspice.io/) exists based on Gitea, chances for this are real. It also has an impact on everyone who patches Forgejo slightly and requires publishing the patches, too. **Benefit:** Such service providers might not be Forgejo customers and might reduce our development power and financial contribution. On the other hand, it is a positive change for users, because they cannot get locked in by proprietary offerings, and any service provider would need to work on Forgejo as free/libre software only. **Requires:** AGPLv3-only, -or-later or EUPLv1.2 ### No inspiration without credits There have been cases reported where code was surprisingly similar to code written for Forgejo, without copyright. While the MIT license already prevents this, it is harder to enforce in practice, because consequences are low (naming the original author is enough). Copyleft licenses discourage people to copy code, because if it is discovered, it would mean the code must be removed / rewritten in a different way, and versions containing it would need to change license to copyleft in addition to naming the original author. **Impact:** Low for end-users, but high for others getting inspired by Forgejo without credit. **Benefit:** Since such cases were claimed, it is likely they would be prevented. **Requires:** any copyleft license. ### License clarity for end-users Copyleft licenses are usually much longer and harder to understand for end-users. It was argued that the EUPL is easier to understand and it has the benefit of having official translations in many more languages. **Impact:** ? **Benefit:** Forgejo users are more likely to accept the change. **Requires:** EUPLv1.2 ### Including copyleft dependencies Forgejo used copyleft code in the past, that was removed recently after being discovered. To get the most functionality into Forgejo, it would be beneficial to not limit ourselves to "permissively" licensed libraries but also allow including copyleft upstream dependencies. **Impact:** Since there were copyleft dependencies in the past, this has real impact on Forgejo. **Benefit:** More freedom when choosing dependencies. **Requires:** the stronger the copyleft, the more available dependencies. [This dependency](https://github.com/Juris-M/citeproc-js) and maybe more are AGPLv3(+), so would only be possible to include with this license (or CPAL for the record) ### Avoid license changes in succession Some people fear that repeated license changes can be confusing to end-users and put us in a bad light ("they don't know what they are doing"-style). Further, users could fear more license changes. **Impact:** Users would need to read and understand multiple legal texts to assess if it requires changes. **Benefit:** Less work for Forgejo, less confusion among users. **Requires:** Holding back copyleft code until we agree on a license for the foreseeable future. ### No locked license version Some contributors feared that choosing -only license variants over -or-later would lock us to a version that does not reflect changes in jurisdiction around the earth. -or-later variants allow for the license creators to publish updated versions that address legal issues with the past license text. **Impact:** Unknown, depends on external factors. **Benefit:** Unknown, too. Choosing upgradable licenses likely mean Forgejo is safer for the (very) long-term future, but it might not matter on a horizon of 10 to 20 years. --- There are also contra positions to some of the above, namely: - go ahead quickly to allow copyleft code (works against "Avoid license changes in succession", "License clarity for end-users") - do not limit the possibility for proprietary SaaS (works against "No proprietary SaaS" and partially against "Including copyleft dependencies", too) - freeze license versions (obviously works against "No locked license version")

n0toose commented 2024年07月30日 14:33:32 +02:00

Great job with the summary, I think it could use or expand upon the following:

• contributors agree on "copyleft is fine, but are explicitly concerned about or-later"
  • potential consequences during litigation (venue or competent court, translation) (contributors, briefly mentioned already)
• linking (end users, there's a difference between the EUPL and the GPL in that regard and the EUPL people claim to explicitly exclude APIs)
• compatibility with other licenses (end users, contributors)
• potential of licensing specific components (e.g. tests) under more specific licenses (end users, contributors)

Resources:

• https://joinup.ec.europa.eu/collection/eupl/news/eupl-or-gplv3-comparison-t (super biased)

I'd be interested in seeing how the GPL-2.0 violations were described, proven or disproven, but I can't speak French and don't know where to find the documents:

• https://www.dlapiper.com/en/insights/publications/2024/03/wakeup-call-for-open-source-users-french-court-awards-damages-for-gpl-violations
• https://joinup.ec.europa.eu/collection/eupl/news/gpl-20-facing-court-ruling-paris

Great job with the summary, I think it could use or expand upon the following: - contributors agree on "copyleft is fine, but are explicitly concerned about `or-later`" - potential consequences during litigation (venue or competent court, translation) (contributors, briefly mentioned already) - linking (end users, there's a difference between the EUPL and the GPL in that regard and the EUPL people claim to explicitly exclude APIs) - compatibility with other licenses (end users, contributors) - potential of licensing specific components (e.g. tests) under more specific licenses (end users, contributors) Resources: - https://joinup.ec.europa.eu/collection/eupl/news/eupl-or-gplv3-comparison-t (super biased) I'd be interested in seeing how the GPL-2.0 violations were described, proven or disproven, but I can't speak French and don't know where to find the documents: - https://www.dlapiper.com/en/insights/publications/2024/03/wakeup-call-for-open-source-users-french-court-awards-damages-for-gpl-violations - https://joinup.ec.europa.eu/collection/eupl/news/gpl-20-facing-court-ruling-paris

alex19srv commented 2024年08月05日 17:00:35 +02:00

IMHO, LGPLv3+ is better choice even for application. Because LGPL code also can't be closed or "relicensed". And it can be copy-pasted to other LGPL project. You can't copy-paste GPL code to LGPL project because GPL have more strict restrictions then LGPL.

IMHO, LGPLv3+ is better choice even for application. Because LGPL code also can't be closed or "relicensed". And it can be copy-pasted to other LGPL project. You can't copy-paste GPL code to LGPL project because GPL have more strict restrictions then LGPL.

0ko commented 2024年08月05日 18:02:51 +02:00

In my understanding, SAAS can be a form of source closure and relicensing, from which LGPL and GPL do not protect. Only AGPL does.

In my understanding, SAAS can be a form of source closure _and relicensing_, from which LGPL and GPL do not protect. Only AGPL does.

caesar commented 2024年08月05日 22:52:01 +02:00

Only AGPL does.

And maybe EUPL (depending on how you interpret the license compatibility clause).

> Only AGPL does. And maybe EUPL (depending on how you interpret the license compatibility clause).

earl-warren commented 2024年08月22日 11:10:00 +02:00

Revisiting @fnetX summary now that Forgejo license was upgraded to GPLv3+, I would like to continue the discussion on the following three items:

---

No proprietary SaaS

Someone could go ahead and create a proprietary SaaS offering without disclosing Forgejo. It could even be white-labelled.
Impact: High, it requires service providers currently looking into Forgejo not to build a business model on proprietary code, but to disclose all their work as free software. Given Allspice exists based on Gitea, chances for this are real. It also has an impact on everyone who patches Forgejo slightly and requires publishing the patches, too.
Benefit: Such service providers might not be Forgejo customers and might reduce our development power and financial contribution. On the other hand, it is a positive change for users, because they cannot get locked in by proprietary offerings, and any service provider would need to work on Forgejo as free/libre software only.
Requires: AGPLv3-only, -or-later or EUPLv1.2

I think Forgejo is still a long way from needing such legal protection. But given that licensing discussions are long and that introducing this would have a high impact on Forgejo users and admins, I agree that now is the time to prepare for it.

• Legal: I think AGPLv3-or-later is a sound and simple choice that is future proof. Sound because it has been scrutinized for many years by a large amount of people, is used in a large number of software. Simple because the path to upgrading from GPLv3-or-later is laid out and does not require legal consultation from a lawyer and/or explicit permission from the authors of GPLv3-or-later copyright holders. Future proof because it allows for a license upgrade in a decade or two from now, should it become necessary because copyright law changed or new ways of turning copyleft software into proprietary software are invented. None of this is hard fact: there are pros and cons: I believe the pros outweigh the cons and I fully expect this will fuel a very long debate.
• Adoption: Some companies are fiercely opposed to AGPL and what it stands for. Switching to AGPL will mean they will turn away from Forgejo. I believe this is not a loss for Forgejo because the very reason they are opposed to AGPL is because they refuse to share alike. It would be a loss if they agreed to share alike and stopped contributing to Forgejo. This again will be a matter of long debates.

License clarity for end-users

Copyleft licenses are usually much longer and harder to understand for end-users. It was argued that the EUPL is easier to understand and it has the benefit of having official translations in many more languages.
Impact: ?
Benefit: Forgejo users are more likely to accept the change.
Requires: EUPLv1.2

I object that EUPL or AGPL are understandable by anyone without a strong legal expertise. The tiniest of detail may have an impact that can only be fully understood with a background in international copyright law. The benefit of the existing Free Software licenses is that they have been vetted and are known to not get people in trouble. Choosing them does not require consulting with a lawyer. Understanding them... that's another challenge altogether.

No inspiration without credits

There have been cases reported where code was surprisingly similar to code written for Forgejo, without copyright. While the MIT license already prevents this, it is harder to enforce in practice, because consequences are low (naming the original author is enough). Copyleft licenses discourage people to copy code, because if it is discovered, it would mean the code must be removed / rewritten in a different way, and versions containing it would need to change license to copyleft in addition to naming the original author.
Impact: Low for end-users, but high for others getting inspired by Forgejo without credit.
Benefit: Since such cases were claimed, it is likely they would be prevented.
Requires: any copyleft license.

I think this is a different subject: plagiarism, which is what happens when an original work is imitated in a certain way.

For instance if Forgejo was to implement audit logs in a way that is similar but not identical to what Gitea has, it could be a case of plagiarism. When and if that is demonstrated to be true, the legal implications depend on the copyright under which the work was distributed by the author of the original work. Since the license of the Gitea patch is MIT, stripping out the author of the patch is not allowed. But if the author is credited under the MIT license, although there is a case of plagiarism, there may not be any way for the author to claim that it is not authorized under copyright law.

That's just scratching the surface and my point is that is starts with plagiarism before copyright is in play and it is a different discussion.

Revisiting @fnetX summary now that [Forgejo license was upgraded to GPLv3+](https://codeberg.org/forgejo/discussions/issues/201), I would like to continue the discussion on the following three items: --- > ### No proprietary SaaS > > Someone could go ahead and create a proprietary SaaS offering without disclosing Forgejo. It could even be white-labelled. > **Impact:** High, it requires service providers currently looking into Forgejo not to build a business model on proprietary code, but to disclose all their work as free software. Given [Allspice](https://allspice.io/) exists based on Gitea, chances for this are real. It also has an impact on everyone who patches Forgejo slightly and requires publishing the patches, too. > **Benefit:** Such service providers might not be Forgejo customers and might reduce our development power and financial contribution. On the other hand, it is a positive change for users, because they cannot get locked in by proprietary offerings, and any service provider would need to work on Forgejo as free/libre software only. > **Requires:** AGPLv3-only, -or-later or EUPLv1.2 I think Forgejo is still a long way from needing such legal protection. But given that licensing discussions are long and that introducing this would have a high impact on Forgejo users and admins, I agree that now is the time to prepare for it. * Legal: I think AGPLv3-or-later is a sound and simple choice that is future proof. Sound because it has been scrutinized for many years by a large amount of people, is used in a large number of software. Simple because the path to upgrading from GPLv3-or-later is laid out and does not require legal consultation from a lawyer and/or explicit permission from the authors of GPLv3-or-later copyright holders. Future proof because it allows for a license upgrade in a decade or two from now, should it become necessary because copyright law changed or new ways of turning copyleft software into proprietary software are invented. None of this is hard fact: there are pros and cons: I believe the pros outweigh the cons and I fully expect this will fuel a very long debate. * Adoption: Some companies are fiercely opposed to AGPL and what it stands for. Switching to AGPL will mean they will turn away from Forgejo. I believe this is not a loss for Forgejo because the very reason they are opposed to AGPL is because they refuse to share alike. It would be a loss if they agreed to share alike and stopped contributing to Forgejo. This again will be a matter of long debates. > ### License clarity for end-users > > Copyleft licenses are usually much longer and harder to understand for end-users. It was argued that the EUPL is easier to understand and it has the benefit of having official translations in many more languages. > **Impact:** ? > **Benefit:** Forgejo users are more likely to accept the change. > **Requires:** EUPLv1.2 I object that EUPL or AGPL are understandable by anyone without a strong legal expertise. The tiniest of detail may have an impact that can only be fully understood with a background in international copyright law. The benefit of the existing Free Software licenses is that they have been vetted and are known to not get people in trouble. Choosing them does not require consulting with a lawyer. Understanding them... that's another challenge altogether. > ### No inspiration without credits > > There have been cases reported where code was surprisingly similar to code written for Forgejo, without copyright. While the MIT license already prevents this, it is harder to enforce in practice, because consequences are low (naming the original author is enough). Copyleft licenses discourage people to copy code, because if it is discovered, it would mean the code must be removed / rewritten in a different way, and versions containing it would need to change license to copyleft in addition to naming the original author. > **Impact:** Low for end-users, but high for others getting inspired by Forgejo without credit. > **Benefit:** Since such cases were claimed, it is likely they would be prevented. > **Requires:** any copyleft license. I think this is a different subject: [plagiarism](https://en.wikipedia.org/wiki/Plagiarism), which is what happens when an original work is imitated in a certain way. For instance if Forgejo was to implement audit logs in a way that is similar but not identical to what Gitea has, it could be a case of plagiarism. When and if that is demonstrated to be true, the legal implications depend on the copyright under which the work was distributed by the author of the original work. Since the license of the Gitea patch is MIT, stripping out the author of the patch is not allowed. But if the author is credited under the MIT license, although there is a case of plagiarism, there may not be any way for the author to claim that it is not authorized under copyright law. That's just scratching the surface and my point is that is starts with plagiarism before copyright is in play and it is a different discussion.

Ghost commented 2024年08月22日 12:20:10 +02:00

First of all - in my understanding EUPL is now no longer an option due to GPLv3+ being allowed in the codebase. Combining the two into an outbound EUPLv1.2 license is impossible.

If a legal advice in needed I suggest contacting joinup program: https://joinup.ec.europa.eu/contact

---

Adoption: Some companies are fiercely opposed to AGPL and what it stands for. Switching to AGPL will mean they will turn away from Forgejo. I believe this is not a loss for Forgejo because the very reason they are opposed to AGPL is because they refuse to share alike. It would be a loss if they agreed to share alike and stopped contributing to Forgejo. This again will be a matter of long debates.

Is there even a case of such entity currently? There's not much point in worrying about non-existent companies not contributing to Forgejo because of AGPL branding.

First of all - in my understanding EUPL is now no longer an option due to GPLv3+ being allowed in the codebase. Combining the two into an outbound EUPLv1.2 license is impossible. If a legal advice in needed I suggest contacting joinup program: https://joinup.ec.europa.eu/contact --- > Adoption: Some companies are fiercely opposed to AGPL and what it stands for. Switching to AGPL will mean they will turn away from Forgejo. I believe this is not a loss for Forgejo because the very reason they are opposed to AGPL is because they refuse to share alike. It would be a loss if they agreed to share alike and stopped contributing to Forgejo. This again will be a matter of long debates. Is there even a case of such entity currently? There's not much point in worrying about non-existent companies not contributing to Forgejo because of AGPL branding.

Ryuno-Ki commented 2024年08月22日 12:34:59 +02:00

If a legal advice in needed I suggest contacting joinup program: https://joinup.ec.europa.eu/contact

There's also the option to use a Support Service for grantees.
„Copyright and license due diligence".

Last year there was a case for Entrust. I can't see a replication in the sustainability repo at the moment.

> If a legal advice in needed I suggest contacting joinup program: https://joinup.ec.europa.eu/contact There's also the option to use a [Support Service](https://nlnet.nl/NGI0/services/) for grantees. „Copyright and license due diligence". Last year there was a case for Entrust. I can't see a replication in the sustainability repo at the moment.

mahlzahn commented 2024年08月22日 14:07:57 +02:00

First of all - in my understanding EUPL is now no longer an option due to GPLv3+ being allowed in the codebase. Combining the two into an outbound EUPLv1.2 license is impossible.

This seems to be true also to my understanding. See https://joinup.ec.europa.eu/collection/eupl/matrix-eupl-compatible-open-source-licences#section-2. Still EUPL-1.2 code could be included (see downstream compatibility) if GPL/AGPL license would be restricted to v3.0 only.

So, I think that we’re left with the four options

• GPL-3.0-only (would allow EUPL-1.2 and GPL-3.0-only contributions)
• GPL-3.0-or-later (currently agreed on)
• AGPL-3.0-only (would allow EUPL-1.2, GPL-3.0-only and AGPL-3.0-only contributions)
• AGPL-3.0-or-later

and with two main questions:

1. Do we want to close the SaaS loophole with its implications? If yes, choose AGPL.
2. Do we want to allow EUPL-1.2, GPL-3.0-only and possibly AGPL-3.0-only contributions? If yes, restrict to v3.0 only.

I personally don’t see another reason, but possibly there could be other concerns to restrict to v3.0 only.

Edit: clarified possible inclusion of GPL/AGPL-3.0-only contributions

> First of all - in my understanding EUPL is now no longer an option due to GPLv3+ being allowed in the codebase. Combining the two into an outbound EUPLv1.2 license is impossible. This seems to be true also to my understanding. See https://joinup.ec.europa.eu/collection/eupl/matrix-eupl-compatible-open-source-licences#section-2. Still EUPL-1.2 code could be included (see [downstream compatibility](https://joinup.ec.europa.eu/collection/eupl/matrix-eupl-compatible-open-source-licences#section-4)) if GPL/AGPL license would be restricted to v3.0 only. So, I think that we’re left with the four options - GPL-3.0-only (would allow EUPL-1.2 and GPL-3.0-only contributions) - **GPL-3.0-or-later** (currently agreed on) - AGPL-3.0-only (would allow EUPL-1.2, GPL-3.0-only and AGPL-3.0-only contributions) - AGPL-3.0-or-later and with two main questions: 1. Do we want to close the SaaS loophole with its implications? If yes, choose AGPL. 2. Do we want to allow EUPL-1.2, GPL-3.0-only and possibly AGPL-3.0-only contributions? If yes, restrict to v3.0 only. I personally don’t see another reason, but possibly there could be other concerns to restrict to v3.0 only. Edit: clarified possible inclusion of GPL/AGPL-3.0-only contributions

Ghost commented 2024年08月22日 14:22:50 +02:00

Worth noting that EUPL has the "or later" version as well. However it is not listed in spdx.

Worth noting that EUPL has the "or later" version as well. However it is not listed in spdx.

Ryuno-Ki commented 2024年08月22日 14:26:33 +02:00

Those two main questions could be addressed with AGPL-3.0-only if I read the list correctly.

There's an upgrade path from -only to -or-later?
Assuming no EUPL-1.2 contributions happened.

Those two main questions could be addressed with AGPL-3.0-only if I read the list correctly. There's an upgrade path from -only to -or-later? Assuming no EUPL-1.2 contributions happened.

mahlzahn commented 2024年08月22日 14:35:12 +02:00

Those two main questions could be addressed with AGPL-3.0-only if I read the list correctly.

Exactly, if we answer both questions with yes, then AGPL-3.0-only should be the choice.

There's an upgrade path from -only to -or-later?
Assuming no EUPL-1.2 contributions happened.

No, that would require each contributor of GPL/AGPL-3.0-only code to agree on this change.

> Those two main questions could be addressed with AGPL-3.0-only if I read the list correctly. Exactly, if we answer both questions with yes, then AGPL-3.0-only should be the choice. > There's an upgrade path from -only to -or-later? > Assuming no EUPL-1.2 contributions happened. No, that would require each contributor of GPL/AGPL-3.0-only code to agree on this change.

Ghost commented 2024年08月22日 14:36:05 +02:00

No there is not.
AGPL3+ would have the following set of licenses (AGPL3, AGPL4,....)
AGPL3 would have (AGPL3)
Shared base is AGPL3 only.

EUPL doesn't come even into equation here.

The only relicense path is either:

• CLA to be able to relicense code
• Contacting all contributors which submitted code under AGPL3 and asking if it would be possible to extend compatibility

No there is not. AGPL3+ would have the following set of licenses (AGPL3, AGPL4,....) AGPL3 would have (AGPL3) Shared base is AGPL3 only. EUPL doesn't come even into equation here. The only relicense path is either: - CLA to be able to relicense code - Contacting all contributors which submitted code under AGPL3 and asking if it would be possible to extend compatibility

recursive_recursion commented 2024年08月22日 15:03:34 +02:00

Apologies for intruding, I'd like to ask:

If the AGPL-3.0-or-later license were to be accepted by all contributors, wouldn't future upgrades/revisions be possible due to the prior discussion was had at the time of agreement?

This means that so long as all contributors agree on licensing under AGPL-3.0-or-later it should mean that a fork would be required in new situations for relicensing without needing reapproval from the previous contributors (for better or for worse). I could be wrong about this

Apologies for intruding, I'd like to ask: If the AGPL-3.0-or-later license were to be accepted by all contributors, wouldn't future upgrades/revisions be possible due to the prior discussion was had at the time of agreement? This means that so long as all contributors agree on licensing under AGPL-3.0-or-later it should mean that a fork would be required in new situations for relicensing without needing reapproval from the previous contributors (for better or for worse). I could be wrong about this

bramh commented 2024年08月22日 15:49:06 +02:00

Perhaps a bit redundant, but here's a table showing the possible resulting licenses when combining GPLv3+ with MIT, GPLv3(+), AGPLv3(+) and EUPL:

My contribution is licensed under	Forgejo's license becomes (choose one)
MIT	GPL-3.0-or-later, GPL-3.0-only, AGPL-3.0-or-later, AGPL-3.0-only
GPL-3.0-or-later	GPL-3.0-or-later, GPL-3.0-only, AGPL-3.0-or-later, AGPL-3.0-only
GPL-3.0-only	GPL-3.0-only, AGPL-3.0-only
AGPL-3.0-or-later	AGPL-3.0-or-later, AGPL-3.0-only
AGPL-3.0-only	AGPL-3.0-only
EUPL-1.2	GPL-3.0-only, AGPL-3.0-only

Also, a compatibility matrix between the licenses:

Allowed contributions (->) Forgejo license (↓)	MIT	GPL-3.0-or-later	GPL-3.0-only	AGPL-3.0-or-later	AGPL-3.0-only	EUPL-1.2
GPL-3.0-or-later	✅	✅	❌	❌	❌	❌
GPL-3.0-only	✅	✅	✅	❌	❌	✅
AGPL-3.0-or-later	✅	✅	❌	✅	❌	❌
AGPL-3.0-only	✅	✅	✅	✅	✅	✅

---

<sub>I am not a lawyer, this is my own interpretation of the following sources:
1. https://www.gnu.org/licenses/license-list.html
2. https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility
3. https://joinup.ec.europa.eu/sites/default/files/custom-page/attachment/2020-03/EUPL-1.2%20EN.txt</sub>

Perhaps a bit redundant, but here's a table showing the possible resulting licenses when combining GPLv3+ with MIT, GPLv3(+), AGPLv3(+) and EUPL: | My contribution is<br>licensed under | Forgejo's license becomes (choose one) | |-------------------|------------------------------------------------------------------| | MIT | GPL-3.0-or-later, GPL-3.0-only,<br>AGPL-3.0-or-later, AGPL-3.0-only | | GPL-3.0-or-later | GPL-3.0-or-later, GPL-3.0-only,<br>AGPL-3.0-or-later, AGPL-3.0-only | | GPL-3.0-only | GPL-3.0-only,<br>AGPL-3.0-only | | AGPL-3.0-or-later | AGPL-3.0-or-later, AGPL-3.0-only | | AGPL-3.0-only | AGPL-3.0-only | | EUPL-1.2 | GPL-3.0-only,<br>AGPL-3.0-only | Also, a compatibility matrix between the licenses: | Allowed contributions (->)<br>Forgejo license (↓) | MIT | GPL-3.0-or-later | GPL-3.0-only | AGPL-3.0-or-later | AGPL-3.0-only | EUPL-1.2 | |---------------------------------------|-----|------------------|--------------|-------------------|---------------|----------| | GPL-3.0-or-later | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ | | GPL-3.0-only | ✅ | ✅ | ✅ | ❌ | ❌ | ✅ | | AGPL-3.0-or-later | ✅ | ✅ | ❌ | ✅ | ❌ | ❌ | | AGPL-3.0-only | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | --- _{I am not a lawyer, this is my own interpretation of the following sources: 1\. https://www.gnu.org/licenses/license-list.html 2. https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility 3. https://joinup.ec.europa.eu/sites/default/files/custom-page/attachment/2020-03/EUPL-1.2%20EN.txt}

bramh commented 2024年08月22日 15:59:20 +02:00

Apologies for intruding, I'd like to ask:

If the AGPL-3.0-or-later license were to be accepted by all contributors, wouldn't future upgrades/revisions be possible due to the prior discussion was had at the time of agreement?

This means that so long as all contributors agree on licensing under AGPL-3.0-or-later it should mean that a fork would be required in new situations for relicensing without needing reapproval from the previous contributors (for better or for worse). I could be wrong about this

There are two licenses involved: the license of the Forgejo source code and the license under which the contributor decides to publish their contributions.

Forgejo's license can be changed somewhat freely, as long as it is compatible with all licenses used by the contributors. Currently, those are MIT and GPL-3.0-or-later, meaning that any of the following licenses would be possible: GPL-3.0-or-later, GPL-3.0-only, AGPL-3.0-or-later, AGPL-3.0-only. If an AGPL-3.0-or-later contribution was added, the possible options would become AGPL-3.0-or-later, AGPL-3.0-only. There is no consent needed from the contributors for this.

The license of an individual contribution can only be changed if you have the contributor's consent (or the nuclear option: removing their contribution altogether). You cannot simply create a fork under a non-compatible license (say, go back to MIT). You will need their consent or remove their code. This is the case for all licenses, not just AGPL.

> Apologies for intruding, I'd like to ask: > > If the AGPL-3.0-or-later license were to be accepted by all contributors, wouldn't future upgrades/revisions be possible due to the prior discussion was had at the time of agreement? > > This means that so long as all contributors agree on licensing under AGPL-3.0-or-later it should mean that a fork would be required in new situations for relicensing without needing reapproval from the previous contributors (for better or for worse). I could be wrong about this There are two licenses involved: the license of the Forgejo source code and the license under which the contributor decides to publish their contributions. Forgejo's license can be changed somewhat freely, as long as it is compatible with all licenses used by the contributors. Currently, those are MIT and GPL-3.0-or-later, meaning that any of the following licenses would be possible: `GPL-3.0-or-later, GPL-3.0-only, AGPL-3.0-or-later, AGPL-3.0-only`. If an AGPL-3.0-or-later contribution was added, the possible options would become `AGPL-3.0-or-later, AGPL-3.0-only`. There is no consent needed from the contributors for this. The license of an individual contribution can only be changed if you have the contributor's consent (or the nuclear option: removing their contribution altogether). You cannot simply create a fork under a non-compatible license (say, go back to MIT). You will need their consent or remove their code. This is the case for all licenses, not just AGPL.

recursive_recursion commented 2024年08月22日 16:39:02 +02:00

Apologies for intruding, I'd like to ask:

If the AGPL-3.0-or-later license were to be accepted by all contributors, wouldn't future upgrades/revisions be possible due to the prior discussion was had at the time of agreement?

This means that so long as all contributors agree on licensing under AGPL-3.0-or-later it should mean that a fork would be required in new situations for relicensing without needing reapproval from the previous contributors (for better or for worse). I could be wrong about this

There are two licenses involved: the license of the Forgejo source code and the license under which the contributor decides to publish their contributions.

Forgejo's license can be changed somewhat freely, as long as it is compatible with all licenses used by the contributors. Currently, those are MIT and GPL-3.0-or-later, meaning that any of the following licenses would be possible: GPL-3.0-or-later, GPL-3.0-only, AGPL-3.0-or-later, AGPL-3.0-only. If an AGPL-3.0-or-later contribution was added, the possible options would become AGPL-3.0-or-later, AGPL-3.0-only. There is no consent needed from the contributors for this.

The license of an individual contribution can only be changed if you have the contributor's consent (or the nuclear option: removing their contribution altogether). You cannot simply create a fork under a non-compatible license (say, go back to MIT). You will need their consent or remove their code. This is the case for all licenses, not just AGPL.

Sorry let me clarify my previous statement:

What I mean to get at was that:
If AGPL-3.0-only was chosen it'd make relicensing harder down the line (consent would be required in order to relicense here) which might unfortunately be required if another loophole like ASP is discovered later in the future.

By selecting AGPL-3.0-only is to potentially have a singular permanent timeline, whereas AGPL-3.0-or-later provides the potential to create alternative branching paths (compatible with the AGPL version that is available at the time) hopping from AGPL-3.0-or-later to AGPL-#.#-or-later (can be visualized as multiverse timelines).

> > Apologies for intruding, I'd like to ask: > > > > If the AGPL-3.0-or-later license were to be accepted by all contributors, wouldn't future upgrades/revisions be possible due to the prior discussion was had at the time of agreement? > > > > This means that so long as all contributors agree on licensing under AGPL-3.0-or-later it should mean that a fork would be required in new situations for relicensing without needing reapproval from the previous contributors (for better or for worse). I could be wrong about this > > There are two licenses involved: the license of the Forgejo source code and the license under which the contributor decides to publish their contributions. > > Forgejo's license can be changed somewhat freely, as long as it is compatible with all licenses used by the contributors. Currently, those are MIT and GPL-3.0-or-later, meaning that any of the following licenses would be possible: `GPL-3.0-or-later, GPL-3.0-only, AGPL-3.0-or-later, AGPL-3.0-only`. If an AGPL-3.0-or-later contribution was added, the possible options would become `AGPL-3.0-or-later, AGPL-3.0-only`. There is no consent needed from the contributors for this. > > The license of an individual contribution can only be changed if you have the contributor's consent (or the nuclear option: removing their contribution altogether). You cannot simply create a fork under a non-compatible license (say, go back to MIT). You will need their consent or remove their code. This is the case for all licenses, not just AGPL. > > > > Sorry let me clarify my previous statement: What I mean to get at was that: If AGPL-3.0-only was chosen it'd make relicensing harder down the line (consent would be required in order to relicense here) which might unfortunately be required if another loophole like ASP is discovered later in the future. By selecting AGPL-3.0-only is to potentially have a singular permanent timeline, whereas AGPL-3.0-or-later provides the potential to create alternative branching paths (compatible with the AGPL version that is available at the time) hopping from AGPL-3.0-or-later to AGPL-#.#-or-later (can be visualized as multiverse timelines).

amano.kenji commented 2024年10月22日 11:08:51 +02:00

I recommend 0BSD which is a public-domain equivalent license.

Copyleft is a form of copyright. All forms of copyright deter collaboration. For example, GPLv2 software cannot be mixed with GPLv3 software. CDDL cannot be mixed with GPL.

Linus torvalds cursed GPLv3 for being incompatible with GPLv2.

Software copyright is a dead end because it is a legal fiction that doesn't exist in nature. If you create a fiction where there is none, there will be resistance to progress. In other words, copyright isn't real. It is a man-made illusion. It is not a force of nature like gravity.

Public domain will help open-source projects move faster than proprietary software companies because proprietary software companies will be slowed down by suing each other for infringing upon each other's software copyright. For example, Oracle sued google for using java on android. Even BSD licenses led to lawsuits between software companies. This BSD lawsuit was the rocket fuel that linux needed to go into the orbit.

While companies have many billion dollars to blow through arbitrary man-made legal fiction with lawyers, open-source projects are mostly led by poor developers who own nothing. Canonical is able to just ship ZFS kernel module binaries because they have enough money to pay lawyers. If you have enough money or power, copyright isn't real. Copyright is a lawfare weapon for people who have money and power.

Arbitrary man-made fictions like copyright and patent make sure only rich people can afford usage of information. That means man-made fictions make the rich richer and the poor poorer. You don't have money to pay lawyers? Then, you can't ship ZFS kernel module binaries. If you obey nature, you will prosper. If you don't, hell breaks loose. If you try to disobey gravity and jump off a building, you will not prosper. Your collective belief in intellectual property which doesn't exist in nature is making you poorer and poorer over time because you are disobeying nature where information belongs to everyone and you own only your own physical copies of information.

The rich and smart know copyright isn't real and wield it as a weapon or ignore it.

Even now, what are you doing? You are wasting precious time on comparing software licenses. I just slapped 0BSD on my software projects and forgot about copyright altogether. I saved time. I win. Time is more valuable than money which can be replenished.

Let's just drop copyright, and move faster without money than multi-billion dollar software companies.

I recommend 0BSD which is a public-domain equivalent license. Copyleft is a form of copyright. All forms of copyright deter collaboration. For example, GPLv2 software cannot be mixed with GPLv3 software. CDDL cannot be mixed with GPL. Linus torvalds cursed GPLv3 for being incompatible with GPLv2. Software copyright is a dead end because it is a legal fiction that doesn't exist in nature. If you create a fiction where there is none, there will be resistance to progress. In other words, copyright isn't real. It is a man-made illusion. It is not a force of nature like gravity. Public domain will help open-source projects move faster than proprietary software companies because proprietary software companies will be slowed down by suing each other for infringing upon each other's software copyright. For example, Oracle sued google for using java on android. Even BSD licenses led to lawsuits between software companies. This BSD lawsuit was the rocket fuel that linux needed to go into the orbit. While companies have many billion dollars to blow through arbitrary man-made legal fiction with lawyers, open-source projects are mostly led by poor developers who own nothing. Canonical is able to just ship ZFS kernel module binaries because they have enough money to pay lawyers. If you have enough money or power, copyright isn't real. Copyright is a lawfare weapon for people who have money and power. Arbitrary man-made fictions like copyright and patent make sure only rich people can afford usage of information. That means man-made fictions make the rich richer and the poor poorer. You don't have money to pay lawyers? Then, you can't ship ZFS kernel module binaries. If you obey nature, you will prosper. If you don't, hell breaks loose. If you try to disobey gravity and jump off a building, you will not prosper. Your collective belief in intellectual property which doesn't exist in nature is making you poorer and poorer over time because you are disobeying nature where information belongs to everyone and you own only your own physical copies of information. The rich and smart know copyright isn't real and wield it as a weapon or ignore it. Even now, what are you doing? You are wasting precious time on comparing software licenses. I just slapped 0BSD on my software projects and forgot about copyright altogether. I saved time. I win. Time is more valuable than money which can be replenished. Let's just drop copyright, and move faster without money than multi-billion dollar software companies.

Ghost commented 2024年10月22日 12:52:55 +02:00

While I agree that copyright isn't the greatest tool ever and it is man-made concept - it does exist.
Picking 0BSD as a main license now is impossible unless contributors who committed code under GPLv3-or-later would change it. This is the case with every license considered now except AGPL.
I also don't see the relation between moving faster and no copyright. It's not like development gets faster because the product has no copyright (impossible as it might be). Suing example you provided doesn't convince me at any point as one can just choose not to sue when they don't have to and usage of 0BSD doesn't protect from lawsuit. Also it's not the developers that would handle such lawsuit. Could you maybe elaborate on that?

While I agree that copyright isn't the greatest tool ever and it is man-made concept - it does exist. Picking 0BSD as a main license now is impossible unless contributors who committed code under GPLv3-or-later would change it. This is the case with every license considered now except AGPL. I also don't see the relation between moving faster and no copyright. It's not like development gets faster because the product has no copyright (impossible as it might be). Suing example you provided doesn't convince me at any point as one can just choose not to sue when they don't have to and usage of 0BSD doesn't protect from lawsuit. Also it's not the developers that would handle such lawsuit. Could you maybe elaborate on that?

fnetX commented 2024年10月22日 13:48:39 +02:00

I think that 0BSD was never possible for Forgejo, because of the inherited MIT codebase.

@amano.kenji but you are more than welcome developing 0BSD parts for the Forgejo ecosystem such as installers, third-party clients (e.g. cli or mobile) and much more.

I think that 0BSD was never possible for Forgejo, because of the inherited MIT codebase. @amano.kenji but you are more than welcome developing 0BSD parts for the Forgejo ecosystem such as installers, third-party clients (e.g. cli or mobile) and much more.

amano.kenji commented 2024年10月22日 16:00:58 +02:00

Picking 0BSD as a main license now is impossible unless contributors who committed code under GPLv3-or-later would change it.

This is what I was talking about. People's collective belief in copyright slows down projects that already adopted copyright licenses. This project has already been checkmated. It's too late for this project, but people can consider 0BSD for new projects.

I also don't see the relation between moving faster and no copyright. It's not like development gets faster because the product has no copyright (impossible as it might be). Suing example you provided doesn't convince me at any point as one can just choose not to sue when they don't have to and usage of 0BSD doesn't protect from lawsuit.

If more people collectively adopt the mindset that comes along with 0BSD, the collective will increasingly have less friction over time. Less lawsuit. Less friction(linux kernel will absorb ZFS and other open-source projects will absorb linux if there is no friction). People will be collectively faster.

If you use 0BSD for a new project, it will make other projects using it freer from legal complications that slow people down. It's not about protecting project authors in the immediate future. It's about leaving other people using your software projects alone. If everybody generally leaves other people alone, we will be collectively far freer. I want to increase collective freedom. Without collective freedom, you can't have your personal freedom.

Lack of arbitrary man-made rules will create optimal condition for evolution of human species. I want evolution. Obey natural laws for evolution and prosperity.

> Picking 0BSD as a main license now is impossible unless contributors who committed code under GPLv3-or-later would change it. This is what I was talking about. People's collective belief in copyright slows down projects that already adopted copyright licenses. This project has already been checkmated. It's too late for this project, but people can consider 0BSD for new projects. > I also don't see the relation between moving faster and no copyright. It's not like development gets faster because the product has no copyright (impossible as it might be). Suing example you provided doesn't convince me at any point as one can just choose not to sue when they don't have to and usage of 0BSD doesn't protect from lawsuit. If more people collectively adopt the mindset that comes along with 0BSD, the collective will increasingly have less friction over time. Less lawsuit. Less friction(linux kernel will absorb ZFS and other open-source projects will absorb linux if there is no friction). People will be collectively faster. If you use 0BSD for a new project, it will make other projects using it freer from legal complications that slow people down. It's not about protecting project authors in the immediate future. It's about leaving other people using your software projects alone. If everybody generally leaves other people alone, we will be collectively far freer. I want to increase collective freedom. Without collective freedom, you can't have your personal freedom. Lack of arbitrary man-made rules will create optimal condition for evolution of human species. I want evolution. Obey natural laws for evolution and prosperity.

pasabanov commented 2024年12月08日 02:12:09 +01:00

I recommend 0BSD which is a public-domain equivalent license.

0BSD is pure evil. Almost as bad as a proprietary license, if not worse.

0BSD is even worse than MIT because, unlike the latter, it doesn't require attribution.

Thus, 0BSD not only puts open source in a vulnerable position by allowing anyone to take the code and release it under a proprietary license, but it doesn't even protect developers' right to attribution!

I wouldn't recommend using this license to anyone who values themselves, their time, and their effort.

> I recommend 0BSD which is a public-domain equivalent license. 0BSD is pure evil. Almost as bad as a proprietary license, if not worse. 0BSD is even worse than MIT because, unlike the latter, it doesn't require attribution. Thus, 0BSD not only puts open source in a vulnerable position by allowing anyone to take the code and release it under a proprietary license, but it doesn't even protect developers' right to attribution! I wouldn't recommend using this license to anyone who values themselves, their time, and their effort.

pasabanov commented 2024年12月08日 02:14:31 +01:00

I want to share my thoughts on GPL and AGPL.

In my opinion, if you choose GPL for your project, there is no reason not to choose AGPL, because all AGPL does is close the loophole in GPL that dishonest parties can exploit to bypass the license terms.

I believe that to protect your work and open-source software in general, it is always best to choose the most restrictive copyleft licenses, as long as their restrictiveness does not contradict the goals of the project. In the case of GPL and AGPL, I see no reason not to choose the latter.

I also noticed discussions here claiming that AGPL is incompatible with GPL, but I don't see how that could be a drawback, because I don't see any reason to change the license from AGPL to GPL.

I want to share my thoughts on GPL and AGPL. In my opinion, if you choose GPL for your project, there is no reason not to choose AGPL, because all AGPL does is close the loophole in GPL that dishonest parties can exploit to bypass the license terms. I believe that to protect your work and open-source software in general, it is always best to choose the most restrictive copyleft licenses, as long as their restrictiveness does not contradict the goals of the project. In the case of GPL and AGPL, I see no reason not to choose the latter. I also noticed discussions here claiming that AGPL is incompatible with GPL, but I don't see how that could be a drawback, because I don't see any reason to change the license from AGPL to GPL.

amano.kenji commented 2024年12月08日 03:20:14 +01:00

In nature, nobody owns information. Information belongs to everyone. If people stop believing in intellectual property, all software licenses will stop functioning. Licensing on access to information is evil.

What's evil is intellectual property which claims ownership over other people's physical copies of information.

In the physical universe, there's only physical property ownership. That means our bodies are our physical properties. If you dictate what other people can do with their physical copies of information, you are indirectly claiming ownership over their physical bodies because you are dictating what people can do with their bodies although they are not initiating harm on other people's physical properties and they are not stealing access to information from anyone else through deception. Laying claims on other people's bodies or their physical properties is called slavery.

Slavery is evil. God hates slavery. God just lets humans enslave or kill each other because God hates those who believe in slavery. Abandonment is God's revenge. God will only come back and help in some form if we collectively stop believing in slavery.

There are many forms of slavery. Chattel slavery is a form of overt slavery. Covert forms of slavery are still prevalent on earth. Indirect claims upon our bodies through our fruits of labor and our physical properties are covert slavery.

You have two choices. Rule in hell. Serve in heaven. Earth has been hell for at least a few thousand years.

While I agree that GPL is a lesser evil than EULA, we shouldn't strive to choose a king that whips us more humanely. GPL may whip you more humanely than EULA, but it is still evil. We should oppose evil instead of choosing a lesser evil. The vast majority of people confuse a lesser evil with true freedom because they never saw true freedom in their lives. Most people are so complacent they think they will be free for ever if their masters start whipping them more humanely. This human animal was humanely enslaved, so it's okay. Trust me.

In nature, nobody owns information. Information belongs to everyone. If people stop believing in intellectual property, all software licenses will stop functioning. Licensing on access to information is evil. What's evil is intellectual property which claims ownership over other people's physical copies of information. In the physical universe, there's only physical property ownership. That means our bodies are our physical properties. If you dictate what other people can do with their physical copies of information, you are indirectly claiming ownership over their physical bodies because you are dictating what people can do with their bodies although they are not initiating harm on other people's physical properties and they are not stealing access to information from anyone else through deception. Laying claims on other people's bodies or their physical properties is called slavery. Slavery is evil. God hates slavery. God just lets humans enslave or kill each other because God hates those who believe in slavery. Abandonment is God's revenge. God will only come back and help in some form if we collectively stop believing in slavery. There are many forms of slavery. Chattel slavery is a form of overt slavery. Covert forms of slavery are still prevalent on earth. Indirect claims upon our bodies through our fruits of labor and our physical properties are covert slavery. You have two choices. Rule in hell. Serve in heaven. Earth has been hell for at least a few thousand years. While I agree that GPL is a lesser evil than EULA, we shouldn't strive to choose a king that whips us more humanely. GPL may whip you more humanely than EULA, but it is still evil. We should oppose evil instead of choosing a lesser evil. The vast majority of people confuse a lesser evil with true freedom because they never saw true freedom in their lives. Most people are so complacent they think they will be free for ever if their masters start whipping them more humanely. This human animal was humanely enslaved, so it's okay. Trust me.

earl-warren commented 2024年12月08日 08:59:44 +01:00

@amano.kenji this is off-topic and does not make any logical sense, please stop.

@amano.kenji this is off-topic and does not make any logical sense, please stop.

fnetX commented 2024年12月08日 13:01:18 +01:00

This thread lead to action, and the Forgejo contributors are happy. If Forgejo community members see a need to reiterate on licensing, a new discussion can be created, reflecting the updated situation.

Leaving this old thread open mostly leads to bumping from users that, to my knowledge, had no meaningful interaction in the Forgejo spaces before.

Thanks to everyone involved.

This thread lead to action, and the Forgejo contributors are happy. If Forgejo community members see a need to reiterate on licensing, a new discussion can be created, reflecting the updated situation. Leaving this old thread open mostly leads to bumping from users that, to my knowledge, had no meaningful interaction in the Forgejo spaces before. Thanks to everyone involved.