<HTML dir=ltr><HEAD><TITLE>Re: Question on OSD #5</TITLE>
<META http-equiv=Content-Type content="text/html; charset=unicode">
<META content="MSHTML 6.00.6000.16544" name=GENERATOR></HEAD>
<BODY>
<DIV id=idOWAReplyText8637 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>The discussion has been really interesting and I hope it continues. Thanks! :)</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>In case there were questions on the intent let me make them more clear:  </FONT><FONT face=Arial size=2>My objective is to adhere to the spirit of open source rather than trying to find a dodge around it. </FONT><FONT face=Arial size=2>However, in the intended environment, it may or may not be possible.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>For example, say that I would like to make some code available but may be constrained to do so only on SIPRNET or to some verified community (available on some portal that requires some kind of certificate).</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>I can obviously just use one of many permissive open source licenses.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>However:</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>1) I would prefer to have an explicit patent grant vs. an implicit patent grant.  The limitation in ECL 2.0 is desirable for me for the same reasons it is desirable for them.  </FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2><EM><STRONG>"While we might wish for a broader license that would cover all of the inventions coming out of an entire university or institution -- and indeed, we fought hard for as broad of a patent license as possible, both in our discussions with individual contributors and their institutions, and during the international summit on open source licensing in higher education that we organized -- many institutions just couldn’t agree with this because they felt that this would in effect force all of the inventors at that institution to be contributors to the project."</STRONG></EM></FONT></DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>I am not inclined to force other inventors to adhere to my beliefs.  I disagree with the sentiment that software made available with this limitation of little value to the community.  It is simply a statement that the originators of the code are only giving away that which they have themselves created and not the work of others even if they happen to work at the same place.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>If an institution wants to provide additional patent grants explicitly they can also do that but typically this limitation is simply to assuage the fear that some IP might be inadvertently released without the permission of the major stakeholders.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>2) I would prefer to have a reciprocal license vs. a permissive one to promote sharing of improvements.  However, some folks simply can't share improvements for classification reasons.  Any reciprocal license in that environment <STRONG>must</STRONG> permit folks who <STRONG>cannot</STRONG> share due to classification or need to know to not have to share or the software is useless to them.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>If item #2 cannot pass OSD muster then ECL 2.0 should be good enough for me should I desire a OSI-approved license.  Of course, this means one or more projects, outside of the control of the Sakai and Kuali groups, using the license.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>However, I would think that a reciprocal license, even with a limit, promotes more code sharing than a permissive license that allows closure.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Since I favor permissive licenses anyway, this isn't that big a deal to me personally.  However, it would be nice to make the argument that what we stick in the commons stays there and not potentially form a competitive advantage for our competitors when arguing for open source.  This is a business case argument in favor of open source even if the protection is somewhat illusory with file based reciprocal licenses.</FONT></DIV></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV dir=ltr><FONT size=2><FONT size=3>></FONT>Matthew Flaschen <matthew.flaschen@gatech.edu> wrote:<BR>>> Chris Travers wrote:<BR><BR>>> The key point is that it needs to remain private.  If an NSA agent makes<BR>>> classified modifications to the Linux kernel and gives them to another<BR>>> agent, that's fine under the GPL, since private modification is allowed,<BR>>> and NSA is a single entity.<BR>>><BR>>> However, if the NSA wants to distribute outside their organization, they<BR>>> can't put any additional restrictions on the code.  It doesn't matter<BR>>> /how/ it is transmitted out.  Once it leaves the entity (NSA in this<BR>>> case), it can be freely distributed by the recipient.<BR><BR>> That is more or less the line I was drawing.  The idea is that secrets<BR>> can be kept secret without violating open source, and that  the<BR>> enforcement of secrecy rules is sort of beyond our discussion.<BR><BR>> However, I would say that the entity is actually the US government in<BR>> this case, not the NSA, and they would be allowed to distribute to<BR>> other government agencies.</FONT></DIV></BLOCKQUOTE></BLOCKQUOTE>
<P><FONT size=2><FONT face=Arial>Is this actually the case?   It sure would have been nice if the FSF had explicitly said that in their FAQ that the USG is considered a single entitity.  </FONT></FONT><FONT size=2><FONT face=Arial>Australia has done a pretty good job of explaining the use of open source within their government but I haven't seen a corresponding document from any US agency.</FONT></FONT></P>
<P><FONT face=Arial size=2>That doesn't help projects that expect to span federal, state and local governments.  I have also been told that even LGPL is unacceptable for some government users but not why.  Could be a v2 issue with use by contractors being distribution.  The wording in GPL V3 Section 2 is somewhat awkward though but it does appear to solve that issue.</FONT></P>
<P><FONT face=Arial size=2>Nigel</FONT></P></BODY></HTML>