Question on OSD #5

[Chris Travers]

On Nov 28, 2007 4:43 AM, Tzeng, Nigel H. <Nigel.Tzeng at jhuapl.edu> wrote:

>
> The objective is to make the code useful to the largest number of folks
> under a reciprocal license. If I require that folks must reciprocate when
> they are legally bound to not reciprocate then they cannot use the code.

I think you need to outline what sort of reciprocation you want.  The
MS-RecL, GPL, and LGPL all have very different levels of
reciprocation.

> > Copyleft licences attempt aim to prevent the creatin of non-open source
> > works from the licenced material. They maximise the rights of
> > downstream recipients, but possibly reduce the number of those recipients.
>
> I am seeking a middle ground.

Maybe a weakly copyleft license (MPL, LGPL, MS-RecL, etc)?

> > If businesses could avoid providing source and free licences to
> > recipients of copyleft licences simply by saying that the charter of the
> > business didn't allow them to give away source code, a lot of businesses
> > would set up to exploit that loophole.
>
> Except that
>
> a)       you can do so under permissive open source license anyway which
> would be the most likely alternative.
>
> b)       the permission to close the source in this scenario is limited to
> reasons of national security and not commercial interests.
>
> I can see the objection that the license might not be global since some of
> the
> terms used in the discussion are US DoD/USG specific and other countries
> use different nomenclature.  I THINK the original text was somewhat neutral
> in that regard.

A couple of points.  From a business perspective permissive licenses
are scary in some ways but from a community perspective I believe they
are superior because they prevent the sort of single-vendor open
source products (note I did not say "projects") we see with MySQL,
Asterisk, etc.  In short the only way to be successful is to have a
community not dependent on a single party.  The sole exception are
single-party reference implementations (the Intel ISCSI Reference
Implementation, for example).

The scary point to a business is related to this-- releasing code
under a permissive license means that one's competitors may use that
code to subsidize their own R&D.  Hence buisnesses tend to contribute
to permissive-licensed projects far more when the pace of development
is such that this sort of subsidy is outweighed by the community
maintenance of the code.  I think that this is a major aspect to
understanding what license to choose.

Successful projects using permissive licenses include Apache and
PostgreSQL.  There are a number of unsuccessful projects as well (as
there are under any license).

>
>
> I hadn't considered that you might tell or expect the recipient not to ask
> for
> the source.  That seems like a rather iffy dodge around the GPL.

The conventional wisdom is that such would conflict with the GPL.
Note that my point was that this does not prevent someone from asking
one not to reveal the identity of the contributor however, since
anonymous or pseudonymous copyright notices might be allowed.
(Pseudonyms might be used along with real names in actual copyright
registration, however, as an optional element).

> >In that case you are not giving them open source code. It might be
> >derived from permissively licensed open source code, and you might be
> >giving them the closed source binaries, or you might be providing it
> >using an Application Service Provider, with no access to the code.
>
>
>
> The suggestion that the GPL was suitable for this environment
> since the downstream recipient is not obligated to distribute.  This example
> shows why the GPL may be unacceptable in some circumstances even if the
> recipient can be trusted not to distribute.  They may see information they
> should not see due to "need to know".

If it is an internal deployment that would seem to pose no problems.
For an external deployment, the question might include whether there
was an interpretation of relevant copyright law which they could use
to discourage lawsuits.  For example, by putting the GPL functionality
into libraries, and having a proprietary wrapper program, then arguing
that this is mere aggregation since it is only a compiled rather than
derivative work.

Any government has enough resources to move at least into debatable
territory.  Since at least in the US, financial damages probably
wouldn't apply to the federal government, the worst case scenario is
that the government is ordered to stop distributing the program.  Then
they move the classified section out of process and wait to see if you
will sue this time.  Or they get Congress to rewrite the rules.

For example, suppose the NSA started to use GNU Readline in classified
programs that were distributed to contractors.  If they contribute the
modifications to that library back, there is not much incentive to sue
them especially since a loss would undermine enforcement elsewhere.

> A permissive license does this just fine.  ECL v2 meets this requirement.

> > With the GPL, it is a specific aim that users should be able to discover
> > how the software works.

> GPL is not the solution to every open source problem.

Agreed.

> >The open source community doesn't like a situation where the original
> >licence holder can use contributions in proprietary works but third
> >parties can't.
>
> Contribution would be mandatory except in the case where you cannot
> due to security classification. There is no closed source version unless
> someone wants to license something they could get for free.  A file based
> reciprocal license is not very onerous.

Personally I don't buy that argument.  One shouldn't build government
rules into licenses.  The fact is that if a government wants to
violate your copyright license there isn't a lot you can do about it
anyway except ask them to stop.  The proper response is not to treat
governments differently in the license but realize that enforcement
options are more limited.

> >If contribution back is voluntary, not many people with
> >volunteer under those circumstances, and if it is mandatory, the
> >software is likely to rejected in favour of a more open alternative.

> If there were many open alternatives I would be quite happy.
> It is an application space largely dominated by either proprietary

I would add that companies like Covalent, EnterpriseDB, GreenPlum,
etc. might take issue with the idea that not many people volunteer to
make contributions.

Again, for a permissively licensed project, the key thing is to build
a large developer community which can keep the pace of development
high enough that the price of contributing is lower than the price of
not contributing.  After all, this is all you can hope for under *any*
open source license.

> > Generally, open source businesses are expected either to make their
> > money from services or to sell non-open source versions that do not
> > include contributions from the open source community.
>
>
>
> We aren't an open source business. We don't sell software products.
> Academic research institutions are almost the opposite of patent trolls.
> We generate IP that is licensed out to industry rather than take it to
> market ourselves.  In some cases we are prohibited from directly
> competing with industry.

Then you have two options:  You can become an open source business (by
using a reciprocal license and then selling licensing for closed
source versions) or you can release under a permissive license.
Academic environments do go both ways (or at least similar ways with
non-commerical licenses and pay-for-commercial-use licenses), but
presumably the latter is probably better.

> >> 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.
>
> > As noted above, you will run into the problem that many in the open
> > source community considers this to be free-loading and will resist
> > feeding back detailed bug fixes if they think they will end up in
> > non-open source software.

> Except that if we open source some particular IP the license value
> for that IP approaches zero.  Since we don't create software products
> as a business (except very rarely) the project itself has no proprietary
> version unless some company creates one.

I would agree with this.  The rabid Stallmanist wing certainly sees it
as freeloading, but PostgreSQL and Apache seem to have no problem
getting contributions.  Suggesting that this reduces contributions on
this basis is basic FUD.

Note that there *is* a business case against such contributions where
they are a) substantial and b) not widely improved upon, that they may
subsidize competition, but in those cases they are also outside the
mainstream scope of the project.
>
> The open source ROI for an academic institution is reputation for innovation
> and useful research.  This might lead to grants and direct work but doesn't
> really represent a revenue stream.  It isn't likely that we would even use
> the software ourselves.
>
>
>
> It is starting to appear that a permissive license which avoids
> misunderstanding
> of intent is worth more than the dubious value of a weak reciprocal license.

In an academic environment, I would agree.

Best Wishes,
Chris Travers