OpenDivX license

[Brian Behlendorf]

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
> task.

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
the standard.

> 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
>     hard.

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
is not.

>   - 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.

	Brian