Question on OSD #5

[Tzeng, Nigel H.]

>David Woolley wrote 

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

> The objective of permissive licences is to achieve that, and they
> achieve this by allowing derivative works to have non-open source
> licences. You seem to be talking about the resulting non-open source
> licences.


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.

 

That would be counterproductive if they happen to be the same folks that 

would find the code most useful.

 

Permissive licenses are superior in this regard since anyone can use them.

Perhaps that's just the best path.

 

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

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


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

> That is definitely not open source. I'm sure every supplier of
> proprietary, closed source, software would argue that their customers
> had no need to know (although my experience is that, in many cases, the
> source code is the only accurate documentation, and users have an
> unsatisfied need to know how the software really works.



Yes, the resulting code would not be open source any longer.  However,

developers would still be using open source code in their project.  When

possible they may contribute changes and fixes back.  There is a process

for downgrading classification of source code.

 

The term "need to know" has specific meaning with regard to classification

of information.

 

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.

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

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

 

No, the code is no longer open source.  However, the original project remains

open source and the closed project is able to use it even though it has

a variation of a reciprocal license.

 

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.


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

 

>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

or stove-piped projects where code is not often available.

 

It would be nice to have an environment of software exchange among

existing projects.  This will be difficult since it goes against the grain

of secrecy/security.

 

This isn't to say it doesn't happen today in the unclass environment.

Folks like the Naval Postgraduate School have open sourced quite

a few things.


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


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

 

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.

 

That's quite helpful. :)


Regards,

 

Nigel

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