Improve licensing article #174

fnetX commented 2021年10月24日 03:11:17 +02:00

Just some additions to the recently added article from #173 (https://docs.codeberg.org/getting-started/licensing/)

Mention private repo / note-taking rule:
A user on Mastodon asked about private repos? We should mention that private repos are possible (re-link to the FAQ which explains this, but people only looking at the licensing guide will overlook the clarification in the FAQ and the section in the Terms of Use)

How to apply:
People might wonder how to apply a license to your code. AFAICT, it's usually considered okay to just put a file next to your code, but to properly license code and avoid any legal uncertainty, it should be explicitly stated that the code is under this license, right? Ideally, every file should include a license header.
It might be good to give good and precise instructions on how to actually change the license, especially since the full license texts are sometimes hard to copy into a easily readable file (so maybe tell people what's necessary to reference a file that lives outside etc).
A place where someone was hit by the "adding a file is enough" is in Codeberg/Community#407, and I agree that the Gitea UI kinda suggests that using the license dialog is everything you need.

Reasoning:
Some people might wonder why a repo needs a license. Some hints are kinda hidden, but they might be made more prominently.

Not specifying a license for your code does not automatically mean you've made it available without restrictions; you are still its copyright holder and must explicitly make the code free by choosing a free license.

Please do not use custom licenses, they are usually a bad idea and might result in legal uncertainty.

---

@michielappelman are you interested in fixing this up once more? No obligation of course, your first version is already very nice, these are just some improvements I can think of by now.

Just some additions to the recently added article from #173 (https://docs.codeberg.org/getting-started/licensing/) Mention private repo / note-taking rule: A user on Mastodon asked about private repos? We should mention that private repos are possible (re-link to the FAQ which explains this, but people only looking at the licensing guide will overlook the clarification in the FAQ and the section in the Terms of Use) How to apply: People might wonder how to apply a license to your code. AFAICT, it's usually considered *okay* to just put a file next to your code, but to properly license code and avoid any legal uncertainty, it should be explicitly stated that the code is under this license, right? Ideally, every file should include a license header. It might be good to give good and precise instructions on how to actually change the license, especially since the full license texts are sometimes hard to copy into a easily readable file (so maybe tell people what's necessary to reference a file that lives outside etc). A place where someone was hit by the "adding a file is enough" is in Codeberg/Community#407, and I agree that the Gitea UI kinda suggests that using the license dialog is everything you need. Reasoning: Some people might wonder *why* a repo needs a license. Some hints are kinda hidden, but they might be made more prominently. > Not specifying a license for your code does not automatically mean you've made it available without restrictions; you are still its copyright holder and must explicitly make the code free by choosing a free license. > Please do not use custom licenses, they are usually a bad idea and might result in legal uncertainty. --- @michielappelman are you interested in fixing this up once more? No obligation of course, your first version is already very nice, these are just some improvements I can think of by now.

tok commented 2021年11月09日 22:44:40 +01:00

Just some more thoughts:

• The article should also mention FSF-approved licenses. Now there is only the OSI. The view of the FSF fits much better in our context. They have a clear focus on ethical aspects, so do we. We promote copyleft, so does the FSF. The OSI has a very questionable position in this regard: Their main sponsor is Google (https://opensource.org/corporate-sponsors-support). Google is very strong in advocating temporarily-open licences (aka 'permissive', such as the Apache licence), Google internally even has a ban on the AGPL (https://opensource.google/docs/using/agpl-policy/).
• To understand licenses and copyleft, it is necessary to have a basic understanding of copyright. A short introduction with some examples could make sense. Or a link to such a thing.
• For non-code licences it might be good to also mention the GNU Free Documentation License (GFDL), since it belongs somehow into the GPL ecosystem.
• I started liking the terms 'temporarily-open' (non-copyleft) and 'forever-open' (copyleft). In my experience it is easy to get mislead as a lay person by the terms 'permissive' and 'copyleft'. The terms are widely established but are not descriptive.

I might eventually work this into the text. Sofar I was not active in contributing to the docs and don't know who is curating them.
So let me know if there are any objections.

Just some more thoughts: * The article should also mention FSF-approved licenses. Now there is only the OSI. The view of the FSF fits much better in our context. They have a clear focus on ethical aspects, so do we. We promote copyleft, so does the FSF. The OSI has a very questionable position in this regard: Their main sponsor is Google (https://opensource.org/corporate-sponsors-support). Google is very strong in advocating *temporarily-open* licences (aka 'permissive', such as the Apache licence), Google internally even has a *ban* on the AGPL (https://opensource.google/docs/using/agpl-policy/). * To understand licenses and copyleft, it is necessary to have a basic understanding of copy*right*. A short introduction with some examples could make sense. Or a link to such a thing. * For non-code licences it might be good to also mention the GNU Free Documentation License (GFDL), since it belongs somehow into the GPL ecosystem. * I started liking the terms 'temporarily-open' (non-copyleft) and 'forever-open' (copyleft). In my experience it is easy to get mislead as a lay person by the terms 'permissive' and 'copyleft'. The terms are widely established but are not descriptive. I might eventually work this into the text. Sofar I was not active in contributing to the docs and don't know who is curating them. So let me know if there are any objections.

tok commented 2021年11月09日 22:49:45 +01:00

AFAICT, it's usually considered okay to just put a file next to your code, but to properly license code and avoid any legal uncertainty, it should be explicitly stated that the code is under this license, right? Ideally, every file should include a license header.

I'm not an expert, but I actually consider the headers even more important because

• files are kind-of atomic units
• there could be files with differenc licences in the same repository

As a reference: https://www.gnu.org/licenses/gpl-howto.en.html

> AFAICT, it's usually considered okay to just put a file next to your code, but to properly license code and avoid any legal uncertainty, it should be explicitly stated that the code is under this license, right? Ideally, every file should include a license header. I'm not an expert, but I actually consider the headers even more important because * files are kind-of atomic units * there could be files with differenc licences in the same repository As a reference: https://www.gnu.org/licenses/gpl-howto.en.html

fnetX commented 2021年11月09日 23:34:58 +01:00

Thank you for your feedback. The article about proper licensing is very important IMHO, because it's what we want to promote here and is a really important thing for us as a software forge, to give contributors at hand. So any improvement very welcome!

There is the lax rule of waiting for about two approvements before merging, less for less-important changes or when there is simply no more feedback after a while.

I think that personals views can make it into the licensing article, but I'd ask everyone to stay as objective as possible and to cover multiple perspectives. There are things people have fought war over, we should just quickly mention different arguments (e.g. copyleft vs temporarily open; license headers vs. one central place (promotion of the reuse project could also be an option), ...).

Thank you for your feedback. The article about proper licensing is very important IMHO, because it's what we want to promote here and is a really important thing for us as a software forge, to give contributors at hand. So any improvement very welcome! There is the lax rule of waiting for about two approvements before merging, less for less-important changes or when there is simply no more feedback after a while. I think that personals views can make it into the licensing article, but I'd ask everyone to stay as objective as possible and to cover multiple perspectives. There are things people have fought war over, we should just quickly mention different arguments (e.g. copyleft vs temporarily open; license headers vs. one central place (promotion of the reuse project could also be an option), ...).

tok commented 2021年11月09日 23:39:19 +01:00

tok/codeberg-documentation@8f109fe51d

Not a pull-request yet because it is late-night work. Just for reference and input to the discussion.

https://codeberg.org/tok/codeberg-documentation/commit/8f109fe51de563a5019dcb61a43ee480ed279f39 Not a pull-request yet because it is late-night work. Just for reference and input to the discussion.

tok commented 2021年11月09日 23:46:31 +01:00

Another thought:
We should highlight that the licence is also about protecting the user from being sued for copyright or even patent infringement (as long as it relates to the licenced work). Especially the MIT licence basically allows that code can be used without copyright infringement but nevertheless the copyright owner can sue the user for patent infringement related to the licenced work. As a user this is good to know. Not sure if that happens often, though. So for this reason we should think about promoting the Apache Licence before the MIT licence.

Another thought: We should highlight that the licence is also about protecting the user from being sued for copyright or even patent infringement (as long as it relates to the licenced work). Especially the MIT licence basically allows that code can be used without copyright infringement but nevertheless the copyright owner can sue the user for *patent* infringement related to the licenced work. As a user this is good to know. Not sure if that happens often, though. So for this reason we should think about promoting the Apache Licence before the MIT licence.

fnetX commented 2021年11月10日 00:07:07 +01:00

Already checked out your commit from the explore view :)

Why did you switch from the OSI list to the FSF list in line 32/41? I don't know why the other one was listed there, though, maybe it's worth linking both as in the current no-license reminder inside the repos?

To the patent thing: It would be great to have resources if this happens, I have never heard of such a thing. It would also be very hard to claim patents if something was released for free use without mentioning the patent, I doubt this works in a court actually. But still, an interesting thought, that could be theoretically mentioned if no such evidence can be found.

Already checked out your commit from the explore view :) Why did you switch from the OSI list to the FSF list in line 32/41? I don't know why the other one was listed there, though, maybe it's worth linking both as in the current no-license reminder inside the repos? To the patent thing: It would be great to have resources if this happens, I have never heard of such a thing. It would also be very hard to claim patents if something was released for free use without mentioning the patent, I doubt this works in a court actually. But still, an interesting thought, that could be theoretically mentioned if no such evidence can be found.

tok commented 2021年11月10日 09:32:16 +01:00

Why did you switch from the OSI list to the FSF list in line 32/41?

I switched to the FSF list for following reasons:

• For consistency. We start introducing free software on the foundation of gnu.org. There are quite some links to gnu.org. Also we promote the GPL family quite clearly. Both are tightly related to the FSF. So it only makes sense to then link to the list of licences by the FSF and not the OSI.
• The FSF seems more aligned with our mission. They put a clear focus on ethical aspects and on the general public. The OSI seems to be more focused on coorporate aspects. They do promote non-copyleft licences (https://opensource.org/licenses). The most solid reference I can currently provide is the list of sponsors. The 'anchor' sponsor of the OSI is Google followed other big technology companies (https://opensource.org/corporate-sponsors-support). I strongly believe that an 'anchor' sponsor will have a influence on the OSI. The FSF looks very different with 'patrons' like Purism and Savoir-Faire Linux (both I see aligned with our mission, the others I don't know) (https://www.fsf.org/patrons).

We can indeed link to both. But I'd then also write a short explanation who they are (as objective as possible). I think it could be confusing otherwise.

> Why did you switch from the OSI list to the FSF list in line 32/41? I switched to the FSF list for following reasons: * For consistency. We start introducing free software on the foundation of gnu.org. There are quite some links to gnu.org. Also we promote the GPL family quite clearly. Both are tightly related to the FSF. So it only makes sense to then link to the list of licences by the FSF and not the OSI. * The FSF seems more aligned with our mission. They put a clear focus on ethical aspects and on the general public. The OSI seems to be more focused on coorporate aspects. They do promote non-copyleft licences (https://opensource.org/licenses). The most solid reference I can currently provide is the list of sponsors. The 'anchor' sponsor of the OSI is Google followed other big technology companies (https://opensource.org/corporate-sponsors-support). I strongly believe that an 'anchor' sponsor will have a influence on the OSI. The FSF looks very different with 'patrons' like Purism and Savoir-Faire Linux (both I see aligned with our mission, the others I don't know) (https://www.fsf.org/patrons). We can indeed link to both. But I'd then also write a short explanation who they are (as objective as possible). I think it could be confusing otherwise.

tok commented 2021年11月10日 09:53:04 +01:00

To the patent thing: It would be great to have resources if this happens, I have never heard of such a thing. It would also be very hard to claim patents if something was released for free use without mentioning the patent, I doubt this works in a court actually. But still, an interesting thought, that could be theoretically mentioned if no such evidence can be found.

The FSF on the X11 Licence and also Expat Licence (often called "the MIT licence"):

we recommend the Apache 2.0 license since it protects users from patent treachery.

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

I'm not an expert on that, but maybe that's an interesting read:

However, the specific license grants under the GPLv2, the
BSD and the MIT licenses were drafted using concepts derived mainly from copyright law
and not patent law.2 By way of example, the express license grants under the GPLv2 concern
only the exclusive rights of a copyright holder, namely copying, modification and distribution
of the code.3 The exclusive rights of a patent holder as enumerated in 35 U.S.C. Sec. 271(a),
i.e. the rights to make, use, sell, offer for sale and import, are not mentioned within the license

grants of the GPLv2.

https://international.vlex.com/vid/free-and-open-source-739218105

Also

The existence and scope of any patent license grants in popular open
source licenses is, to date, unresolved

As the article states, there seems to be unclarity.

Based on this I conclude that there's no guarantee that such software licences also give the user a licence to use a patent under the same conditions.

I believe that this can be avoided using licences with a 'patent clause' like the GPLv3 or Apache-2.0 do. Not only does this protect the user but it also protects the project from 'trojan' contributions.

Imagine Android would be licenced under the X11/Expat/MIT licence without a patent clause. It would be possible that somebody maliciously sneaks in a patented contribution and then later sues Google for patent infringement.

> To the patent thing: It would be great to have resources if this happens, I have never heard of such a thing. It would also be very hard to claim patents if something was released for free use without mentioning the patent, I doubt this works in a court actually. But still, an interesting thought, that could be theoretically mentioned if no such evidence can be found. The FSF on the X11 Licence and also Expat Licence (often called "the MIT licence"): > we recommend the Apache 2.0 license since it protects users from patent treachery. https://www.gnu.org/licenses/license-list.en.html#X11License I'm not an expert on that, but maybe that's an interesting read: > However, the specific license grants under the GPLv2, the > BSD and the MIT licenses were drafted using concepts derived mainly from copyright law > and not patent law.2 By way of example, the express license grants under the GPLv2 concern > only the exclusive rights of a copyright holder, namely copying, modification and distribution > of the code.3 The exclusive rights of a patent holder as enumerated in 35 U.S.C. Sec. 271(a), > i.e. the rights to make, use, sell, offer for sale and import, are not mentioned within the license > > grants of the GPLv2. > https://international.vlex.com/vid/free-and-open-source-739218105 Also > The existence and scope of any patent license grants in popular open source licenses is, to date, unresolved As the article states, there seems to be unclarity. Based on this I conclude that there's no guarantee that such software licences also give the user a licence to use a patent under the same conditions. I believe that this can be avoided using licences with a 'patent clause' like the GPLv3 or Apache-2.0 do. Not only does this protect the user but it also protects the project from 'trojan' contributions. Imagine Android would be licenced under the X11/Expat/MIT licence without a patent clause. It would be possible that somebody maliciously sneaks in a patented contribution and then later sues Google for patent infringement.

tok commented 2021年11月10日 09:59:19 +01:00

Yet another thought:

Do we want to have an opinion, recommendation or even terms-of-use regarding contributor licence agreements (CLA)?

I remember projects being licenced under an free and open-source licence but they required contributors to sign a CLA. The CLA basically said that the contributor transfers the copyright ownership to the project owner.

Such methods can be used as 'backdoors' to turn copyleft into non-copyleft or even proprietary code: If you are the only copyright owner of a software, then you can change the licence at will.

See for example https://en.wikipedia.org/wiki/Contributor_License_Agreement#Examples.

Yet another thought: Do we want to have an opinion, recommendation or even terms-of-use regarding contributor licence agreements (CLA)? I remember projects being licenced under an free and open-source licence but they required contributors to sign a CLA. The CLA basically said that the contributor transfers the copyright ownership to the project owner. Such methods can be used as 'backdoors' to turn copyleft into non-copyleft or even proprietary code: If you are the only copyright owner of a software, then you can change the licence at will. See for example https://en.wikipedia.org/wiki/Contributor_License_Agreement#Examples.

tok commented 2021年11月11日 10:49:06 +01:00

Comment on choosealicense.com

• This page is made by Github and must be assumed to reflect interests of Microsoft. I suspect that there is a bias which is not aligned with ours (GPL comes last). And they keep silent about the missing patent clause in the MIT licence (on the front page).
• The wording "I want it simple and permissive" sounds to be crafted to make people favour the MIT licence (not clear which one of X11, Expat, there is confusion). Of course, laypeople will want to have legal things simple, and "permissive" even sounds like fair and good.

More ideas & comments:

I think, Codeberg can have its own recommendation of licences indeed (similar to what there is already).
However, I suggest to move this section more towards the top of the document and then later on go into explanations. I'm afraid, many people will not read the full text anyway.

About spelling: https://prowritingaid.com/art/492/Licence-vs--License%3A-Which-One-is-Right.aspx (trackers there)

In the US: license = noun, to license = verb
Everywhere else: licence = noun, to license = verb
Since codeberg.org is located in Germany, I suggest to use the latter spelling. (I was not being consistent myself, but will try from now on)

Comment on **choosealicense.com** * This page is made by Github and must be assumed to reflect interests of Microsoft. I suspect that there is a bias which is not aligned with ours (GPL comes last). And they keep silent about the missing patent clause in the MIT licence (on the front page). * The wording "I want it simple and permissive" sounds to be crafted to make people favour the MIT licence (not clear which one of X11, Expat, there is confusion). Of course, laypeople will want to have legal things simple, and "permissive" even sounds like fair and good. More ideas & comments: I think, Codeberg can have its own recommendation of licences indeed (similar to what there is already). However, I suggest to move this section more towards the top of the document and then later on go into explanations. I'm afraid, many people will not read the full text anyway. About **spelling**: https://prowritingaid.com/art/492/Licence-vs--License%3A-Which-One-is-Right.aspx (trackers there) In the US: licen**s**e = noun, to licen**s**e = verb Everywhere else: licen**c**e = noun, to licen**s**e = verb Since codeberg.org is located in Germany, I suggest to use the latter spelling. (I was not being consistent myself, but will try from now on)

fnetX commented 2021年11月11日 12:05:12 +01:00

I'm afraid I only scanned through your comments. Feel free to just go ahead and realize them. We are happy about every contribution, and the current state does in no way reflect an official stance or anything, but is simply a very first contribution we received and allowed us to make licensing more clear to our users than it has been before. There is always a lot of room for improvements.

I'm afraid I only scanned through your comments. Feel free to just go ahead and realize them. We are happy about every contribution, and the current state does in no way reflect an official stance or anything, but is simply a very first contribution we received and allowed us to make licensing more clear to our users than it has been before. There is always a lot of room for improvements.

Luca commented 2021年11月15日 23:45:20 +01:00

I had extensive offline discussions with @tok. Below are some of the thoughts which emerged:

1. the page should provide some practical recommendations about specific licences and recommend in the first place licences which guarantee a perpetual openness of the code (copyleft/forever-open licences). It should not reinvent the wheel, but it should redirect to external well-established references whenever possible, like the extensive catalogation of licences made by GNU/FSF.
2. the page should warn about the patent issue of certain licences (patent treachery)
3. the page should contain text which is concise and simple to undererstand. It should provide a basic legal background about copyright law. It should explain the difference between forever-open licences (copyleft) and temporarily-open licences (permissive)
4. the page should explain how to add a licence in practice by redirecting to dedicated pages, such as https://reuse.software
5. the page should be structured in paragraphs for a) software projects, b) hardware projects, c) other projects (text, artwork, etc) since they all have different licence requirements
6. the page should promote selected best practices (e.g. avoid the use of too many licences. i.e. the proliferation of licences)
7. as an indepedent association which further promotes awareness on social and philosophical issues (see statute), Codeberg should warn about existing conflict of interests of other entities (e.g. Microsoft/GitHub/Choosealicense)
8. warn about CLA and provide recommendations
9. append an FAQ (what about private repos?, ...)
10. about the way to begin the page:
    In the statute of Codeberg is written that:

