Question on OSD #5

[Tzeng, Nigel H.]

The discussion has been really interesting and I hope it continues. Thanks! :)
 
In case there were questions on the intent let me make them more clear:  My objective is to adhere to the spirit of open source rather than trying to find a dodge around it. However, in the intended environment, it may or may not be possible.
 
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).
 
I can obviously just use one of many permissive open source licenses.
 
However:
 
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.  
 
"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."
 
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.
 
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.
 
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 must permit folks who cannot share due to classification or need to know to not have to share or the software is useless to them.
 
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.
 
However, I would think that a reciprocal license, even with a limit, promotes more code sharing than a permissive license that allows closure.
 
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.

		>Matthew Flaschen <matthew.flaschen at gatech.edu> wrote:
		>> Chris Travers wrote:
		
		>> The key point is that it needs to remain private.  If an NSA agent makes
		>> classified modifications to the Linux kernel and gives them to another
		>> agent, that's fine under the GPL, since private modification is allowed,
		>> and NSA is a single entity.
		>>
		>> However, if the NSA wants to distribute outside their organization, they
		>> can't put any additional restrictions on the code.  It doesn't matter
		>> /how/ it is transmitted out.  Once it leaves the entity (NSA in this
		>> case), it can be freely distributed by the recipient.
		
		> That is more or less the line I was drawing.  The idea is that secrets
		> can be kept secret without violating open source, and that  the
		> enforcement of secrecy rules is sort of beyond our discussion.
		
		> However, I would say that the entity is actually the US government in
		> this case, not the NSA, and they would be allowed to distribute to
		> other government agencies.

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.  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.

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.

Nigel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20071126/aa9b99e8/attachment.html>