Public domain dedication as license metadata #701

Open
opened 1 month ago by io · 10 comments
io commented 1 month ago

Many pieces of software avoid licensing discussions (e.g.: GPL vs BSD vs CC) by releasing software as 'public domain' software. Generally FL/OSS licenses are rooted in copyright, while public domain dedications are usually a removal of copyright entirely. Some of the software I'm hacking on these days began as public domain software. I want to properly ensure the public domain dedication is noted as the licensing terms of the repository.

A copyright abolitionist user should be able to select 'public domain' from the license drop down menu when configuring a repository when that is our desired licensing terms. By making this an overt act, users can help rid the world of copyright, one repository at a time.

For a reasonable European and North American perspective on this issue, I would encourage readers to consider this analysis: https://cr.yp.to/publicdomain.html

Many pieces of software avoid licensing discussions (e.g.: GPL vs BSD vs CC) by releasing software as 'public domain' software. Generally FL/OSS licenses are rooted in copyright, while public domain dedications are usually a removal of copyright entirely. Some of the software I'm hacking on these days began as public domain software. I want to properly ensure the public domain dedication is noted as the licensing terms of the repository. A copyright abolitionist user should be able to select 'public domain' from the license drop down menu when configuring a repository when that is our desired licensing terms. By making this an overt act, users can help rid the world of copyright, one repository at a time. For a reasonable European and North American perspective on this issue, I would encourage readers to consider this analysis: https://cr.yp.to/publicdomain.html

That article is misleading in various ways. US style copyright is very different from the EU based system. The main difference being that in the US copyright is wholesale transferable (and can thus also be given up), in Europe it isn't.

In Europe we use the "droit d'auteur" philsophy which makes a difference between authorship rights (which are inalienable and non-transferable) and usage rights (commonly named licensing rights/Nutzungsrechte).

So technically the authorship rights expire 70 years after the death of the primary author. There is no shortcut. No way to give up authorship rights.

What we however can do is give up the usage rights. It's practically comparable to what colloquially is called public domain, but it still stays fundamentally different.

That's at the core of the confusion since many years. So whenever you dedicate your work (as european) to the public domain, you do NOT give up your authorship rights, as they are inalienable.

The mentioned article sort of touches on that but limits it to Germany while in reality it goes far beyond that.

Keep that in mind when adding a public domain option - and, as always, better to have a lawyer take a look at the possibilities and implications.

Obviously, I am not a lawyer. But I have been very, very deep in these questions since many years for professional reasons.

That article is misleading in various ways. US style copyright is very different from the EU based system. The main difference being that in the US copyright is wholesale transferable (and can thus also be given up), in Europe it isn't. In Europe we use the "droit d'auteur" philsophy which makes a difference between authorship rights (which are inalienable and non-transferable) and usage rights (commonly named licensing rights/Nutzungsrechte). So technically the authorship rights expire 70 years after the death of the primary author. There is no shortcut. No way to give up authorship rights. What we however can do is give up the usage rights. It's practically comparable to what colloquially is called public domain, but it still stays fundamentally different. That's at the core of the confusion since many years. So whenever you dedicate your work (as european) to the public domain, you do NOT give up your authorship rights, as they are inalienable. The mentioned article sort of touches on that but limits it to Germany while in reality it goes far beyond that. Keep that in mind when adding a public domain option - and, as always, better to have a lawyer take a look at the possibilities and implications. Obviously, I am not a lawyer. But I have been very, very deep in these questions since many years for professional reasons.

As far as I can see, it's at least possible to select the CC0 License which is basically a "Public Domain License" - if this term is not a contradiction in itself.
Anyway I remember discussions about CC0 because it explicitly does not waive any patent rights - which in turn can be problematic.

While I don't see why Codeberg shouldn't offer selecting "Public Domain" by itself I still find it important to say that the analysis you linked might not reflect the current situation regarding copyright/Urheberrecht in European law to its full extent.
Just declaring a work "Public Domain" without any further details does, according to literature, however not grant any commercial rights to the public. So anyone using "PD" software originating from the European Union in their own work and releasing it commercially might be at risk being sued for copyright violations.

