Improve licensing article #174

Open
opened 1 year ago by fnetX · 17 comments
fnetX commented 1 year ago
Owner

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.
fnetX added the
Status: Help wanted
Kind: Documentation
Kind: Enhancement
Priority: Medium
labels 1 year ago

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.

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
Poster
Owner

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), ...).

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.

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.
Poster
Owner

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.

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.

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.

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.

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)
Poster
Owner

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.

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.
Poster
Owner

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.

  1. 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.

&

  1. rather link to it, please

  2. 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 💙

@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.

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

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

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 1 year ago
Collaborator

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
Sign in to join this conversation.
No Milestone
No Assignees
5 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Codeberg/Documentation#174
Loading…
There is no content yet.