brian at collab.net
Mon Jan 22 08:21:50 UTC 2001
On Sun, 21 Jan 2001 kmself at ix.netcom.com wrote:
> A philosophical point first: I believe that attempting standards
> enforcement through copyright licensing is fundamentally broken. We've
> seen this tried several times, with the Artistic (control over "Perl"
> name), and SCSL licenses, the results tending to be that the license
> doesn't work as intended or doesn't meet the OSD. Wrong tool for the
Thoughts on the SISSL? It doesn't make adherence mandatory, but it does
say you have to release a reference implementation of your divergence from
> I'd argue that tying allowed modification to specific compatibility
> standards is a violation of:
> - Condition 3, Derived Works: Is the original license bound to the
> same terms, or could the authors modify the code to be incompatible
> with the MPEG-4 standard. This might be a stretch, but I'd argue it
The license does *allow* derived work (allow != unconditionally allow),
and that derived work, since it's conformant to the standard, can be
distributed under the *same* terms. However, the protocol standard
effectively enumerates more conditions on that allow, and if any of those
conditions are not OSD conformant (my CSS example), the license as a whole
> - Condition 6, Discrimination against fields of endeavor: This is IMO
> far more clear cut. Restricting application of the license to code
> meeting specific compatibility requirements is imposing a
> restriction that a work *not* adhering to this standard is not
> permitted. The discrimination is against any field of endeavor
> which isn't directly focused on MPEG-4.
This whole clause is a seriously vague mess, because "field of endeavor"
isn't defined anywhere and has no (that I know of) rigorous standard
definition in copyright law. By one stretch, the GPL discriminates
against a field of endeavor: the commercial-license-driven software
market. You may say, "but what if I just want some small bit
of the code, like a compression algorithm, to use in a web server? It
doesn't even make sense to talk about MPEG-4 in that case." Well, that's
a *practical* issue, but many open source licenses have that problem.
On Sun, 21 Jan 2001, Ben Tilly wrote:
> What do you think about permitting any change you want, but
> requiring changes that break a given standard to state that
> fact whenever and wherever they display notifications that
> it is derived from __X__ that it does not actually meet
> standard __Y__?
I don't see it as affecting OSD conformance. Personally speaking, I don't
think it's strong enough - I prefer the SISSL's requirement of publishing
a reference implementation of your changes, so that you can't use that
noncompliance to gain market advantage.
More information about the License-discuss