Redeker, IT-Recht, 7. Auflage 2020, Rn. 95, 96
Wandtke/Bullinger, Urheberrecht, 6. Auflage 2022, Rn. 103, 104

Additionally I agree with @jwildeboer that it's also important to keep in mind, that even with enough effort you may get a "license" that is really close to "public domain" while the concept itself to it's full extent still is impossible to achieve because of the conceptual differences between authorship/"Urheberrecht" and copyright.

As far as I can see, it's at least possible to select the CC0 License which is basically a "Public Domain License" - if this term is not a contradiction in itself. Anyway I remember discussions about CC0 because it explicitly does **not** waive any patent rights - which in turn can be problematic. While I don't see why Codeberg shouldn't offer selecting "Public Domain" by itself I still find it important to say that the analysis you linked might not reflect the current situation regarding copyright/Urheberrecht in European law to its full extent. Just declaring a work "Public Domain" without any further details does, according to literature, however not grant any commercial rights to the public. So anyone using "PD" software originating from the European Union in their own work and releasing it commercially might be at risk being sued for copyright violations. > Redeker, IT-Recht, 7. Auflage 2020, Rn. 95, 96 > Wandtke/Bullinger, Urheberrecht, 6. Auflage 2022, Rn. 103, 104 Additionally I agree with @jwildeboer that it's also important to keep in mind, that even with enough effort you may get a "license" that is really close to "public domain" while the concept itself to it's full extent still is impossible to achieve because of the conceptual differences between authorship/"Urheberrecht" and copyright.

Also worth adding that CC licenses are expicitly NOT meant for software, as Creative Commons has declared and explained many, many times. That is one of the reasons why it doesn't cover patents explicitly, BTW.

https://creativecommons.org/faq/#can-i-apply-a-creative-commons-license-to-software

Can I apply a Creative Commons license to software?

We recommend against using Creative Commons licenses for software. Instead, we strongly encourage you to use one of the very good software licenses which are already available. We recommend considering licenses listed as free by the Free Software Foundation and listed as “open source” by the Open Source Initiative.

[...]

Also worth adding that CC licenses are expicitly NOT meant for software, as Creative Commons has declared and explained many, many times. That is one of the reasons why it doesn't cover patents explicitly, BTW. https://creativecommons.org/faq/#can-i-apply-a-creative-commons-license-to-software ### Can I apply a Creative Commons license to software? We recommend against using Creative Commons licenses for software. Instead, we strongly encourage you to use one of the very good software licenses which are already available. We recommend considering licenses listed as free by the Free Software Foundation and listed as “open source” by the Open Source Initiative. [...]
Collaborator

I don't really understand the question / goal of this issue. Should we offer a template / switch to say "This repo is public domain"?

If so, I think this is highly problematic. As already mentioned, "Public Domain" isn't an accepted term everywhere on earth and by itself not enough to unambiguosly determine the usage rights on content.

This is worked around by some Public Domain licences that contain statements that grant all usage rights when waiving all authorship rights is not allowed locally.

If someone needs PD, they should probably use a licence like 0-BSD or CC-0 that is doing nearly the same, but in a way that allows much more people to use a work without worrying about legal consequences.

We might instead consider grouping licences e.g.

  • "Public domain and like-minded"
  • "Strong Copyleft"
  • ...
  • "Only name author"
  • "Don't care"
  • and / or even "Most popular"
I don't really understand the question / goal of this issue. Should we offer a template / switch to say "This repo is public domain"? If so, I think this is highly problematic. As already mentioned, "Public Domain" isn't an accepted term everywhere on earth and by itself not enough to unambiguosly determine the usage rights on content. This is worked around by some Public Domain licences that contain statements that grant all usage rights when waiving all authorship rights is not allowed locally. If someone needs PD, they should probably use a licence like 0-BSD or CC-0 that is doing nearly the same, but in a way that allows much more people to use a work without worrying about legal consequences. We might instead consider grouping licences e.g. - "Public domain and like-minded" - "Strong Copyleft" - ... - "Only name author" - "Don't care" - and / or even "Most popular"
Poster

The intention behind opening this bug originally was to ensure that Codeberg repository metadata for a 'public domain' release of software could be accurately represented.