The purpose of the association is to promote the creation, collection, dissemination and preservation of Free Content (Open Content, Free Cultural Work) and Free and Open Source Software (FOSS), and their documentation in selfless activity, thereby enabling equal opportunities in access to knowledge and education. To this end, it also aims to raise awareness of the related social and philosophical issues.

but in the current licencing page is written that:

Codeberg's mission is to support the development and creation of Free Software, thus we only allow those repos licensed under an OSI/FSF-approved license.

The two should be consistent. Maybe rather than trying to deduce from abstract principles it is enought to state that term of use of codeberg requires the use of an open-source licence for all project. One can later explain why this is important.

I had extensive offline discussions with @tok. Below are some of the thoughts which emerged: 1. the page should provide some practical recommendations about specific licences and recommend in the first place licences which guarantee a perpetual openness of the code (copyleft/forever-open licences). It should not reinvent the wheel, but it should redirect to external well-established references whenever possible, like the extensive catalogation of licences made by GNU/FSF. 2. the page should warn about the patent issue of certain licences (patent treachery) 3. the page should contain text which is concise and simple to undererstand. It should provide a basic legal background about copyright law. It should explain the difference between forever-open licences (copyleft) and temporarily-open licences (permissive) 4. the page should explain how to add a licence in practice by redirecting to dedicated pages, such as https://reuse.software 5. the page should be structured in paragraphs for a) software projects, b) hardware projects, c) other projects (text, artwork, etc) since they all have different licence requirements 6. the page should promote selected best practices (e.g. avoid the use of too many licences. i.e. the proliferation of licences) 7. as an indepedent association which further promotes awareness on social and philosophical issues (see statute), Codeberg should warn about existing conflict of interests of other entities (e.g. Microsoft/GitHub/Choosealicense) 8. warn about CLA and provide recommendations 9. append an FAQ (what about private repos?, ...) 10. about the way to begin the page: In the statute of Codeberg is written that: ```txt The purpose of the association is to promote the creation, collection, dissemination and preservation of Free Content (Open Content, Free Cultural Work) and Free and Open Source Software (FOSS), and their documentation in selfless activity, thereby enabling equal opportunities in access to knowledge and education. To this end, it also aims to raise awareness of the related social and philosophical issues. ``` but in the current licencing page is written that: ```txt Codeberg's mission is to support the development and creation of Free Software, thus we only allow those repos licensed under an OSI/FSF-approved license. ``` The two should be consistent. Maybe rather than trying to deduce from abstract principles it is enought to state that term of use of codeberg requires the use of an open-source licence for all project. One can later explain why this is important.

