<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.5730.11" name=GENERATOR></HEAD>
<BODY>
<DIV id=idOWAReplyText5001 dir=ltr>
<DIV dir=ltr><FONT face=Arial size=2>Matthew Flaschen [mailto:matthew.flaschen@gatech.edu] wrote<BR></FONT><FONT size=2><BR><FONT face=Arial>> The spirit of open source is subjective, but OSD #1 requires that "The<BR>> license shall not restrict any party from selling or giving away the<BR>> software [...]" and OSD #7 that "The rights attached to the program must<BR>> apply to all to whom the program is redistributed [...]". Restrictions<BR>> have traditionally been admitted, (e.g. export restrictions,<BR>> geographical limitations in GPL), but reluctantly.<BR></FONT></FONT></DIV>
<DIV dir=ltr><FONT size=2><FONT face=Arial>I am not certain your point here. The objective is to share code as </FONT></FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2>much as possible. The definition of "possible" may differ among folks</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2>but the sharing of code should be a common enough goal.</FONT><FONT></DIV></FONT></DIV>
<DIV dir=ltr><FONT size=2>
<DIV dir=ltr><BR><FONT face=Arial>> However, note that your program may itself infringe patents held by<BR>> others in your institution. In fact, at a large institution like MIT,<BR>> it's much more likely to infringe someone else's patent than your own.<BR>> They won't sue /you/, but they may sue us. Thus, the patent grant<BR>> provides negligible protection.<BR></FONT></DIV>
<DIV dir=ltr><FONT face=Arial>You're even more likely to infringe on someone's patent outside your</FONT></DIV>
<DIV dir=ltr><FONT face=Arial>organization than within it. However, the point is that some institutions</FONT></DIV>
<DIV dir=ltr><FONT face=Arial>will not share code (ie do open source) without this limitation. If this</FONT></DIV>
<DIV dir=ltr><FONT face=Arial>limitation allows folks to move forward with open source I think that</FONT></DIV>
<DIV dir=ltr><FONT face=Arial>would be a good thing. </FONT></DIV>
<DIV dir=ltr><FONT face=Arial></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial>Presumably that is why ECL 2.0 was approved.</DIV></FONT><FONT face=Arial></FONT></FONT></DIV>
<DIV dir=ltr><FONT size=2><FONT face=Arial>
<DIV dir=ltr><BR>> Again, note my NSA example. If someone on a classified NSA network gets<BR>> a copy of GPL code, they can make and share modifications internally<BR>> without ever distributing to the outside world.<BR></DIV>
<DIV dir=ltr>Depends on the nature of the license doesn't it? GPL is not specifically </DIV>
<DIV dir=ltr>under discussion here. If anything, MS-RL is and I primarily like</DIV>
<DIV dir=ltr>that because it's short.</DIV>
<DIV dir=ltr><BR>> You may be under the misapprehension that modifications to GPL software<BR>> must be submitted "to the community". In fact, the source must only be<BR>> provided to those you provide the binary to, /if/ you distribute outside<BR>> of your organization.<BR></DIV>
<DIV dir=ltr>Yes, but they may need to distribute a binary version only and limit</DIV>
<DIV dir=ltr>access to source code because the end users have no "need to know".</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>An example of this would be the use of a classified physics or behavior </DIV>
<DIV dir=ltr>models that descibes the performance of a system or tactic. The system </DIV>
<DIV dir=ltr>may use this internally as a intermediate step that is used to compute an</DIV>
<DIV dir=ltr>outcome for a user. The user should not have knowledege of how the</DIV>
<DIV dir=ltr>answer was developed as would reveal information they have no need to </DIV>
<DIV dir=ltr>know even though they have the clearance to use the product itself.</DIV>
<DIV dir=ltr><BR>>> If item #2 cannot pass OSD muster then ECL 2.0 should be good enough<BR>>> for me should I desire a OSI-approved license. Of course, this means<BR>>> one or more projects, outside of the control of the Sakai and Kuali<BR>>> groups, using the license.<BR><BR>> This is undesirable, and contrary to the representations made for<BR>> approval, though not actually forbidden.<BR></DIV>
<DIV dir=ltr>I dunno how you would hold them accountable for something I might</DIV>
<DIV dir=ltr>choose to do. Nor am I sure why you would want to preclude or even</DIV>
<DIV dir=ltr>frown upon on someone using an OSI approved license...</DIV>
<DIV dir=ltr><BR>>> However, I would think that a reciprocal license, even with a limit,<BR>>> promotes more code sharing than a permissive license that allows<BR>>> closure.<BR><BR>> For an original author with many patents, the patent issue is more<BR>> important. I would still prefer an implicit "use" license over a<BR>> deliberately weak explicit license.<BR></DIV>
<DIV dir=ltr>I suppose that we have to agree to disagree. From my perspective</DIV>
<DIV dir=ltr>I have zero desire to potentially give away someone else's work.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>My work is my work. Their work is their work.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>If I can show that my work pre-dates theirs then I would be the actual </DIV>
<DIV dir=ltr>original inventor and the grant is good. If not, its not really mine to </DIV>
<DIV dir=ltr>give away, now is it?</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>If their patent previously existed I would hope our IP release process</DIV>
<DIV dir=ltr>would catch that and we would not release the code as open source</DIV>
<DIV dir=ltr>or get the patent actual holder to make an explicit grant.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>For a large institution like MIT it could come from MIT, Lincoln Labs, </DIV>
<DIV dir=ltr>the Broad Institute or the Whitehead Institute. Lincoln labs should not be</DIV>
<DIV dir=ltr>able to deliberately or accidently give away something that Whitehead</DIV>
<DIV dir=ltr>developed first and owns without Whitehead's approval.</DIV>
<DIV dir=ltr><BR>>> Since I favor permissive licenses anyway, this isn't that big a deal<BR>>> to me personally. However, it would be nice to make the argument<BR>>> that what we stick in the commons stays there and not potentially<BR>>> form a competitive advantage for our competitors when arguing for<BR>>> open source.<BR><BR>> Presumably, if you're competitor ever gets access to the code, it wasn't<BR>> classified/private so GPL or MPL will work.<BR></DIV>
<DIV dir=ltr>There is no issue with a competitor getting the code. </DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>The potential issue is with a "competitor" getting the code and successfully </DIV>
<DIV dir=ltr>moving the community/user base to the closed source version because they </DIV>
<DIV dir=ltr>can afford to put far more resources on extending it than can the open</DIV>
<DIV dir=ltr>source community.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>If I make the business case that releasing IP with some potential value</DIV>
<DIV dir=ltr>as open source rather than conventional licensing because it provides my </DIV>
<DIV dir=ltr>insititution ROI in the form of mindshare and potential service/enhacement </DIV>
<DIV dir=ltr>revenue then it would be helpful to show that hijacking the project is somewhat</DIV>
<DIV dir=ltr>less likely than with the case with a purely permissive license.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>Otherwise, I believe they might be more inclined to simply seek conventional </DIV>
<DIV dir=ltr>licening opportunities. Using MIT as the example, I believe that their Technology</DIV>
<DIV dir=ltr>Licence Office had $46M in revenues in 2005.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>Many research universities have thus created technology licensing offices</DIV>
<DIV dir=ltr>whom are often the gatekeepers of what is, or is not, open sourced.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>Prior to the Bayh-Dole Act it was a lot more informal...</DIV>
<DIV dir=ltr><BR>>> This is a business case argument in favor of open<BR>>> source even if the protection is somewhat illusory with file based<BR>>> reciprocal licenses.<BR>><BR>>Actually, completely and provably illusory.<BR></DIV>
<DIV dir=ltr>In some languages, yes, completely illusory. In most languages, with </DIV>
<DIV dir=ltr>proper structuring, you should be able to keep any of the code you develop </DIV>
<DIV dir=ltr>seperate from the code I develop. </DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>However, for bug fixes and enhancements to the core code it would be annoying </DIV>
<DIV dir=ltr>to do so and the path of least resistance is to simply return the changes upstream.</DIV>
<DIV dir=ltr>Especially if there is legal incentive to do so.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>If competitor provides real value added, I'm inclined to let them profit from it. I </DIV>
<DIV dir=ltr>really only want bug fixes and core enhancements returned and frankly I'm not</DIV>
<DIV dir=ltr>all that insistant about it. </DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>Of course, I am hoping that a weaker reciprocal license is acceptable enough for</DIV>
<DIV dir=ltr>my institution if a permissive license is not. I will certainly explain in detail how</DIV>
<DIV dir=ltr>folks might circumvent a file based license.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>However, what I want and what my institution may want may be completely</DIV>
<DIV dir=ltr>different things.</DIV>
<DIV dir=ltr><BR>>> Is this actually the case? It sure would have been nice if the FSF<BR>>> had explicitly said that in their FAQ that the USG is considered a<BR>>> single entitity.<BR><BR>> Keep in mind, the FAQ isn't legally binding even for FSF-owned code, and<BR>> has almost no value for code owned by others.<BR></DIV>
<DIV dir=ltr>Legally binding is somewhat less important than letting folks know</DIV>
<DIV dir=ltr>what at least THEY think the answer is.</DIV>
<DIV dir=ltr><BR>>> Australia has done a pretty good job of explaining<BR>>> the use of open source within their government but I haven't seen a<BR>>> corresponding document from any US agency.<BR>>><BR>>> That doesn't help projects that expect to span federal, state and<BR>>> local governments.<BR><BR>>First, this assumes the United States as a whole (federal + state +<BR>>local) is not an entity, which is probably a matter of dispute.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>If it is a matter of dispute that's not a good thing is it?</DIV>
<DIV dir=ltr><BR>>Regardless, the subcontractor exception may still apply for GPLv3.<BR><BR>>Also, we have to determine whether this is a real issue. Say the<BR>>federal government writes a secret modification to GPL software. Then<BR>>they give the modified version to California. They have to license the<BR>>modification under the GPL, which allows California to redistribute it<BR>>outside of the project. Does California have any reason to do so? No.<BR>>Is it at all likely that they will do so? No.<BR></DIV>
<DIV dir=ltr>This is presuming that California has any need to know what those </DIV>
<DIV dir=ltr>changes are and should actually be allowed to see the source code.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>The world of security has its own rules and they are often not negotiable. </DIV>
<DIV dir=ltr>Doing open source in that environment has additional challenges. Reducing</DIV>
<DIV dir=ltr>potential friction where possible is helpful to gain acceptance to release </DIV>
<DIV dir=ltr>things as open source at all.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>I have released code in this environment and I know the steps I had to </DIV>
<DIV dir=ltr>take to do so. Perhaps at GTRI it is easier. However, in their 2006 Annual </DIV>
<DIV dir=ltr>Review there is only one mention of open source and it appears to be </DIV>
<DIV dir=ltr>for something "inspired by open source" but not actually open source</DIV>
<DIV dir=ltr>itself. I'm sure there are open source contributions by GTRI and no, open </DIV>
<DIV dir=ltr>source doesn't appear in our annual report either.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>Wouldn't it be nice to change that?</DIV>
<DIV dir=ltr><BR>Regards,</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>Nigel</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>ObDis: Speaking for myself and not Hopkins...which is also why I keep using </DIV>
<DIV dir=ltr>MIT as the example. :)<BR></DIV></FONT></FONT></DIV></BODY></HTML>