Question on OSD #5

[Matthew Flaschen]

Tzeng, Nigel H. wrote:
> 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.  

As noted many a time, this argument can be made for any restriction.

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

Internal distribution is allowed for MS-RecL (MS-RL is confusing, due to
Microsoft Reference License), and most other licenses.  It's really an
exception in copyright law itself, just because of who's a "person"
under the law.

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

Distributing binaries publicly while keeping the source classified is a
*very* poor substitute for keeping the binaries classified, as any
reverse engineer could tell you..

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

Again, it's not hard to determine that mathematical model of a binary by
decompiling it.

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

I wouldn't hold them accountable, I would hope the OSI board would hold
/you/ "accountable", as in "be a little disappointed and maybe not as
convinced by the 'it's temporary' argument in the future".

> Nor am I sure why you would want to preclude or even
> frown upon on someone using an OSI approved license...

There's a whole category of licenses (actually, at least three
categories: "Special Purpose Licenses", "Non-reusable licenses",
"Licenses that have been voluntarily retired") listed at
http://opensource.org/licenses/category that OSI discourages use of.
Educational Community License is on the Special Purpose List.

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

That's true from a meritocracy standpoint, but legally it's baseless.
It's all John Hopkins University Applied Physics Laboratory (or MIT, or
whatever other institution applies)'s work from a legal standpoint, and
it doesn't make much difference to me which researcher invented it when
I get sued by JHUAPL or MIT.

> If I can show that my work pre-dates theirs then I would be the actual 
> original inventor and the grant is good.

No it's not.  Even if you really predated the patent (and let's admit
this inaccuracy isn't that rare under U.S. law), you're not the
"individual that is the author of the Work is also the inventor of the
patent claims", as  ECL 2.0 puts 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.

But, all the people asking for this exception have admitted how unlikely
this "catch" is.

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

Whitehead doesn't own anything.  MIT does.

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

This problem is solved with GPL or MS-RecL (assuming you overlook the
file-based weakness).  The only "problem" you haven't solved is putting
a limited patent grant in a reciprocal license, and I think OSI's
reluctant to do that, based on past experience with the BIPL.

> Prior to the Bayh-Dole Act it was a lot more informal...

And it still is, in practice.  I can give you a dozen examples of people
using the MIT license (which does have a patent grant, whether people
like it or not) without their institution's explicit approval.

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

The point is that code I develop can be intricately linked with code you
developed, to the point where anyone would admit it's a derivative work,
but it's still separate under MS-RL.  For instance, think of me writing
a patch file that modified one of your core functions but insisting the
patch file is not under MS-RecL.  This is allowed under MS-RecL, despite
being a clear derivative work under any reasonable standard.

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

Okay, but the fact is core enhancements can be made in separate files.

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

I know that.  Likely, they didn't put the answer there either because no
one asked the question, or they don't know the answer.

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

No, it's not, but legal complexity is a fact of life.

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

Whether you can distribute binary-only to California depends if the
United States as a whole is one entity, and whether California can be a
subcontractor under the federal government's direction and control.  You
would obviously need legal advice to know with any confidence.

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

I'm not at GTRI, so I wouldn't know.

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

That's a valid goal, but it doesn't require a new license.

Matt Flaschen