[License-discuss] [Non-DoD Source] A new USG License

Tue Mar 31 14:16:22 UTC 2020

McCoy, if you're willing to talk with Diane, I'd appreciate it!  I did talk with her quite a while ago about the USG's issues, but nothing much came of the interaction (she seemed very, very busy at the time).  If you're able to continue the discussions, I would be very interested in seeing where they went.  Note that I'm no longer the lead person at ARL regarding OSS, so I can only be interested in my personal capacity (although if things seem to be heading in the right direction, I can ping all the right people from my end).

That said, I'm only willing to push on my end **if** the OSI is willing to seriously consider the USG's predicament, and willing to accept that a new license may be necessary.  Ideally this would be a better version of NOSA, one that everyone can accept, but I personally don't care what license is used as long as it solves all the major issues.  Otherwise we're back at the same impasse that we've been at for some time.

Thanks,
Cem Karan

________________________________
From: McCoy Smith [mccoy at lexpan.law]
Sent: Monday, March 30, 2020 5:08 PM
To: license-discuss at lists.opensource.org
Cc: 'Nigel T'; Karan, Cem F CIV USARMY CCDC ARL (USA)
Subject: [Non-DoD Source] A new USG License

All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser.

________________________________

From: Richard Fontana <rfontana at redhat.com>
Sent: Saturday, February 29, 2020 11:42 AM
To: mccoy at lexpan.law; license-discuss at lists.opensource.org
Cc: Nigel T <nigel.2048 at gmail.com>
Subject: Re: [License-discuss] [Non-DoD Source] Re: Resources to discourage governments from bespoke licenses?

NOSA 2.0 was not rejected as such -- the definitive statement by the OSI board was in November 2017:

"Resolved, That, in view of the length, complexity, and ambiguities in the submitted drafts of the NASA Open Source Agreement version 2.0, it is the opinion of the OSI that the conformance of NOSA 2.0 to the OSD cannot be assured. OSI thus can neither approve nor reject the license, and NASA is invited to submit a new draft of NOSA for consideration by the OSI."

Caution-http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2017-November/003309.html < Caution-http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2017-November/003309.html >

Nigel, I am sorry you are still so angry about how NOSA 2.0 was dealt with. In retrospect I would have tried to convince the OSI board to reject the license outright early on. I would say that, until a year or so ago, the OSI board was reluctant to formally reject any submitted licenses, not as a matter of formal policy or anything, but rather as a kind of institutional custom, although earlier in OSI's history there were apparently a few outright rejections.

It's also worth remembering that the OSI streamlined its license review process last year in large part because of the experience with the NOSA 2.0 submission.

Now that the Board election is over, thought I’d give my two cents on this [when I was a candidate for the Board, I didn’t think discussing this was a good idea; now that I’m not, I’m back to just a regular-old frequent list commentator, so not in any way associated with decisions of the Board].

I’d like to see NOSA 2.0 (or 3.0 if that indeed exists) resubmitted for approval on license-approval.   The history on it is just too murky to me and I’m of the opinion that license approvals or disapprovals (or withdrawals in the face of disapproval) ought to be clearer.  The new process improvements I think are a step in the right direction, and I think it would be beneficial to have NOSA x.0 go through that process.

To me, that license is a good candidate for reconsideration because:

  1.  It is designed to be an improved version of an existing OSI approved license (Caution-https://opensource.org/licenses/NASA-1.3 < Caution-https://opensource.org/licenses/NASA-1.3 > ).  OSI should always be biased toward giving additional consideration of improved versions of already-approved licenses, as it’s a good way to fix problems with the old version, particularly when an old version may have gotten approved with some OSD conformance issues that can be fixed in the new version.
  2.  If there is a version 3.0 that may have addressed issues that were raised with 2.0, that ought to be considered afresh, without any of the concerns raised with 2.0 impacting approval (unless the problems that were identified with 2.0 continue into 3.0).
  3.  OSI should be particularly receptive to the USG’s desire to adopt or produce more open source code (AFAIK, USG is the biggest single consumer of software in the world), and taking the extra step to help facilitate their adoption or use should be encouraged.

Also, at one point in the thread on USG licensing, someone (I think it was Cem) indicated that something like CC0 (with a public domain dedication for copyright, with a highly permissive license backstop for jurisdictions where public domain dedications were not recognized or legally problematic), but that because CC0 is not an OSI license (because of the disclaimer of patent rights), it didn’t solve one of the issues they were trying to address with NOSA 2.0.  I wonder if another solution would be to see if Creative Commons would be  willing to either create a CC0 with an express patent grant commensurate in scope with the public domain dedication/license backstop, or would allow the separate creation of one based on CC0.  If that seems like a fruitful idea, I could approach Diane Peters (who I know and used to meet up with periodically before our state went into social lockdown) about whether that was an idea they would support.

Not sure if USG is up for that (and if so, if any USG lawyer is willing to step into the process to discuss specific legal issues with any submitted license), but thought I’d throw that out there and see if there was any traction on the USG side for that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20200331/1c34cbb5/attachment.html>