Approval of IWL - Consolidated Response

Lasse R. Nielsen atwork at infimum.dk
Wed May 28 09:41:23 UTC 2008


On Wed, 28 May 2008 08:58:15 +0200, Gernot Heiser <gernot at ok-labs.com> wrote:
...
> It seems to me that arguments are boiling down to OSD compliance not
> being sufficient. So the OSD isn't the definition of what's open
> source, but just a partial list of requirements? And the full list
> isn't available anywhere?

I don't speak for the OSI, so my evaluation is entirely my own.

I do think that OSD compliance is not enough. There is also a quality requirement.
The licens needs to be clear and unambiguous (otherwise it will be hard or impossible
to know whether it is OSD compliant and/or whether one violates the license).

I.e., it must be a usable license that meets the goals of the OSD.

All comments on the IWL are about the two clauses:

|    (c) Redistributions in any form must be accompanied by information on
|        how to obtain complete source code for:
|
|        (i) the Software; and
|        (ii) all accompanying software that uses (or is intended to use) the
|             Software whether directly or indirectly.
|        For an executable file, "complete source code" means the source code for
|        all modules it contains and includes associated build and other files
|        reasonably required to produce the executable.
|
|    (d) The source code referred to in paragraph (c) must:
|        (i) either be included in the distribution or be available for no more
|            than the cost of distribution plus a nominal fee; and
|        (ii) be licensed by each relevant holder of copyright under either the
|             Licence Terms (with an appropriate copyright notice) or the terms of
|             a licence which is approved by the Open Source Initiative.

>From this, the meaning of the words "accompanying", "uses", "intended", and "indirectly"
is not clear.

What does it mean to accompany? To be available from the same FTP servier, to exist
on the same CD, to be part of the same zip archive? I guess the intended line is
somewhere in this range. I think that any restriction on software that is merely
"accompanying" the covered Software is a problem. It definitly ontradicts OSD #9 and
maybe also OSD #1. The only way to affect other accomanying software is if that
software is a derived work, so that OSD #3 applies, but that is not the case here.

What does it mean to use the software? Call a function of the software (library use),
call a service on a server running the software (client/server use), or executing the
software using a system exec call? The first suggests a derived work, the
last would mean that an accompanying bash implementation might be covered (depending
on the meaning of "intended"). It is definitly not the case that the programs of c(ii)
need to be derived from the Software, so OSD #3 can't be used as argument for requireing
them to be covered by the same lincense.

What does it mean that use is intended? By whom (it's author, the distributor, or ...)?
If I create a program whose only purpose is to call the Software, then intended use
is clear. If I distribute a mini Linux distribution with the intent of only running
the software, then the version of Linux included is intended for using the software?
I.e., there can be generic software that uses the software, but that was not originally
intended to do so.

What does it mean to use something indirectly? To use something that uses (or further
transitive closure)? Or must the first use somehow trigger a chain of events that causes
code from the Software to be executed, that would not otherwise have happened?
How many levels of indirection? Does the OS that starts a server, *use* the Software of the
server? It certainly directly invokes it. That might make any program that uses the OS also
indirectly use the Software. Even worse if the Software is used in, e.g., a system wide
logging demon (which the license shouldn't preclude), which might mean that most software
on the system "indirectly uses" the Software.

Also, "a license approved by the OSI" should probably be changed to "a license certified
by the OSI".


I.e., my personal complaints against the IWL is not that it is not OSD compliant (due to
OSD #9), but also, just as significantly, that it is so unclear that I cannot begin to
determine whether it is otherwise OSD compliant.

It should be possible to look at a particular case of distribution and, with not too much
trouble, determine whether the license is violated or not. With the current wording, which
is fairly wide reaching without being precise, the range of possible interpretations makes
that a matter of guesswork.

/L
-- 
Lasse R.H. Nielsen - atwork at infimum.dk
 'Faith without judgement merely degrades the spirit divine'
 Reproduction of this message, or parts thereof, is allowed if proper attribution is given.



More information about the License-review mailing list