-
Notifications
You must be signed in to change notification settings - Fork 461
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Title 19 licenses #48137
Comments
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
|
I would also recommend submitting this license for review by OSI: https://opensource.org/approval |
The fact is that we do automatic license detection using |
As an alternative, would NIST consider incorporating a standard license, along the lines of:
? License proliferation is usually a bad thing for everyone. |
I already mentioned that you should submit this license to OSI if you want to use it. You/NIST should also contact (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 |
So looking at #48131 (comment), 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. However, inspecting the text, it seems the biggest term is the inclusion of the notice. |
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 |
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 |
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. |
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. |
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:
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?
The text was updated successfully, but these errors were encountered: