Question on OSD #5

[Matthew Flaschen]

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

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

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.

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

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.

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.

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

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

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

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

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

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

Matt Flaschen