On 3/2/2020 2:04 PM, Karan, Cem F CIV USARMY CCDC ARL (USA) via License-discuss wrote: >> -----Original Message----- >> From: Richard Fontana <rfont...@redhat.com> >> Sent: Saturday, February 29, 2020 2:07 PM >> To: mc...@lexpan.law; license-discuss@lists.opensource.org >> Cc: Karan, Cem F CIV USARMY CCDC ARL (USA) <cem.f.karan....@mail.mil> >> Subject: Re: [License-discuss] [Non-DoD Source] Re: Resources to discourage >> governments from bespoke licenses? >> >> On Fri, Feb 28, 2020 at 5:25 PM McCoy Smith <mc...@lexpan.law> wrote: >>>>> -----Original Message----- >>>>> From: Karan, Cem F CIV USARMY CCDC ARL (USA) >>>>> <cem.f.karan....@mail.mil> >>>>> Sent: Friday, February 28, 2020 12:39 PM >>>>> To: mc...@lexpan.law; license-discuss@lists.opensource.org >>>>> Subject: RE: [License-discuss] [Non-DoD Source] Re: Resources to >>>>> discourage governments from bespoke licenses? >>>>> Hmmm... OK, I remember that a NOSA 3.0 was being drafted at one time, and >>>>> I know it got put up on the list. Does anyone want me >> to go poke at the NASA lawyers to see if they'll push on NOSA 3.0 >>again? >> Alternatively, does anyone want to push on Congress to do >> something about copyright law so that the US Government can use the >> standard, already approved licenses? >>> Are you sure about that? I've scanned the archives and don't see anything >>> about a NOSA 3.0. Just about 2.0. And 2.0 was never >> approved; the only approved version is 1.3. The last discussion on NOSA 2.0 >> was around June of 2018. >> >> My recollection is that the NASA lawyer mentioned working on a NOSA >> 3.0 but this version was never submitted for OSI approval and I'm not aware >> of it being used publicly. I think the various version numbers >> of NOSA are getting confused in this and other recent threads. > Yes, I'm sorry for causing confusion. I was talking the NASA guys a fair > amount a couple of years back about NOSA 3.0 which was supposed to address > issues with 1.3 and 2.0, but I think that as Nigel has explained, they just > plain got tired of trying (and I got the versions mixed up in my mind). The > law is quite clear that US Government works do not have copyright within the > US. I think that there are other conditions that affect the Government, but > not private citizens, which were also supposed to be addressed in NOSA 3.0, > but I'm not sure about that (both because it's been a long time, and because > I'm not a lawyer, so don't remember the details). Given that, the NOSA > licenses are a good idea for Government Open Source Software (GOSS). > > That said, I am willing to talk with NASA about submitting whichever version > of NOSA they have (2.0 or 3.0) provided all of the following are true: > > - All critique of the licenses have clear, actionable steps towards > correction, or if there is no way to correct the deficiency, a clear > explanation of what the issue is, and why it can't be corrected. > - That the entire process from initial submission to final voting take no > more than 90 days. Formal rejection is fine by me, but I'd like it to be > clear that it is rejected, rather than just ignored. > > Is this acceptable to everyone? Does everyone want me to talk with NASA? Hi Cem,
I can't promise the timing, but the instructions for license review do describe process and the goal for the length of pendency. https://opensource.org/approval That's the process we'll follow for any license submitted. As to critique, the difficulty is that the review is done collaborative and people express their individual opinions, but you can't really tell what is something that the OSI Board considers an issue and what it doesn't. Personally I wait to see all the viewpoints before I reach my own conclusion and I'm sure other Board members are the same. So the process may involve some crystal ball reading on the part of the drafters, trying to figure out what criticisms need to be addressed and which can be ignored. I would say if it's an unintended loophole or vagueness, then it's always good practice to revise it so that the document is as clear and accurate as possible. Sometimes it's a matter of the license submitter explaining where someone has misunderstood the license. If it's a philosophical disagreement, that's going to depend on what the issue is and whether it's something that the drafters can and are willing to change. After the review period, the License Committee makes a recommendation to the full Board in a very complete rationale document. You can see two examples, one not recommending approval of the first version of the CAL license here: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-June/004248.html and the second approving the second version here: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004660.html The full Board then votes on the recommendation. A rationale document not approving the license is going to be the best way to understand what would need to be addressed in a resubmission. Van Lindberg might be able to help you navigate the process; he just went through it with the CAL license and I suspect it was a learning process for him. He can probably give you some tips. Pam Pamela Chestek Chair, License Review Committee Open Source Initiative _______________________________________________ License-discuss mailing list License-discuss@lists.opensource.org http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org