Re: OpenDivX license
On Sun, 21 Jan 2001 [EMAIL PROTECTED] 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
Re: OpenDivX license
on Thu, Jan 18, 2001 at 09:51:40PM -0800, Brian Behlendorf ([EMAIL PROTECTED]) 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 [EMAIL PROTECTED]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 PGP signature
Re: OpenDivX license
[EMAIL PROTECTED] wrote: on Thu, Jan 18, 2001 at 09:51:40PM -0800, Brian Behlendorf ([EMAIL PROTECTED]) 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. Donald Knuth enforced a standard through copyright with TeX. I think it worked well, even if the result is not open source. 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. 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__? This could be useful for reference implementations. There might be absolutely no problem with borrowing code from the implementation and using anywhere. However it is important to require that if it is used in something not compatible with the standard that there be no possibility of creating confusion with the standard. Cheers, Ben _ Get your FREE download of MSN Explorer at http://explorer.msn.com
OpenDivX license
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... -- patrik wallstrom | f o o d f i g h t tel: +46-8-6188428 | s t o c k h o l m gsm: +46-708405080 | - - - - - - - - -
