Use or Apply for SPDX Licence
Hi folks, It would be useful to distributions, packagers, and organization licence checkers if the tzcode and tzdata were covered by (a) Public Domain SPDX licence identifier(s) https://spdx.org/licenses/ e.g. CC-PDDC, PDDL, SAX-PD, Unlicense, WTFPL, etc. or applied for it's own e.g. IANA-TZ-PD. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.]
Quoting Brian Inglis on Saturday June 20, 2020:
It would be useful to distributions, packagers, and organization licence checkers if the tzcode and tzdata were covered by (a) Public Domain SPDX licence identifier(s) WTFPL, etc. or applied for it's own e.g. IANA-TZ-PD.
In response to a few different requests that the IANA registries have more explicit licensing, we've been working with the IETF and IETF Trust recently on developing an approach to licensing that preserves the current nature but makes it clear. We'll take this tagging into consideration. kim
On Jun 20, 2020, at 4:43 PM, Kim Davies <kim.davies@iana.org> wrote:
[EXTERNAL EMAIL]
Quoting Brian Inglis on Saturday June 20, 2020:
It would be useful to distributions, packagers, and organization licence checkers if the tzcode and tzdata were covered by (a) Public Domain SPDX licence identifier(s) WTFPL, etc. or applied for it's own e.g. IANA-TZ-PD.
In response to a few different requests that the IANA registries have more explicit licensing, we've been working with the IETF and IETF Trust recently on developing an approach to licensing that preserves the current nature but makes it clear. We'll take this tagging into consideration.
kim
I don't get it. Much of the material is marked "public domain". That has a precise meaning. Licenses are different from public domain. Why is anything needed here? paul
On 6/20/20 1:45 PM, Paul.Koning@dell.com wrote:
Why is anything needed here?
I guess it's for some sort of packaging software that wants to see a LICENSE file containing a bunch of strings like "CC-PDDC" and "BSD-3-Clause". Or maybe these strings would need to be in every source file? It's not clear. It would be helpful to know more details. What is the packaging software? How does that software work with tzdb now? Why would the change (whatever it is) save everybody time? If the IETF has a task force on this topic, perhaps we should wait for it to come to a conclusion before worrying about the issue.
On 2020-06-20 15:02, Paul Eggert wrote:
On 6/20/20 1:45 PM, Paul.Koning@dell.com wrote:
Why is anything needed here?
I guess it's for some sort of packaging software that wants to see a LICENSE file containing a bunch of strings like "CC-PDDC" and "BSD-3-Clause". Or maybe these strings would need to be in every source file? It's not clear.
See https://spdx.dev/about/ "The Software Package Data Exchange® (SPDX®) specification is a standard format for communicating the components, licenses and copyrights associated with software packages. The SPDX standard helps facilitate compliance with free and open source software licenses by standardizing the way license information is shared across the software supply chain. SPDX reduces redundant work by providing a common format for companies and communities to share important data about software licenses and copyrights, thereby streamlining and improving compliance. The SPDX specification is developed by the SPDX workgroup, which is hosted by the Linux Foundation. The grass-roots effort includes representatives from more than 20 organizations—software, systems and tool vendors, foundations and systems integrators—all committed to creating a standard for software package data exchange formats." also https://wiki.spdx.org/view/Legal_Team/Decisions/Dealing_with_Public_Domain_w... "The rules around “Public Domain” often vary or are unspecified jurisdiction to jurisdiction. Adding to the confusion, some jurisdictions may not even recognize the concept of “Public Domain” (or similar). As such, a license may nevertheless be required or implied in these cases. Even in the U.S., there is no clear, officially-sanctioned procedure for affirmatively placing copyright-eligible works into the “Public Domain” aside from natural statutory expiration of copyright. The bottom-line is, there are few if any objective, brightline rules for proactively placing copyright-eligible works into the Public Domain that we can broadly rely on." Public domain is not a legal concept in many countries outside the U.S., may not be recognized in some countries, is not a licence, conveys no rights, or may require payment of fees to the state or authors' societies (in Africa and South America, some of which have abolished them; recently proposed by Germany for Europe); see: https://en.wikipedia.org/wiki/Paying_public_domain [OT: I'm surprised more countries do not, although a number do have a private copying levy or royalty on sales of blank media and/or recording equipment (in some places, any device containing memory), as some percentage is deemed to be sold for use to copy published works; see https://en.wikipedia.org/wiki/Private_copying_levy ] Please consider the problems tz has using the definitive and timely IERS leap-seconds.list, due to lack of any explicit licence, having to wait until NIST generates their derivative release, as that is a US government derived product in the public domain.
It would be helpful to know more details. What is the packaging software? How does that software work with tzdb now? Why would the change (whatever it is) save everybody time?
SPDX is under the Linux Foundation, and Linux has now been plastered with SPDX labels in all source files, and other projects are adding them, to reduce the effort of replying to compliance/risk management and other queries from supply chain managers: keeping product acquisition staff busy working from home.
If the IETF has a task force on this topic, perhaps we should wait for it to come to a conclusion before worrying about the issue.
See: https://trustee.ietf.org/trust-legal-provisions.html https://trustee.ietf.org/license-info/IETF-TLP-5.htm https://trustee.ietf.org/copyright-faq.html https://tools.ietf.org/html/rfc5377 https://tools.ietf.org/html/rfc5378 and normative and informative references included therein. It appears from these documents that the IETF legal team (so far) have a narrow focus on IETF documents and U.S. Copyright law, and fail to address the situation elsewhere, beyond acknowledging consideration of the Berne convention. FAQ 1.11 "No license is needed to use or modify public domain documents. However, given the complexity of determining whether or not a particular document is in the public domain, the IETF Trust does not seek to differentiate between public domain and non-public domain documents. Thus, the same assurances are requested, and the same licenses are granted, for all documents. In the case of public domain documents, however, your rights may be greater than those granted under the IETF Trust’s outbound license." That applies only in the U.S. and not the parts of the rest of the world where PD is unrecognized. Kim Davies said only that SPDX tagging would be taken into consideration by the IETF, not that licensing of PD content would be treated any differently to other IETF content, and whether tz content may be considered IETF content (under BSD simplified), handled under an alternate stream, or considered independent, so not considered by the IETF (I'd bet on this option). It would useful to know where information about this topic by the IETF is being posted, as: https://mailarchive.ietf.org/arch/browse/tlp-interest/ shows no (relevant) activity since 2015. As there are concerns about IERS leap-seconds.list on this list, European and other country product compliance/risk management/supply chain staff have concerns about tz content. So list members involved in such concerns may want to make those known. And it is normally better to get ahead of the requests, before product compliance/risk management/supply chain folks work their way down to emailing this list. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.]
On 6/21/20 8:26 AM, Brian Inglis wrote:
SPDX is under the Linux Foundation, and Linux has now been plastered with SPDX labels in all source files, and other projects are adding them, to reduce the effort of replying to compliance/risk management and other queries from supply chain managers: keeping product acquisition staff busy working from home.
I just checked, and the string "SPDX" is in about 26% of Linux source files, so apparently SPDX labeling is typically not needed universally even within its home project. From the Linux point of view, perhaps tzdb source could also fall under the category of "labeling not needed". Also, I'm not seeing many questions from compliance/risk management people on this mailing list - after all, the LICENSE file is pretty clear to anybody who does this sort of thing for a living - so perhaps the need for SPDX labeling is not so great for tzdb.
As there are concerns about IERS leap-seconds.list on this list, European and other country product compliance/risk management/supply chain staff have concerns about tz content.
Fair enough, but SPDX tagging won't solve that problem, just as the lack of SPDX tagging in the IERS leap-seconds.list isn't the fundamental problem that we have with using that file. One of my worries here is that SPDX tagging will give people even more arguments to sue me and/or the IANA. The SPDX website keeps saying things like "Certifier recognizes that his good faith efforts may not shield him from liability if in fact the work certified is not in the public domain." This leads me to think that I don't want to be an SPDX certifier, and would rather that somebody else take the additional legal liability that would arise from SPDX tagging. I've already been sued one time too many for my volunteer work.
On Jun 21, 2020, at 2:18 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
... One of my worries here is that SPDX tagging will give people even more arguments to sue me and/or the IANA. The SPDX website keeps saying things like "Certifier recognizes that his good faith efforts may not shield him from liability if in fact the work certified is not in the public domain." This leads me to think that I don't want to be an SPDX certifier, and would rather that somebody else take the additional legal liability that would arise from SPDX tagging. I've already been sued one time too many for my volunteer work.
Indeed. Given wording like that, US residents at least would be wise to run far and fast whenever this notion is proposed. It may be that other countries have more sane judicial systems. If so, someone from one of those countries might volunteer to put on the tag. paul
On 2020-06-21 13:00, Paul.Koning@dell.com wrote:
On Jun 21, 2020, at 2:18 PM, Paul Eggert wrote: One of my worries here is that SPDX tagging will give people even more arguments to sue me and/or the IANA. The SPDX website keeps saying things like "Certifier recognizes that his good faith efforts may not shield him from liability if in fact the work certified is not in the public domain." This leads me to think that I don't want to be an SPDX certifier, and would rather that somebody else take the additional legal liability that would arise from SPDX tagging. I've already been sued one time too many for my volunteer work.
Fair enough: once bitten, twice shy, and all that. That looks like a warning, similar to those regarding patents and so-called "Intellectual Property", that may be inadvertently included in IETF documents, that you agreed to when you submitted RFCs. If you adopted one of the existing PD licences, you would just be using those licences, terms, and labels.
Indeed. Given wording like that, US residents at least would be wise to run far and fast whenever this notion is proposed. It may be that other countries have more sane judicial systems. If so, someone from one of those countries might volunteer to put on the tag.
Judicial systems, maybe some cases; legal and legislative systems: nah; they all have trade offs built in. The suggestion was to adopt a PD licence that is in effect for these works outside the US; and an easy to use label for those. Those licences, terms, and labels already exist for use with the non-PD components. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.]
Date: Sun, 21 Jun 2020 13:49:13 -0600 From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca> Message-ID: <59a09579-b68a-d6a6-845d-214722d70dba@SystematicSw.ab.ca> | The suggestion was to adopt a PD licence The problem is, that while anyone can offer a licence for anything (possibly subject to fraud issues), doing so on something that you do not own is pointless, and ineffectual (at best). It has already been established I think (at least in the US) that the data part of tz* consists of facts, not subject to copyright, the form in which it is presented might be, but who exactly owns that? For the code, you'd have to (somehow) discover who created each specific piece, the compilation might be potentially subject to a separate copyright (in some jurisdictions) but anyone worried about that part would simply take the pieces, and put them back together themselves. So, Brian, if you believe that there should be a licence with the tz* code 7 data, why don't you offer one? You're as good a a source as just about anyone else I can think of. kre
In many countries it is not possible (or is unclear if it is possible) to put a work into the public domain and grant all rights. Some licenses, such as CC0, are designed so that even if putting works into the public domain is invalid users will still have all rights afforded as if it were in the public domain. Artemis -- Artemis Tosini me@artem.ist Am Sa, 20. Jun 2020, um 20:45, schrieb Paul.Koning@dell.com:
On Jun 20, 2020, at 4:43 PM, Kim Davies <kim.davies@iana.org> wrote:
[EXTERNAL EMAIL]
Quoting Brian Inglis on Saturday June 20, 2020:
It would be useful to distributions, packagers, and organization licence checkers if the tzcode and tzdata were covered by (a) Public Domain SPDX licence identifier(s) WTFPL, etc. or applied for it's own e.g. IANA-TZ-PD.
In response to a few different requests that the IANA registries have more explicit licensing, we've been working with the IETF and IETF Trust recently on developing an approach to licensing that preserves the current nature but makes it clear. We'll take this tagging into consideration.
kim
I don't get it. Much of the material is marked "public domain". That has a precise meaning. Licenses are different from public domain. Why is anything needed here?
paul
"Artemis Tosini" <me@artem.ist> writes:
In many countries it is not possible (or is unclear if it is possible) to put a work into the public domain and grant all rights. Some licenses, such as CC0, are designed so that even if putting works into the public domain is invalid users will still have all rights afforded as if it were in the public domain.
However, given that all of the people who have historically submitted commentary or other patches that have been incorporated into tz did not agree to the CC0 license explicitly or implicitly (the license postdates much of this work), it's hard to see how anyone could reasonably claim that tz is under such a license. There is a large grey-area assumption with most free software packages that do not do either copyright assignment or CLAs that people contributing patches are doing so under the prevailing license of the thing to which they're contributing at the time and cannot reasonably object to their work being redistributed under that license. That license for tz has been stated for some time to be "public domain" and prior to that was left largely unstated. Despite all the issues with the "public domain" concept in international copyright law, I doubt claiming some other license now would be on any firmer legal ground. The practical reality is that it's highly unlikely that anyone is going to assert copyright rights over material in the tz distribution (to the extent that it's copyrightable at all, which is probably limited to the code and the commentary), and if they do, the details of the case seem likely to turn on elements other than the license statement. Lawyers may not be happy about the uncertainty and may want to transfer that uncertainty to some other party with some legal document. If I were Paul, I wouldn't want any part in that. There's essentially no upside for him as maintainer to accept any responsibility or liability for the uncertainty. If IANA wants to take on some of the legal uncertainty, well, at least have legal counsel to advise on the merits of and tactics for doing so. -- Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>
On 2020-06-21 04:45:06 (+0800), Paul.Koning@dell.com wrote:
On Jun 20, 2020, at 4:43 PM, Kim Davies <kim.davies@iana.org> wrote:
Quoting Brian Inglis on Saturday June 20, 2020:
It would be useful to distributions, packagers, and organization licence checkers if the tzcode and tzdata were covered by (a) Public Domain SPDX licence identifier(s) WTFPL, etc. or applied for it's own e.g. IANA-TZ-PD.
In response to a few different requests that the IANA registries have more explicit licensing, we've been working with the IETF and IETF Trust recently on developing an approach to licensing that preserves the current nature but makes it clear. We'll take this tagging into consideration.
I don't get it. Much of the material is marked "public domain". That has a precise meaning. Licenses are different from public domain. Why is anything needed here?
As others have pointed out, while the concept of public domain is reasonably well-defined in the US and similar legal systems, it's rather more nebulous in many (most?) parts of the world. Many European countries, for example, make a distinction between "copyright" and "moral rights". While copyright can be assigned or licensed (and sometimes opted out), there are no (or few) such provisions for other rights. A CC0 or similar tag would make it more clear that the authors/contributors expect no rights to their contributions even when they are subject to legal systems that don't have a formally defined public domain. Unfortunately, I don't think it's practical to retroactively apply a CC0 tag. Formally, you'd need each individual contributor to agree. Given the age of the tz project, this may be impossible. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
"Philip Paeps" <philip@trouble.is> writes:
Unfortunately, I don't think it's practical to retroactively apply a CC0 tag. Formally, you'd need each individual contributor to agree. Given the age of the tz project, this may be impossible.
Yeah, that. FWIW, we've had roughly comparable discussions in the Postgres project. The existing PG copyright is a mess: it's sloppily worded and it protects nobody except the University of California. But we've concluded that changing it is effectively impossible, because there's no way to get the concurrence of every past contributor. And that conclusion was arrived at in 2000 ... so it'd be that much worse now. In practice, the amount of interest in changing the license wording has dropped to about nothing since 2000, too. People are far more used to the concept of community-owned open source code than they were then, and the fact that the governing document is loosely phrased bothers nobody now other than perhaps some bean-counters. In short, I think politely ignoring SPDX is the right thing to do. It's trying to solve a problem that was real enough twenty years ago, but people have gotten over it. regards, tom lane
On Mon, 2020-06-22 at 22:51 -0400, Tom Lane wrote:
"Philip Paeps" <philip@trouble.is> writes:
Unfortunately, I don't think it's practical to retroactively apply a CC0 tag. Formally, you'd need each individual contributor to agree. Given the age of the tz project, this may be impossible.
Yeah, that.
FWIW, we've had roughly comparable discussions in the Postgres project. The existing PG copyright is a mess: it's sloppily worded and it protects nobody except the University of California. But we've concluded that changing it is effectively impossible, because there's no way to get the concurrence of every past contributor. And that conclusion was arrived at in 2000 ... so it'd be that much worse now.
In practice, the amount of interest in changing the license wording has dropped to about nothing since 2000, too. People are far more used to the concept of community-owned open source code than they were then, and the fact that the governing document is loosely phrased bothers nobody now other than perhaps some bean-counters.
In short, I think politely ignoring SPDX is the right thing to do. It's trying to solve a problem that was real enough twenty years ago, but people have gotten over it.
regards, tom lane
Actually, the point of SPDX is to create unique tags for existing licenses, not to create or change the licenses that a project is released under. This is meant to make identification of licenses used easier to identify in a more consistent way. Think automation. As a matter of fact Postgresql already has a SPDX tag. :) https://spdx.org/licenses/PostgreSQL.html For an example of how SPDX might be used you can look at Opensuse. The rpm spec files are expected to have an SPDX tag for the License value. https://en.opensuse.org/openSUSE:Packaging_guidelines#Spec_Files As the Packaging Guidelines state, the SPDX is "relatively" new so there aren't valid tags for all licenses yet. It looks like currently Opensuse marks the timezone rpms as "BSD-3-Clause AND SUSE-Public- Domain" https://build.opensuse.org/package/view_file/Base:System/timezone/timez one.spec?expand=1 Ralph Schaffner
On 2020-06-23 01:22, Ralph Schaffner wrote:
On Mon, 2020-06-22 at 22:51 -0400, Tom Lane wrote:
"Philip Paeps" <philip@trouble.is> writes:
Unfortunately, I don't think it's practical to retroactively apply a CC0 tag. Formally, you'd need each individual contributor to agree. Given the age of the tz project, this may be impossible.
Yeah, that. FWIW, we've had roughly comparable discussions in the Postgres project. The existing PG copyright is a mess: it's sloppily worded and it protects nobody except the University of California. But we've concluded that changing it is effectively impossible, because there's no way to get the concurrence of every past contributor. And that conclusion was arrived at in 2000 ... so it'd be that much worse now. In practice, the amount of interest in changing the license wording has dropped to about nothing since 2000, too. People are far more used to the concept of community-owned open source code than they were then, and the fact that the governing document is loosely phrased bothers nobody now other than perhaps some bean-counters. In short, I think politely ignoring SPDX is the right thing to do. It's trying to solve a problem that was real enough twenty years ago, but people have gotten over it.
I suspect that it may be driven by the FSF Licensing & Compliance Team or others similarly following up on GPL, and possibly other, licence violations, like not including copies of licences or not making all open source available.
Actually, the point of SPDX is to create unique tags for existing licenses, not to create or change the licenses that a project is released under. This is meant to make identification of licenses used easier to identify in a more consistent way. Think automation.
As a matter of fact Postgresql already has a SPDX tag. :) https://spdx.org/licenses/PostgreSQL.html
For an example of how SPDX might be used you can look at Opensuse. The rpm spec files are expected to have an SPDX tag for the License value.
https://en.opensuse.org/openSUSE:Packaging_guidelines#Spec_Files
As the Packaging Guidelines state, the SPDX is "relatively" new so there aren't valid tags for all licenses yet. It looks like currently Opensuse marks the timezone rpms as "BSD-3-Clause AND SUSE-Public- Domain"
https://build.opensuse.org/package/view_file/Base:System/timezone/timez one.spec?expand=1
CC0 could be better but I have the same reservations about the effectiveness and validity of making such changes as stated above. This project could add a comment SPDX-License-Identifier: BSD-3-Clause when date.c, newstrftime.3, or strftime.c are modified, and as SUSE-Public-Domain is not listed at the SPDX site, on a similar basis, add comment SPDX-License-Identifier: LicenceRef-IANA-TZ-Public-Domain, as any other files are modified in this project. The project repos and tzcode sources should probably also include or reference a copy of the BSD-3-Clause licence. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.]
participants (10)
-
Artemis Tosini -
Brian Inglis -
Kim Davies -
Paul Eggert -
Paul.Koning＠dell.com -
Philip Paeps -
Ralph Schaffner -
Robert Elz -
Russ Allbery -
Tom Lane