OpenDivX license

[kmself at ix.netcom.com]

on Thu, Jan 18, 2001 at 09:51:40PM -0800, Brian Behlendorf (brian at collab.net) wrote:
> On Thu, 18 Jan 2001, Patrik Wallstrom wrote:
> > http://www.projectmayo.com/opendivx/divx_open_license_v10.txt
> > 
> > This license has not been approved by OSI, has it?
> > 
> > They call OpenDivX an Open Source-project, but limits the code to be
> > compatible with the MPEG-4 standard:
> > 
> > 6. Any Codec or Larger Works created by you must conform to the
> > MPEG-4 Video Standard.
> > 
> > The license contains other things as well...
> 
> On a casual rereading of the OSD I don't see any provision of the
> OSD that such a requirement would contradict, though clearly the
> provisions of that "standard" might conflict with the OSD and the
> document that describes that standard should be considered part of the
> license itself.  For example, if the "standard" said "no software
> implementing this protocol may have its source code revealed" e.g., the
> CSS standard for DVD decryption, there's no way that license could be
> considered Open Source.  
> 
> The big issue is, who gets to judge conformance?  How would a negative
> judgement be challenged?  If the license provided two paths to follow
> depending on the conformance of the software to that standard, with both
> paths being legit under the OSD, that's ideal.  See the SISSL for an
> example of a license such as the above.

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.

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.

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

Cheers.

-- 
Karsten M. Self <kmself at ix.netcom.com>    http://kmself.home.netcom.com/
 What part of "Gestalt" don't you understand?       There is no K5 cabal
  http://gestalt-system.sourceforge.net/         http://www.kuro5hin.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20010121/a3a216b0/attachment.sig>