I really appreciate that the Julia registrator enforces a liberal Open Source license on packages. However, I’ve run into a problem. As a US Government employee, I’m required by Title 17 United States Code Section 105 to release my work into the public domain without a copyright. This is the license I’m expected to use:
This software was developed by employees of the National Institute of Standards
and Technology (NIST), an agency of the Federal Government and is being made
available as a public service. Pursuant to title 17 United States Code Section
105, works of NIST employees are not subject to copyright protection in the
United States. This software may be subject to foreign copyright. Permission
in the United States and in foreign countries, to the extent that NIST may hold
copyright, to use, copy, modify, create derivative works, and distribute this
software and its documentation without fee is hereby granted on a non-exclusive
basis, provided that this notice and disclaimer of warranty appears in all copies.
THE SOFTWARE IS PROVIDED ‘AS IS’ WITHOUT ANY WARRANTY OF ANY KIND, EITHER
EXPRESSED, IMPLIED, OR STATUTORY, INCLUDING, BUT NOT LIMITED TO, ANY WARRANTY
THAT THE SOFTWARE WILL CONFORM TO SPECIFICATIONS, ANY IMPLIED WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND FREEDOM FROM INFRINGEMENT,
AND ANY WARRANTY THAT THE DOCUMENTATION WILL CONFORM TO THE SOFTWARE, OR ANY
WARRANTY THAT THE SOFTWARE WILL BE ERROR FREE. IN NO EVENT SHALL NIST BE LIABLE
FOR ANY DAMAGES, INCLUDING, BUT NOT LIMITED TO, DIRECT, INDIRECT, SPECIAL OR
CONSEQUENTIAL DAMAGES, ARISING OUT OF, RESULTING FROM, OR IN ANY WAY CONNECTED
WITH THIS SOFTWARE, WHETHER OR NOT BASED UPON WARRANTY, CONTRACT, TORT, OR
OTHERWISE, WHETHER OR NOT INJURY WAS SUSTAINED BY PERSONS OR PROPERTY OR OTHERWISE,
AND WHETHER OR NOT LOSS WAS SUSTAINED FROM, OR AROSE OUT OF THE RESULTS OF, OR USE
OF, THE SOFTWARE OR SERVICES PROVIDED HEREUNDER.It would seem to conform to the ideals that Julia’s licensing requirements promote but is, none-the-less, not permitted by the package registrator because it only accepts a limited number of Open Source Initiative licenses. I can’t be the only Fed to have run into this issue.
Would the Julia overlords be willing to consider adding an exception for Title 19 licenses?
Activity
21I would also recommend submitting this license for review by OSI: https://opensource.org/approval
The fact is that we do automatic license detection using licensecheck, and we don't really want to deal with exceptions, that's extra burden for the maintainers
As an alternative, would NIST consider incorporating a standard license, along the lines of:
Pursuant to title 17, this software is not copyrighted blah blah blah. But to the extent that it is copyrighted, permission is granted according to [...1-clause BSD...]
? License proliferation is usually a bad thing for everyone.
licensecheck apparently uses the SPDX License List, which seems to be based on the OSI list and the FSF list.
I already mentioned that you should submit this license to OSI if you want to use it. You/NIST should also contact licensing@fsf.org to get onto their approved-license list.
(I'm guessing that both of them will probably try to convince NIST to incorporate a standard license (e.g. 1BSD) with a preamble about title 17, but they are probably also sympathetic to the Title-17 public-domain requirement.)
Can it be dual-licensed? Perhaps it can be licensed under both the title-17 license and another license like 1BSD or MIT? (My understanding is that dual licensing allows the user to choose which license they want to use the code with). Our current checks would allow that without needing manual exemptions.
edit: but long-term it would be good to get it upstreamed to OSI etc
The license I use is in the SPDX License List - NIST-PD-fallback
I (or heaven forbid, one of our lawyers) can contact licensing@fsf.org. However, FSF won't be able to convince NIST to use a different license. This is the one we are legislated to use.
So looking at https://github.com/JuliaRegistries/General/pull/48131#issuecomment-960666031, licensecheck was able to identify the license as NIST-PD-fallback as you pointed out. That license is not OSI-approved, so even though RegistryCI could identify the license, it failed our check. So contacting the FSF probably wouldn't help much, the thing we need (according to our existing policies at least) is for it to be OSI-approved, or for the package to be otherwise usable under an OSI-approved license (e.g. by dual licensing).
Or to convince folks here to change our policy to "must be OSI-approved or NIST-PD-fallback". But the whole point of us just using the OSI list is that we aren't lawyers and don't want to negotiate individual licenses.
I think dual-licensing is the easiest approach here, right?
I can understand your desire to outsource the lawyering. Can you point me to an example of a dual-licensed package?
Aye. NIST-PD-fallback isn't an OSI-approved license or one that licensee detects. There shouldn't be any issue with dual-licensing here. You might want to check which OSI-approved / licensee-detected license matches the NIST-PD-fallback specifics most closely and use that one for the LICENSE after checking with your agency. Then you could include a note that it is dual-licensed with NIST-PD-fallback and the link to the text and same meta (copyright holder or lack of it / year).
However, inspecting the text, it seems the biggest term is the inclusion of the notice. Apache-2 for example allows for the requirement of a notice to be included in distribution so you could include the text of NIST-PD-fallback under a NOTICE file to meet that requirement for instance.
The problem I run into with dual licensing is that the NIST-PD-fallback states that the work is "not subject to copyright protection in the United States" Without a copyright, I can't apply a license. When congress passed the law many years ago (pre-Open Source licensing), it intended that Federal government employees work be maximally available for reuse. They assumed that putting the work in the "public domain" by forbidding a copyright would do this.
(BTW, I'm not a lawyer so I'm just repeating the guidance I get from NIST's lawyers.)
I think the distinction is in protection, meaning that y'all still has the copyright rights but that can't seek remedy at a US court for infringement as those protections fall under the special federal law. Still, it is interesting to see the effect here. I might reach out to my colleagues at my agency (BEA) to see if they have any thoughts on this. I don't think BEA has the same applicable rules as far as I know, but maybe we do.
Thanks to each of you for the advice. I'll look into this further on my end.
@jcastle, could offer some input from GSA or code.gov that might help us better understand the situation?
We have reached out to a few folks at FCSM to try to get you something useful. From what I gathered, for journal publications the copyrights are transferred to comply with the law even before current text. USPTO is also looped to try to get a good picture. All that said, @NicholasWMRitchie, thanks for bringing this to our attention.
FWIW, The Unlicense is a public-domain dedication that is OSI approved in case that's acceptable to NIST https://opensource.org/licenses/Unlicense
As a US Government employee, I’m required by Title 17 United States Code Section 105 to release my work into the public domain without a copyright. This is the license I’m expected to use:
I'm a bit confused about this part. Is it public domain or not? If it's public domain then no license is required. Putting the license on there is nice in that it guarantees certain rights, but it isn't necessary, just as no license is required to quote or reproduce Shakespeare plays. Anyone can put any license they want on the package, including the Unlicense or MIT or whatever (and anyone else can also do the same). The Unlicense seems the closest to being a license that expresses that it is public domain.
Is it public domain or not? If it's public domain then no license is required.
As the NIST "license" states, it's public domain in the US, but it's possible that it's copyrighted in other countries, so they include a "fallback" license just in case.
You could potentially dual license with the same caveat: "Any portion of this work by NIST employees is public domain in the US because of Title 17 blah blah, but to the extent that it is copyrighted anywhere in the world we release it under the following license: ..."
Note also that you still need a license if you accept nontrivial patches from anyone outside of NIST, since those patches are copyrighted (by default).
I don't think https://www.law.cornell.edu/uscode/text/17/105 describes "public domain" as commonly understood. Especially after reading the annotations from the US House report or 106-107. It would probably be best to wait a bit to see what guidance we get at our agencies.
Looks fine to me. To the extent that a copyright exists, its wording is almost identical to the wording of 0-clause BSD, plus the warranty-disclaimer requirement which is similar to 1-clause BSD. Compare:
with