<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 28, 2019 at 1:51 PM Smith, McCoy <<a href="mailto:mccoy.smith@intel.com">mccoy.smith@intel.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>>Thank you for restating the underlying disagreement on the same false pretense.  Governments are subject to a plethora of different regulations and laws than commercial actors.  To claim or presume there are no requirements unique to Government seems quite fallacious.<br>
<br>
And both with NOSA 2.0 and the recent LBNL BSD, questions on the list were asked about the "regulations and laws" that were dictating certain provisions in those licenses, and that an attorney from the agency that drafted these licenses respond to those questions:<br></blockquote><div><br></div><div>I wasn't monitoring the lists when the NOSA 2.0 was submitted so I can't comment on what happened there. It does turn out, though, that at one point I happened to have a long conversation or two with the drafter of the original NOSA. As he described it, his purpose was to preserve copyleft-style source availability for code written by the government.</div><div><br></div><div>As he described it, goverment-written code is all public domain. Unfortunately, the predominant effect of that public domain status for the code was that government contractors would take the code, make trivial modifications, and sell it back to the government under a proprietary license - which they were within their rights to do. This resulted in the government needing to pay for many incompatible proprietary forks of code that was 95% based upon the previous public domain code released by the government itself.</div><div><br></div><div>Two approaches were trialed to deal with this: The first was having the government cooperate with a private entity that would hold a copyright, and include in the contract with the private entity the requirement to release the code under an open source license.</div><div><br></div><div>The second approach was the NOSA. This was a contract, rather than a license, and it used the concept of an intended third party beneficiary - in this case the government itself, but also any others who would be interested - as an alternative means of enforcing source availability.</div><div><br></div><div>In this case, it was specifically a government-specific issue - its lack of ability to copyright (and thus to license) that led to the creation of the original NOSA.</div><div><br></div><div>With regard to the LL-BSD, I am not aware of a similar issue, but it could also be that the people releasing the code do not have the ability under various operating statutes and rules to engage in typical inbound licensing. This could easily be translated through various levels of hierarchy into "the [mumble, mumble] rules and regulations don't allow it."</div><div><br></div><div>I have no particular stake in this issue, but I have counseled both government entities and government contractors on open source issues, and GOSS does have some unique aspects that should be recognized.</div><div><br></div><div>Thanks,<br></div><div>Van<br></div></div></div>