Question on OSD #5

[Tzeng, Nigel H.]

Matthew Flaschen [mailto:matthew.flaschen at gatech.edu] wrote

> The spirit of open source is subjective, but OSD #1 requires that "The
> license shall not restrict any party from selling or giving away the
> software [...]" and OSD #7 that "The rights attached to the program must
> apply to all to whom the program is redistributed [...]".  Restrictions
> have traditionally been admitted, (e.g. export restrictions,
> geographical limitations in GPL), but reluctantly.

I am not certain your point here.  The objective is to share code as 
much as possible.  The definition of "possible" may differ among folks
but the sharing of code should be a common enough goal.

> However, note that your program may itself infringe patents held by
> others in your institution.  In fact, at a large institution like MIT,
> it's much more likely to infringe someone else's patent than your own.
> They won't sue /you/, but they may sue us.  Thus, the patent grant
> provides negligible protection.

You're even more likely to infringe on someone's patent outside your
organization than within it.  However, the point is that some institutions
will not share code (ie do open source) without this limitation.  If this
limitation allows folks to move forward with open source I think that
would be a good thing.  
 
Presumably that is why ECL 2.0 was approved.

> Again, note my NSA example.  If someone on a classified NSA network gets
> a copy of GPL code, they can make and share modifications internally
> without ever distributing to the outside world.

Depends on the nature of the license doesn't it?  GPL is not specifically 
under discussion here.  If anything, MS-RL is and I primarily like
that because it's short.

> You may be under the misapprehension that modifications to GPL software
> must be submitted "to the community".  In fact, the source must only be
> provided to those you provide the binary to, /if/ you distribute outside
> of your organization.

Yes, but they may need to distribute a binary version only and limit
access to source code because the end users have no "need to know".
 
An example of this would be the use of a classified physics or behavior 
models that descibes the performance of a system or tactic.  The system 
may use this internally as a intermediate step that is used to compute an
outcome for a user.  The user should not have knowledege of how the
answer was developed as would reveal information they have no need to 
know even though they have the clearance to use the product itself.

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

> This is undesirable, and contrary to the representations made for
> approval, though not actually forbidden.

I dunno how you would hold them accountable for something I might
choose to do.  Nor am I sure why you would want to preclude or even
frown upon on someone using an OSI approved license...

>> However, I would think that a reciprocal license, even with a limit,
>> promotes more code sharing than a permissive license that allows
>> closure.

> For an original author with many patents, the patent issue is more
> important.  I would still prefer an implicit "use" license over a
> deliberately weak explicit license.

I suppose that we have to agree to disagree.  From my perspective
I have zero desire to potentially give away someone else's work.
 
My work is my work.  Their work is their work.
 
If I can show that my work pre-dates theirs then I would be the actual 
original inventor and the grant is good.  If not, its not really mine to 
give away, now is it?
 
If their patent previously existed I would hope our IP release process
would catch that and we would not release the code as open source
or get the patent actual holder to make an explicit grant.
 
For a large institution like MIT it could come from MIT, Lincoln Labs, 
the Broad Institute or the Whitehead Institute.  Lincoln labs should not be
able to deliberately or accidently give away something that Whitehead
developed first and owns without Whitehead's approval.

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

> Presumably, if you're competitor ever gets access to the code, it wasn't
> classified/private so GPL or MPL will work.

There is no issue with a competitor getting the code.  
 
The potential issue is with a "competitor" getting the code and successfully 
moving the community/user base to the closed source version because they 
can afford to put far more resources on extending it than can the open
source community.
 
If I make the business case that releasing IP with some potential value
as open source rather than conventional licensing because it provides my 
insititution ROI in the form of mindshare and potential service/enhacement 
revenue then it would be helpful to show that hijacking the project is somewhat
less likely than with the case with a purely permissive license.
 
Otherwise, I believe they might be more inclined to simply seek conventional 
licening opportunities.  Using MIT as the example, I believe that their Technology
Licence Office had $46M in revenues in 2005.
 
Many research universities have thus created technology licensing offices
whom are often the gatekeepers of what is, or is not, open sourced.
 
Prior to the Bayh-Dole Act it was a lot more informal...

>> This is a business case argument in favor of open
>> source even if the protection is somewhat illusory with file based
>> reciprocal licenses.
>
>Actually, completely and provably illusory.

In some languages, yes, completely illusory.  In most languages, with 
proper structuring, you should be able to keep any of the code you develop 
seperate from the code I develop.  
 
However, for bug fixes and enhancements to the core code it would be annoying 
to do so and the path of least resistance is to simply return the changes upstream.
Especially if there is legal incentive to do so.
 
If competitor provides real value added, I'm inclined to let them profit from it.  I 
really only want bug fixes and core enhancements returned and frankly I'm not
all that insistant about it.  
 
Of course, I am hoping that a weaker reciprocal license is acceptable enough for
my institution if a permissive license is not.  I will certainly explain in detail how
folks might circumvent a file based license.
 
However, what I want and what my institution may want may be completely
different things.

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

> Keep in mind, the FAQ isn't legally binding even for FSF-owned code, and
> has almost no value for code owned by others.

Legally binding is somewhat less important than letting folks know
what at least THEY think the answer is.

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

>First, this assumes the United States as a whole (federal + state +
>local) is not an entity, which is probably a matter of dispute.
 
If it is a matter of dispute that's not a good thing is it?

>Regardless, the subcontractor exception may still apply for GPLv3.

>Also, we have to determine whether this is a real issue.  Say the
>federal government writes a secret modification to GPL software.  Then
>they give the modified version to California.  They have to license the
>modification under the GPL, which allows California to redistribute it
>outside of the project.  Does California have any reason to do so?  No.
>Is it at all likely that they will do so?  No.

This is presuming that California has any need to know what those 
changes are and should actually be allowed to see the source code.
 
The world of security has its own rules and they are often not negotiable.  
Doing open source in that environment has additional challenges.  Reducing
potential friction where possible is helpful to gain acceptance to release 
things as open source at all.
 
I have released code in this environment and I know the steps I had to 
take to do so.  Perhaps at GTRI it is easier.  However, in their 2006 Annual 
Review there is only one mention of open source and it appears to be 
for something "inspired by open source" but not actually open source
itself.  I'm sure there are open source contributions by GTRI and no, open 
source doesn't appear in our annual report either.
 
Wouldn't it be nice to change that?

Regards,
 
Nigel
 
ObDis: Speaking for myself and not Hopkins...which is also why I keep using 
MIT as the example. :)

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