fnetX commented 2021年11月16日 01:16:52 +01:00

Thank you for this easier-to-read list of points. We could even convert this into ToDo-Boxes ([ ]) and ask people to pick one (some) of them.

5. I think we should keep repetition as low as possible, but having some extra paragraphs that mention exceptions / differences for other kinds of content sounds like a good idea.

&

9. rather link to it, please

10. This page was mainly a blocker for licence reminders to spread awareness, and is thus mainly linked there. So the most important thing is to make people understand why a FLOSS licence is the thing we all want in their repo, not "just because it's in the Terms of Use". Whoever is going to rework this, please keep in mind that people might read the article without even fully understanding what this spirit means. I know many people who literally thought that they are contributing to Open Source because they put their code into a publicly accessible space (like a Git(Hub) repo). Those will be redirected to this article, and they should be caring about FLOSS afterwards 💙

Thank you for this easier-to-read list of points. We could even convert this into ToDo-Boxes (`[ ]`) and ask people to pick one (some) of them. 5) I think we should keep repetition as low as possible, but having some extra paragraphs that mention exceptions / differences for other kinds of content sounds like a good idea. & 9) rather link to it, please 10) This page was mainly a blocker for licence reminders to spread awareness, and is thus mainly linked there. So the most important thing is to make people understand *why* a FLOSS licence is the thing we all want in their repo, not "just because it's in the Terms of Use". Whoever is going to rework this, please keep in mind that people might read the article without even fully understanding what this spirit means. I know many people who literally thought that they are contributing to Open Source because they put their code into a publicly accessible space (like a Git(Hub) repo). Those will be redirected to this article, and they should be caring about FLOSS afterwards 💙

