Fwd: Re: Updated license - please comment

[Chuck Swiger]

Mark Rafn wrote:
[ ... ]
>> Does OSD #3 mean that "The license must allow [ALL] modifications and derived
>> works, ...", without any restrictions?
> 
> IMO, pretty much yes.  

Hmm.  I agree that users of open source software generally should have the right 
to fork and distribute modifications of software, even if the original author 
"doesn't like it".

In the context of the ScoreC/RSPL's #2A, I think users should be able distribute 
a version of ScoreC that is not a library.  I have not seen RPI provide a good 
reason as to why this restriction is in the best interest of the ScoreC  project 
or the end-users.  Absent a compelling justification, I would agree with Mark 
that RSPL #2A conflicts with with a reasonable definition of "open source" (*).

However, I submit that software authors sometimes do have legitimate interest in 
maintaining the "integrity" of their projects by limiting redistribution.  If 
there was a compelling reason behind #2A, which was also in (or at least mindful 
of) the best interests of the end users and the rest of the open source 
community, then that reason should be considered on its merits.

>> 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.
> 
> It's nearly impossible to define "deliberately broken or malicious" in
> such a way that would make the result free enough to be called
> open-source.  It's very valid to re-use code in a way that violates
> standards, spoofs headers to interoperate with other programs, etc.

I agree that it's a valid part of open source to re-use code, spoof header 
files, etc: for example, 'top' contains spoofed version of a header file which 
defines the structure of a process table entry for each operating system.

I don't insist upon having a 100% unambiguous definition for "deliberately 
broken or malicious", any more than I feel the need to define "self defense".

Judges exist to resolve ambiguous cases.

> Heck, even trying to specify that this code cannot be used in 
> self-propagating malware would violate the "fields of endeavor" clause of 
> the OSD.
> 
> It's perfectly reasonable to demand that forks are distinguished from the 
> original "official" version, but open-source software does not prevent 
> modifications just because we don't approve of the use.

Open source software certainly should not contain broad restrictions on 
redistribution: if any restrictions are permissible, they should be 
well-justified, narrowly focused, and non-discriminatory.

In particular, software which performs cryptography and authentication such as 
OpenSSH, OpenSSL, SASL, and so forth has critical ramifications to the end-user. 
If the authors of that software wanted to forbid "deliberately broken or 
malicious" redistributions in their license, well, I perceive some degree of 
validity to such a position.

Maintaining the integrity of the calculations performed by crypto software is 
not a hypothetical problem-- refer to the CERT advisories I'd mentioned to 
David.  To the extent that this reasoning applies to the RSPL, that is why #2D 
strikes me as a reasonable restriction and one which does not necessarily 
exclude the RSPL from being open source.

[ 2A is a different matter, however. ]

-- 
-Chuck

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