As of today, any Codeberg repository under such release terms cannot easily express the 'public domain' copyright status in any of the repository metadata. This results in an inaccurate summary representation of repository contents. The closest way to correctly express the public domain status on Codeberg is to elide the metadata entirely by selecting no license at all, and to ensure there is included data in the repository that makes a public domain dedication. The ability to not select a license is currently allowed and it has an ambiguous meaning.

There are several ways that one could represent the 'public domain' release status in the Codeberg metadata model. Ensuring that there is a way to reflect the reality of the released terms seems reasonable.

A few possible examples:

  1. One could be to present an additional question as a boolean such as: [copyright] -> {'yes', 'no'}

  2. Another could be to reflect the special status of a public domain dedication by adding a boolean such as 'public domain' -> {'yes', 'no'}

  3. Another way is to allow for 'public domain' as a license.

  4. Other options likely exist.

Looking at PyPi, developers appear to have chosen option 2.

On PyPi, we see 1353 projects that are "License :: Public Domain": https://pypi.org/search/?q=&o=&c=License+%3A%3A+Public+Domain

Also on PyPi 383 projects are CC-0: https://pypi.org/search/?q=&o=&c=License+%3A%3A+CC0+1.0+Universal+%28CC0+1.0%29+Public+Domain+Dedication

On PyPi 18 projects are both: https://pypi.org/search/?q=&o=&c=License+%3A%3A+CC0+1.0+Universal+%28CC0+1.0%29+Public+Domain+Dedication&c=License+%3A%3A+Public+Domain

PyPi is relevant to this discussion. The repository in question is a C program made into a library and additionally Python bindings have been added. When the bindings are uploaded to PyPi, it is possible to set "License :: Public Domain" in the PyPi metadata which accurately represents the public domain status.

A small number of projects try to express something like public domain on Codeberg: https://codeberg.org/explore/repos?q=public+domain

A few thousand projects express "public domain" on github: https://github.com/search?q=%22public+domain%22

CC-0 is recommended by the Creative Commons for use by authors of software and it is considered compatible with the GPL in agreement with the FSF. The use of CC-0 for software has been encouraged for more than a decade. See https://wiki.creativecommons.org/wiki/CC0_FAQ#May_I_apply_CC0_to_computer_software.3F_If_so.2C_is_there_a_recommended_implementation.3F and https://creativecommons.org/2011/04/15/using-cc0-for-public-domain-software/ for further information on CC-0 for use in licensing software.

Never the less, re-licensing the software in the repository in question is not a solution to the problem of wanting to accurately represent the status of the software as it was released. A person may be able to re-license software under the CC-0 license. However that person shouldn't change the fact that the original authors chose 'public domain' when they released their software, nor would it make sense to try to erase the original authorship information. CC-0 existed when the original authors made this choice, and they did not choose CC-0, and thus selecting CC-0 is incorrect. Correctly representing the release terms is the goal of this issue. My contributions on top of the released software are also intended to be in the public domain. This is becuase I want to ensure that my enhancements can be accepted by the upstream authors under the same terms as their original release: a public domain dedication.

Ensuring that there is accurate metadata which reflects the author's public domain declaration is the purpose of this issue.