tok commented 2021年11月16日 08:51:53 +01:00

@fnetX Ah, I did not fully get that people will be mainly redirected there with the licence reminder. Thanks!

I had in mind to start like this:

Code without licence imposes legal uncertainty about its use and distribution. Therefore the Terms of Use of Codeberg requires that all projects should be published with an open-source licence. This can be motivated as follows:
For projects published without a licence or an equivalent agreement, copyright law grants to the authors (whether they are known publicly or not) the exclusive right for use and distribution of their work.
In other words: in the absence of a permission from the copyright holder, copyright law forbids anybody else than the copyright holder to use or distribute (for example to copy or sell, either directly or though third parties) the work. A licence is a legal statement which grants others the rights to use the protected work, eventually under some conditions.
Providing a licence is not the unique way to grant the rights to use or distribute a protected work, but is a very practical one and it is the only way which has worked so far in practice in the developement of Free Software.

@fnetX Ah, I did not fully get that people will be mainly redirected there with the licence reminder. Thanks! I had in mind to start like this: > Code without licence imposes legal uncertainty about its use and distribution. Therefore the [Terms of Use](https://codeberg.org/codeberg/org/src/branch/main/TermsOfUse.md) of Codeberg requires that all projects should be published with an open-source licence. This can be motivated as follows: For projects published without a licence or an equivalent agreement, copyright law grants to the authors (whether they are known publicly or not) the exclusive right for use and distribution of their work. In other words: in the absence of a permission from the copyright holder, copyright law forbids anybody else than the copyright holder to use or distribute (for example to copy or sell, either directly or though third parties) the work. A *licence* is a legal statement which grants others the rights to use the protected work, eventually under some conditions. Providing a licence is not the unique way to grant the rights to use or distribute a protected work, but is a very practical one and it is the only way which has worked so far in practice in the developement of Free Software.

sjbutler commented 2021年11月18日 22:03:06 +01:00

Perhaps indicate that REUSE (https://reuse.software/) is the prefered (expected) approach.

Perhaps indicate that REUSE (https://reuse.software/) is the prefered (expected) approach.

fnetX commented 2021年11月20日 13:59:52 +01:00

Copy from the original issue, I think this is the part not yet implemented but proposed in the now-closed issue.

clarify some common issues with licences, e.g. clarifying how to apply them properly and unmistakably (also see Codeberg/Community#407, chosing -ONLY vs. -OR-LATER variants must be done by the user for example)

Copy from the original issue, I think this is the part not yet implemented but proposed in the now-closed issue. > clarify some common issues with licences, e.g. clarifying how to apply them properly and unmistakably (also see Codeberg/Community#407, chosing -ONLY vs. -OR-LATER variants must be done by the user for example)

n commented 2021年11月21日 15:07:07 +01:00

For a public domain equivalent license, we recommend using 0BSD instead of other licenses. I think it would be beneficial to explain why: it has better reception and recognition from companies.

Relevant comment on choosealicence.com: https://github.com/github/choosealicense.com/issues/805#issuecomment-799220564

For a public domain equivalent license, we recommend using 0BSD instead of other licenses. I think it would be beneficial to explain why: it has better reception and recognition from companies. Relevant comment on choosealicence.com: https://github.com/github/choosealicense.com/issues/805#issuecomment-799220564

soas commented 2023年09月10日 12:20:03 +02:00

Found this issue via Community repo: Codeberg/Community#624 I apologize if this should be a separate issue or in a different tracker; this is my best guess.

Currently the new repo page still links to https://choosealicense.com/ where MIT license is prominently and favorably described as mentioned previously.

I would suggest that when this is fixed, the drop down list should correspond to the names given on the provided documentation.

This libre license advocated by the linked page is "GNU GPLv3". If I type "GNU" into the drop down I get gnu-javamail-exception and gnu-plot. Type "GPL" and there are about 2 dozen options. "GPLv3" shows nothing but there are 4x variations under GPL-3.0-. In my browser the drop down only show 3 lines at a time so it is not easy to find that v3 is described as -3.0-.. you need to hunt a lot if you don't already know that. Then, I don't know which one actually is the same one I want.

It's fine to have the long extensive list for those who wish to use it, but the first items should be exactly the same wording as whatever documentation is provided. In this case, the top item should be GNU GPLv3, followed, I guess, by MIT.

Found this issue via Community repo: https://codeberg.org/Codeberg/Community/issues/624 I apologize if this should be a separate issue or in a different tracker; this is my best guess. Currently the new repo page still links to https://choosealicense.com/ where MIT license is prominently and favorably described as mentioned previously. I would suggest that when this is fixed, the drop down list should correspond to the names given on the provided documentation. This libre license advocated by the linked page is "GNU GPLv3". If I type "GNU" into the drop down I get `gnu-javamail-exception` and `gnu-plot`. Type "GPL" and there are about 2 dozen options. "GPLv3" shows nothing but there are 4x variations under `GPL-3.0-`. In my browser the drop down only show 3 lines at a time so it is not easy to find that `v3` is described as `-3.0-`.. you need to hunt a lot if you don't already know that. Then, I don't know which one actually is the same one I want. It's fine to have the long extensive list for those who wish to use it, but the first items should be exactly the same wording as whatever documentation is provided. In this case, the top item should be `GNU GPLv3`, followed, I guess, by `MIT`.

fnetX commented 2023年10月08日 00:39:35 +02:00

I'm in favour of promoting https://writefreesoftware.org/ from Codeberg, replacing Choose a license where applicable. WriteFreeSoftware aligns better with our mission, is more approachable in my opinion, and covers more than "simply choosing a license". Because writing Free Software does not end with picking a choice from a checkbox alone.

I'm in favour of promoting https://writefreesoftware.org/ from Codeberg, replacing Choose a license where applicable. WriteFreeSoftware aligns better with our mission, is more approachable in my opinion, and covers more than "simply choosing a license". Because writing Free Software does not end with picking a choice from a checkbox alone.

soas commented 2023年10月09日 13:53:05 +02:00

I am guessing you would link directly to Choosing a license? If yes I think it is a huge improvement over the existing link. It very succinctly touches on a range of issues to consider.

With regards to my previous comment about the licenses being findable in the list, I think the change of link should be made irregardless.

But I would like to point out that of the libre licenses recommended, none of them are findable. (Both the MIT and BSD licenses are findable though.)

The problem is that abbreviations are being used instead of the full names. Also, the GPL abbreviations have different word orders than the full names on this website. So they are not located in the expected alphabetical order.

On my desktop browser, this drop down shows up with a fancy type-to-find widget that should make obtaining the correct item from the long list pretty fast. Yes none of them are findable this way; you really have to scroll through the list which only shows 3 lines at a time.

The solution could be to list the full name along with abbreviations. For example, replace "MPL-2.0" with "Mozilla Public License 2.0 (MPL-2.0)". Assuming other browsers work the same way mine does, this would still allow people who know the abbreviation they are looking for to locate easily (typing "mpl").

Idk if there is some other reason why the listings are abbreviation-only. Internationalization?

I am guessing you would link directly to [Choosing a license](https://writefreesoftware.org/learn/participate/choose-a-license/)? If yes I think it is a huge improvement over the existing link. It very succinctly touches on a range of issues to consider. With regards to my previous comment about the licenses being findable in the list, I think the change of link should be made irregardless. But I would like to point out that of the libre licenses recommended, none of them are findable. (Both the MIT and BSD licenses *are* findable though.) The problem is that abbreviations are being used instead of the full names. Also, the GPL abbreviations have different word orders than the full names on this website. So they are not located in the expected alphabetical order. On my desktop browser, this drop down shows up with a fancy type-to-find widget that should make obtaining the correct item from the long list pretty fast. Yes none of them are findable this way; you really have to scroll through the list which only shows 3 lines at a time. The solution could be to list the full name along with abbreviations. For example, replace "MPL-2.0" with "Mozilla Public License 2.0 (MPL-2.0)". Assuming other browsers work the same way mine does, this would still allow people who know the abbreviation they are looking for to locate easily (typing "mpl"). Idk if there is some other reason why the listings are abbreviation-only. Internationalization?

fnetX commented 2023年10月09日 15:21:45 +02:00

Could you try to propose your changes to the license chooser to https://codeberg.org/forgejo/forgejo?

The list is autogenerated from SPDX license data, but I'm pretty sure that someone could make adjustments to this process to allow the format "Full Name (Short Name)".

Could you try to propose your changes to the license chooser to https://codeberg.org/forgejo/forgejo? The list is autogenerated from SPDX license data, but I'm pretty sure that someone could make adjustments to this process to allow the format "Full Name (Short Name)".

soas commented 2024年02月02日 16:37:47 +01:00

I've had this issue pinned as I was trying to articulate a request in https://codeberg.org/forgejo/forgejo as requested. But I couldn't get it very concise.

Now I see the linked documentation has been changed to https://docs.codeberg.org/getting-started/licensing. For me, I like the new one. I finally know which license to select from the list (AGPL 3.0 or later). I honestly couldn't figure it out before.

I feel that the document might be a little complicated for someone who isn't already framiliar with the concepts though. Maybe it's just impossible to explain in a way that's both reasonably accurate/nuanced and also extremely brief.

I am curious:

1: are the effects measurable?

Are there any metrics available describing how many people actually select a license at the "create repo" page and if it changes over time? Especially if it can be correlated with viewing the explainer document.

Hope it doesn't come across as excessively taylorist or snooping.

2: flowchart flow

Is the intention to make the "flowchart" section visually clearer? I am not framiliar with eleventy. Without adding a bunch of complexity to the whole repo would it be possible to add some more hints to help follow the narrative? Such as borders on the left side, highlight on mouse over? Like this (tiny on purpose to show structure not content):

image

3: easy input license into form

Would it be possible to have links next to each license name that brings you to the new repo page with that form filled? Could look like this:

• No --> We recommend using the AGPL-3.0-or-later licence  create repo with this license

With that URL being https://codeberg.org/repo/create?license=AGPL-3.0-or-later and clicking it does this:

image

Not sure if it would/could go back to the previous tab the user arrived from or if it just opens a fresh one.

It might sound excessively hand-holding but remembering a long code to find it in a list among a bunch of other nearly-identical long codes is kind of hard if you don't already have a familiarity with what they are designating.

If it can't be done by magic, then having an option to copy the exact and complete name as it appears in the drop down list would be a good alternative. Like how code snippets often have the little "copy" button in the top-right corner.

4: other ways to make license choosing easier

The easier it is the more likely it will happen.

• Allow user/organization to configure default license for new repos. Then you are not faced with re-reading the guidance document every time. Make a thoughtful decision once and revisit it only when needed.

• Provide a page showing an overview of licenses of all repos for user/organization. Like https://codeberg.org/username?tab=repositories there could be a search filter/sort for license, and for needs-a-license. This would let people check easily if they forgot somewhere. For repos which are public, it would encourage accountability as other poeple could easily see an overview.

• Have some toggle for the list on new repo page to be abbreviated on an opt-in basis. Most people do not need all these choices. Being able to click "Short list" or something and have everything but the most up to date and popular 5-10 options go away would make it easier if you are trying to jog your memory.

• Somewhat conversely, I still think the full names would be worthwhile including in addition to the abbreviations. Previously I was trying to search for "gnu" instead of GPL which gets you like "GNU-compiler-exception". Other commonly-used name someone might want like mozilla or creative commons are likewise not findable.

• There should be a link on the new repo page to wherever the licenses are stored. I assume in their own repo somewhere. So that the full text can be read by anyone so inclined prior to accepting it.

• I do not find a way to add the license after the repo is created. If it exists it's hard to find. If it doesn't exist it would be nice. In the settings have an "add license" section. Even if it is literally just a link to wherever the license are kept and instructions on how to do it manually. But better if it's magic of course. I think it's reasonable that you might want to work on something a little before deciding on a license.

Sorry there's so many things. It's a bit of a bike shed type thing probably but thought I'd throw them out there in case any of them sound like a good fit.

I've had this issue pinned as I was trying to articulate a request in https://codeberg.org/forgejo/forgejo as requested. But I couldn't get it very concise. Now I see the linked documentation has been changed to https://docs.codeberg.org/getting-started/licensing. For me, I like the new one. I finally know which license to select from the list (AGPL 3.0 or later). I honestly couldn't figure it out before. I feel that the document might be a little complicated for someone who isn't already framiliar with the concepts though. Maybe it's just impossible to explain in a way that's both reasonably accurate/nuanced *and also* extremely brief. I am curious: **1: are the effects measurable?** Are there any metrics available describing how many people actually select a license at the "create repo" page and if it changes over time? Especially if it can be correlated with viewing the explainer document. Hope it doesn't come across as excessively taylorist or snooping. **2: flowchart flow** Is the intention to make the "flowchart" section visually clearer? I am not framiliar with eleventy. Without adding a bunch of complexity to the whole repo would it be possible to add some more hints to help follow the narrative? Such as borders on the left side, highlight on mouse over? Like this (tiny on purpose to show structure not content):  **3: easy input license into form** Would it be possible to have links next to each license name that brings you to the new repo page with that form filled? Could look like this: > - No --> We recommend using the AGPL-3.0-or-later licence [ create repo with this license](https://codeberg.org/repo/create?license=AGPL-3.0-or-later) With that URL being `https://codeberg.org/repo/create?license=AGPL-3.0-or-later` and clicking it does this:  Not sure if it would/could go back to the previous tab the user arrived from or if it just opens a fresh one. It might sound excessively hand-holding but remembering a long code to find it in a list among a bunch of other nearly-identical long codes is kind of hard if you don't already have a familiarity with what they are designating. If it can't be done by magic, then having an option to copy the *exact* and *complete* name as it appears in the drop down list would be a good alternative. Like how code snippets often have the little "copy" button in the top-right corner. **4: other ways to make license choosing easier** The easier it is the more likely it will happen. - Allow user/organization to configure default license for new repos. Then you are not faced with re-reading the guidance document every time. Make a thoughtful decision once and revisit it only when needed. - Provide a page showing an overview of licenses of all repos for user/organization. Like https://codeberg.org/username?tab=repositories there could be a search filter/sort for license, and for needs-a-license. This would let people check easily if they forgot somewhere. For repos which are public, it would encourage accountability as other poeple could easily see an overview. - Have some toggle for the list on new repo page to be abbreviated on an opt-in basis. Most people do not need all these choices. Being able to click "Short list" or something and have everything but the most up to date and popular 5-10 options go away would make it easier if you are trying to jog your memory. - Somewhat conversely, I still think the full names would be worthwhile including in addition to the abbreviations. Previously I was trying to search for "gnu" instead of GPL which gets you like "GNU-compiler-exception". Other commonly-used name someone might want like mozilla or creative commons are likewise not findable. - There should be a link on the new repo page to wherever the licenses are stored. I assume in their own repo somewhere. So that the full text can be read by anyone so inclined prior to accepting it. - I do not find a way to add the license after the repo is created. If it exists it's hard to find. If it doesn't exist it would be nice. In the settings have an "add license" section. Even if it is literally just a link to wherever the license are kept and instructions on how to do it manually. But better if it's magic of course. I think it's reasonable that you might want to work on something a little before deciding on a license. Sorry there's so many things. It's a bit of a bike shed type thing probably but thought I'd throw them out there in case any of them sound like a good fit.

n0toose commented 2024年02月02日 17:00:48 +01:00

I feel that the document might be a little complicated for someone who isn't already framiliar with the concepts though. Maybe it's just impossible to explain in a way that's both reasonably accurate/nuanced and also extremely brief.

Idea: Fork Choose a License and carry over the essential points of the current article ("our perspective") onto that tool?

> I feel that the document might be a little complicated for someone who isn't already framiliar with the concepts though. Maybe it's just impossible to explain in a way that's both reasonably accurate/nuanced and also extremely brief. Idea: Fork [Choose a License](https://choosealicense.com/) and carry over the essential points of the current article ("our perspective") onto that tool?

tok commented 2024年02月05日 17:36:06 +01:00

Codeberg.org: removed quote, because spam user was deleted

Do you mean formatting of license texts, or formatting of the licensing guide, or formatting of documents in projects? For the latter, REUSE would define some sort of formatting which is even machine readable.

(Honestly, this post reads like a advertisement for this commercial service which is probably not interesting for this community.)

> Codeberg.org: removed quote, because spam user was deleted Do you mean formatting of license texts, or formatting of the licensing guide, or formatting of documents in projects? For the latter, REUSE would define some sort of formatting which is even machine readable. (Honestly, this post reads like a advertisement for this commercial service which is probably not interesting for this community.)

Gusted commented 2024年02月05日 19:32:21 +01:00

(Honestly, this post reads like a advertisement for this commercial service which is probably not interesting for this community.)

Yes it does sound like that. @moderation

> (Honestly, this post reads like a advertisement for this commercial service which is probably not interesting for this community.) Yes it does sound like that. @moderation

n0toose commented 2024年03月01日 13:58:23 +01:00

@moderation

@moderation

cfr commented 2024年11月24日 05:20:39 +01:00

@michielappelman, your initial version is commendable, and there's no obligation to implement these suggestions. However, these improvements could make the article even more user-friendly and informative. Lastly, for those seeking assistance with writing or editing documentation, consider checking out https://domypaper.com/ write my paper for professional and reliable services. Thank you for your dedication to improving Codeberg documentation. Looking forward to seeing this article become an even more valuable resource!

This link is to a commercial service which looks very much like the typical buy-your-coursework-essay-or-term-paper-here. I did not explore beyond first impressions, but if this has any relevance to the concerns discussed in this issue, it is certainly hidden extremely well.

There does not seem to be any option to report a problem with a post. Not sure if I'm meant to open a new issue about a comment, but hopefully this is enough to draw it to somebody's attention.

> @michielappelman, your initial version is commendable, and there's no obligation to implement these suggestions. However, these improvements could make the article even more user-friendly and informative. Lastly, for those seeking assistance with writing or editing documentation, consider checking out https://domypaper.com/ write my paper for professional and reliable services. Thank you for your dedication to improving Codeberg documentation. Looking forward to seeing this article become an even more valuable resource! This link is to a commercial service which looks very much like the typical buy-your-coursework-essay-or-term-paper-here. I did not explore beyond first impressions, but if this has any relevance to the concerns discussed in this issue, it is certainly hidden extremely well. There does not seem to be any option to report a problem with a post. Not sure if I'm meant to open a new issue about a comment, but hopefully this is enough to draw it to somebody's attention.

cfr commented 2024年11月24日 05:28:11 +01:00

See osdc/bots#71 (comment). User has 2 posts. Both spam as far as I can see.

See https://codeberg.org/osdc/bots/issues/71#issue-920345. User has 2 posts. Both spam as far as I can see.

ppigazzini commented 2025年12月07日 20:21:29 +01:00

Old licenses like MIT and BSD are simple and permissive, but they have known legal weaknesses, at example: they lack explicit patent protections, their liability disclaimers are not fully enforceable in any legal system, and even the use of capital letters in disclaimers has sometimes been judged by courts as less readable and therefore less effective.

Modern licenses like Apache or Mozilla were designed to address the weaknesses of older licenses. They explicitly handle patent risks, provide clearer liability disclaimers, and improve legal enforceability across jurisdictions, making them more robust in today’s legal environment.

The EUPL is the only open-source license formally adopted by the European Commission and is legally valid in all 27 EU Member States. This ensures enforceability under national laws, unlike other licenses which rely on general contract principles.
The EUPL exists in 23 official EU languages, and all versions are legally equivalent, avoiding ambiguity in translation.
The EUPL is thoroughly documented by the EU itself, avoiding ambiguity in interpretation.

How to use the EUPL (very informative):
https://joinup.ec.europa.eu/collection/eupl/how-use-eupl
EUPL text:
https://joinup.ec.europa.eu/collection/eupl/eupl-text-eupl-12
Compatibility matrix:
https://joinup.ec.europa.eu/collection/eupl/matrix-eupl-compatible-open-source-licences
Description of the 7 new principles enforced in the license (the license covers "work", any combination of SW, DATA, design etc.):
https://joinup.ec.europa.eu/sites/default/files/discussion/attachment/2024-01/How%20could%20open%20licensing%20protect%20democracy.pdf

MIT and Unlicense weaknesses:
https://writing.kemitchell.com/2016/09/21/MIT-License-Line-by-Line
https://writing.kemitchell.com/2022/08/05/Public-Domain-Software

EU legal framework for any SW license:

• Directive 2009/24/EC of the EU Parliament and of the Council of 23 April 2009 on the legal protection of computer programs
  https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32009L0024

US legal framework for any SW license:

• US 1989 Copyright Law (uniformed to 1988 Berne Convention for the Protection of Literary and Artistic Works) https://www.copyright.gov/title17/
• UCC (Uniform Commercial Code) https://www.uniformlaws.org/acts/ucc
• Common Law

Old licenses like MIT and BSD are simple and permissive, but they have known legal weaknesses, at example: they lack explicit patent protections, their liability disclaimers are not fully enforceable in any legal system, and even the use of capital letters in disclaimers has sometimes been judged by courts as less readable and therefore less effective. Modern licenses like Apache or Mozilla were designed to address the weaknesses of older licenses. They explicitly handle patent risks, provide clearer liability disclaimers, and improve legal enforceability across jurisdictions, making them more robust in today’s legal environment. The EUPL is the only open-source license formally adopted by the European Commission and is legally valid in all 27 EU Member States. This ensures enforceability under national laws, unlike other licenses which rely on general contract principles. The EUPL exists in 23 official EU languages, and all versions are legally equivalent, avoiding ambiguity in translation. The EUPL is thoroughly documented by the EU itself, avoiding ambiguity in interpretation. How to use the EUPL (very informative): <https://joinup.ec.europa.eu/collection/eupl/how-use-eupl> EUPL text: <https://joinup.ec.europa.eu/collection/eupl/eupl-text-eupl-12> Compatibility matrix: <https://joinup.ec.europa.eu/collection/eupl/matrix-eupl-compatible-open-source-licences> Description of the 7 new principles enforced in the license (the license covers "work", any combination of SW, DATA, design etc.): <https://joinup.ec.europa.eu/sites/default/files/discussion/attachment/2024-01/How%20could%20open%20licensing%20protect%20democracy.pdf> MIT and Unlicense weaknesses: <https://writing.kemitchell.com/2016/09/21/MIT-License-Line-by-Line> <https://writing.kemitchell.com/2022/08/05/Public-Domain-Software> EU legal framework for any SW license: - Directive 2009/24/EC of the EU Parliament and of the Council of 23 April 2009 on the legal protection of computer programs <https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32009L0024> US legal framework for any SW license: - US 1989 Copyright Law (uniformed to 1988 Berne Convention for the Protection of Literary and Artistic Works) <https://www.copyright.gov/title17/> - UCC (Uniform Commercial Code) <https://www.uniformlaws.org/acts/ucc> - Common Law

n0toose commented 2025年12月08日 00:10:36 +01:00

Hi, sorry, we need people that contribute to the documentation from an objective point of view - we understand that the page could be improved.

Hi, sorry, we need people that contribute to the documentation from an objective point of view - we understand that the page could be improved.

ppigazzini commented 2025年12月08日 02:08:18 +01:00

The EU recognized that many established open‐source licenses have weaknesses, so it developed the EUPL to provide a clearer, more robust framework. This document explains how the EUPL addresses those gaps, and I think you’ll find it a valuable resource for improving your license page.

https://interoperable-europe.ec.europa.eu/sites/default/files/discussion/attachment/2024-01/How%20could%20open%20licensing%20protect%20democracy.pdf

I have some repositories licensed under MIT/BSD. I know these are weak and badly written licenses, I chose them out of laziness.

Have a good night :)

The EU recognized that many established open‐source licenses have weaknesses, so it developed the EUPL to provide a clearer, more robust framework. This document explains how the EUPL addresses those gaps, and I think you’ll find it a valuable resource for improving your license page. <https://interoperable-europe.ec.europa.eu/sites/default/files/discussion/attachment/2024-01/How%20could%20open%20licensing%20protect%20democracy.pdf> I have some repositories licensed under MIT/BSD. I know these are weak and badly written licenses, I chose them out of laziness. Have a good night :)