Fwd: Re: Updated license - please comment
Chuck Swiger
chuck at codefab.com
Mon Jun 23 19:57:04 UTC 2003
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
More information about the License-discuss
mailing list