The intention behind opening this bug originally was to ensure that Codeberg repository metadata for a 'public domain' release of software could be accurately represented. As of today, any Codeberg repository under such release terms cannot easily express the 'public domain' copyright status in any of the repository metadata. This results in an inaccurate summary representation of repository contents. The closest way to correctly express the public domain status on Codeberg is to elide the metadata entirely by selecting no license at all, and to ensure there is included data in the repository that makes a public domain dedication. The ability to not select a license is currently allowed and it has an ambiguous meaning. There are several ways that one could represent the 'public domain' release status in the Codeberg metadata model. Ensuring that there is a way to reflect the reality of the released terms seems reasonable. A few possible examples: 0) One could be to present an additional question as a boolean such as: [copyright] -> {'yes', 'no'} 1) Another could be to reflect the special status of a public domain dedication by adding a boolean such as 'public domain' -> {'yes', 'no'} 2) Another way is to allow for 'public domain' as a license. 3) Other options likely exist. Looking at PyPi, developers appear to have chosen option 2. On PyPi, we see 1353 projects that are "License :: Public Domain": https://pypi.org/search/?q=&o=&c=License+%3A%3A+Public+Domain Also on PyPi 383 projects are CC-0: https://pypi.org/search/?q=&o=&c=License+%3A%3A+CC0+1.0+Universal+%28CC0+1.0%29+Public+Domain+Dedication On PyPi 18 projects are both: https://pypi.org/search/?q=&o=&c=License+%3A%3A+CC0+1.0+Universal+%28CC0+1.0%29+Public+Domain+Dedication&c=License+%3A%3A+Public+Domain PyPi is relevant to this discussion. The repository in question is a C program made into a library and additionally Python bindings have been added. When the bindings are uploaded to PyPi, it is possible to set "License :: Public Domain" in the PyPi metadata which accurately represents the public domain status. A small number of projects try to express something like public domain on Codeberg: https://codeberg.org/explore/repos?q=public+domain A few thousand projects express "public domain" on github: https://github.com/search?q=%22public+domain%22 CC-0 is recommended by the Creative Commons for use by authors of software and it is considered compatible with the GPL in agreement with the FSF. The use of CC-0 for software has been encouraged for more than a decade. See https://wiki.creativecommons.org/wiki/CC0_FAQ#May_I_apply_CC0_to_computer_software.3F_If_so.2C_is_there_a_recommended_implementation.3F and https://creativecommons.org/2011/04/15/using-cc0-for-public-domain-software/ for further information on CC-0 for use in licensing software. Never the less, _re-licensing the software_ in the repository in question is not a solution to the problem of wanting to accurately represent the status of the software as _it was released_. A person may be able to re-license software under the CC-0 license. However that person shouldn't change the fact that the original authors chose 'public domain' when they released their software, nor would it make sense to try to erase the original authorship information. CC-0 existed when the original authors made this choice, and they did not choose CC-0, and thus selecting CC-0 is incorrect. Correctly representing the release terms is the goal of this issue. My contributions on top of the released software are also intended to be in the public domain. This is becuase I want to ensure that my enhancements can be accepted by the upstream authors under the same terms as their original release: a public domain dedication. Ensuring that there is accurate metadata which reflects the _author's_ public domain declaration is the purpose of this issue.

As already stated, I don't really see a point, why Codeberg wouldn't want to offer the option "Public Domain".
It's a viable option for many users, just not for EU-based users, but Codeberg should trust its users that they select the most suitable option - I would argue.
So I also don't see a point where I want to add an extra checkbox or something. Maybe, just add some information regarding this topic into the licensing-documentation at some time, but you ought to be careful with this as it's
a. a law topic and we're not lawyers
b. it's also a controversial topic.

I just wanted to pinpoint, in my last reply, that your linked resource on PD in European law might not be totally accurate. That people that come across this discussion keep in mind, that PD is a difficult topic at least sometimes.

