Subject: Re: Updated license - please comment
From: Chuck Swiger <cswiger@mac.com>
Date: Wed, 18 Jun 2003 17:04:55 -0400

Mark Rafn wrote:
> On Wed, 18 Jun 2003, Rod Dixon wrote:
[ ... ]
> Am I the only one who thinks 2a and 2d are unacceptible?  It violates
> OSD#3 by limiting the type of derived work, perhaps OSD#6 by limiting
> itself to creators of software libraries, and perhaps OSD#8 by being
> specific to the product "software library".  As far as I can tell, it
> prevents anyone from distributing an application that statically links the
> library into it (if such an application is a derived work of the library,
> at least).

True.  However, I don't find the restrictions unacceptible from a personal 
standpoint: in the event that I wanted to do something with ScoreC, it's free as 
in "free beer", I have the sources, and I can change them to suit my local 
requirements if I needed to.  At the moment, I don't see much possibility that 
I'd want to redistribute any such changes at all.  RPI could, if they chose to, 
sure, but being able to "fork" my own "ScoreC" distribution isn't a concern-- 
the issue of redistributing my local changes is moot.

On the other hand, I do agree that a project which people are not free to "fork" 
and redistribute in other ways than just a library per 2a is not open source.

Clause 2d asks people publishing changes to make a good faith attempt to 
maintain the integrity of the calculations defined by the API, etc.  Why is it 
particularly useful to enable people to redistribute changes which break the API 
deliberately?

> It doesn't even seem close to me.  Let me know if I'm insane, or reading 
> it wrong, but I can't see how such a restriction can be considered open 
> source.

You seem to be reading the OSD as it is written just fine.  If it is axiomatic 
that the OSD as written defines "(OSI) open source", your analysis is correct.

If the OSD should be interpreted to mandate that a compliant license may not 
forbid deliberately broken or malicious redistributions, then my frank opinion 
is that the OSD should be changed, not the proposed license term.

However, taken to extremes, and for the sake of example, what happens if someone 
maliciously publishes a set of changes to trojan the OpenSSL security library?

What happens if Oracle continues to publish a set of changes to JDBC that slow 
down Java's database connection performance to other DB vendor products?  After 
they've been alerted about the problem, given a chance to correct it, and chose 
not to, that is.

[ ... ]
> Yes, this indicates that I think the LGPL without section 3 would 
> be non-open-source.

Does OSD #3 mean that "The license must allow [ALL] modifications and derived 
works, ...", without any restrictions?  I think ScoreC's 2d is perfectly reasonable.

-- 
-Chuck

--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3