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