As already stated, I don't really see a point, why Codeberg wouldn't want to offer the option "Public Domain". It's a viable option for many users, just not for EU-based users, but Codeberg should trust its users that they select the most suitable option - I would argue. So I also don't see a point where I want to add an extra checkbox or something. Maybe, just add some information regarding this topic into the [licensing-documentation](https://docs.codeberg.org/getting-started/licensing/) at some time, but you ought to be careful with this as it's a. a law topic and we're not lawyers b. it's also a controversial topic. I just wanted to pinpoint, in my last reply, that your linked resource on PD in European law might not be totally accurate. That people that come across this discussion keep in mind, that *PD* is a difficult topic at least sometimes.
Poster

There is probably general agreement that the public domain is a viable option somewhere on Earth. That's at least one reason to add it to the optional metadata. There is some debate about how it might be implemented. I don't feel strongly about implementation. What matters to me is that the facts about the repository are represented in a useful, and correct manner. The public domain exists conceptually, software is released in the public domain in a given context, and any repository metadata should reflect these facts.

We perhaps don't all agree on the legal analysis regarding EU-based users. However, when we begin to discuss users' usage rights, we are discussing different matters than the original intention of this issue which is very narrow: expressing an author's public domain declaration accurately in Codeberg's repository metadata.

If we were to assume that public domain code is somehow problematic, which I do not assume normally, it follows that it is even more important to ensure that the metadata is correct. This enhancement would enhance the ability of all concerned parties to avoid reading code that they may consider problematic from their perspective.

The linked resource seems accurate enough to me.

For example: the droit d'auteur philosophy comment above is addressed in the Does the public domain exist in Europe too? section of the text. The linked resource states clearly that some rights cannot be waived in Europe.

Is there something specific that seems inaccurate in the linked analysis?

There is probably general agreement that the public domain is a viable option _somewhere_ on Earth. That's at least one reason to add it to the _optional_ metadata. There is some debate about how it might be implemented. I don't feel strongly about implementation. What matters to me is that the facts about the repository are represented in a useful, and correct manner. The public domain exists conceptually, software is released in the public domain in a given context, and any repository metadata should reflect these facts. We perhaps don't all agree on the legal analysis regarding EU-based _users_. However, when we begin to discuss users' usage rights, we are discussing different matters than the original intention of this issue which is very narrow: expressing an _author's_ public domain declaration accurately in Codeberg's repository metadata. If we were to assume that public domain code is somehow problematic, which I do not assume normally, it follows that it is even _more_ important to ensure that the metadata is correct. This enhancement would enhance the ability of all concerned parties to avoid reading code that they may consider problematic from their perspective. The linked resource seems accurate enough to me. For example: the _droit d'auteur_ philosophy comment above is addressed in the _Does the public domain exist in Europe too?_ section of the text. The linked resource states clearly that some rights cannot be waived in Europe. Is there something specific that seems inaccurate in the linked analysis?

@io thanks for opening this issue 👍 as a maintainer of one of the projects returned in your search query I recall wishing to have had the PD license metadata available when creating projects.

It appears that the WTFPL is offered, as well the Unlicense in the metadata which AFAICT are similar in spirit- despite not being a legal wonk.

As a creator of both code and non-code things, who is also somewhat of a copyright abolitionist, I have appreciated Github's offering a PD license and it only seems reasonable Codeberg would offer this as well.

@io thanks for opening this issue 👍 as a maintainer of [one of the projects](https://codeberg.org/eotl/creations) returned in your [search query](https://codeberg.org/explore/repos?q=public+domain) I recall wishing to have had the PD license metadata available when creating projects. It appears that the [WTFPL](http://www.wtfpl.net) is offered, as well the [Unlicense](https://unlicense.org) in the metadata which AFAICT are similar in spirit- despite not being a legal wonk. As a creator of both code and non-code things, who is also somewhat of a copyright abolitionist, ~~I have appreciated Github's offering a PD license and~~ it only seems reasonable Codeberg would offer this as well.

Apologies, I was mistaken there does not appear to be a PD license in GitHub's templates, but I am 100% and certain that I have selected Public Domain from a dropdown on some centralized asset hosting tool in the past.

I do recall The Noun Project explicitely offers this. TNP is a well made platform which offers designers a distribution channel to both receive commercial royalities as well as release their icons into the Public Domain. Their solution is similar to what @io proposes above.

Apologies, I was mistaken there *does not* appear to be a PD license in GitHub's templates, but I am 100% and certain that I have selected `Public Domain` from a dropdown on some centralized asset hosting tool in the past. I do recall [The Noun Project](https://thenounproject.com) explicitely offers this. TNP is a well made platform which offers designers a distribution channel to *both* receive commercial royalities as well as release their icons into the Public Domain. Their solution is similar to what @io proposes above.

Maybe the term "public domain" should not be used here. Better to dreate a simple "do what you want" licence, which includes a statement "I garantee, thath this code is either my own work or it does only contain third party code which has been released under this same license or compatible: Do what you want with it.".

Maybe the term "public domain" should not be used here. Better to dreate a simple "do what you want" licence, which includes a statement "I garantee, thath this code is either my own work or it does only contain third party code which has been released under this same license or compatible: Do what you want with it.".
Sign in to join this conversation.
No Milestone
No Assignees
6 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Codeberg/Community#701
Loading…
There is no content yet.