Re: OpenDivX license
On Thu, 25 Jan 2001, Joseph Carter wrote:
> 6. No Discrimination Against Fields of Endeavor
>
> The license must not restrict anyone from making use of the program
> in a specific field of endeavor. For example, it may not restrict the
> program from being used in a business, or from being used for genetic
> research.
>
> If a license says you cannot use this software for x, that is almost
> always a violation of the DFSG. Software that must never be modified to
> deviate from a standard quite clearly fails the above.
Uh, no. At least, not from the above - you're extrapolating "field of
endevor" to "can not use software for x", where I presume "x" is your term
for "non-standards-compliant use". The examples used above are very
different from a clause talking about a protocol standard, and not just a
technical difference. For example, a license stating "this software can't
be redistributed by a genetics company" would leave me, if I were a
programmer for Genentech, completely out of luck, by virtue of who I am.
However, if it said "I can't distribute a modification that violates a
standard", that doesn't lock me out, that just says I have a hoop I have
to jump through. So, ethically it's a much different case.
The "rationale" given (written originally by Perens, I presume) is: "the
major intention of this clause is to prohibit license traps that prevent
open source from being used commercially. We want commercial users to join
our community, not feel excluded from it."
> If you believe this has no practical limitations, consider the case of
> a proprietary codec modification by Microsoft---they'd NEVER do that
> right? According to this license, this software could not be modified
> to support those proprietary extensions since they violate the spec.
Sure. Did you see the part where I said "I didn't like it"? I don't
think this is a good thing either. A bigger hindrance would be for
those who want to modify the program to support the next version of the
same protocol.
But neither do I like some of the patent clauses that have gotten into
open source licenses, etc. However, I do not believe it violates the
language of the DFSG or OSD.
> In spirit, practice, and language this fails the DFSG.
In spirit, yes. I would suggest that the whole issue of standards
adherence might require a new clause, something like:
Rights to redistribution must not be restricted by adherence
to a specific standard for the behavior of the software.
Perhaps with a second sentence describing the situation with the SISSL,
where when one violates the standard they can do so so long as they
publish their code (or at least a reference implementation of that
change), thus providing two paths both of which are DFSG-free. However,
does this impact the GPL, which talks a bit about how programs may be
legally linked to non-GPL software?
I'll even volunteer to author the rationale. =) The best one: standards
are ephemeral (change often), licenses are "forever" (at least until
someone rewrites it).
> > DFSG #4 gets closer: it says that the license has to allow someone to be
> > able to distribute a patch that, say in the above example, replaces the
> > hard-coded port 80 with another port, "with the source code" - I don't
> > know if that means mere aggregation on a CDROM and/or in a similar
> > directory on a web site, or if it can be a part of the .tgz, etc.
>
> Ah, but that works only as long as binaries may be distributed with those
> patches applied. Since that's not the case here, it's irrelivant.
Uh, no. I don't see a requirement in the OSD that licenses have to
unconditionally allow modified binaries. #4 does say, "the license must
explicitly permit distribution of software built from modified source
code" - and that is permitted, so long as the standard is adhered to.
For the third time, I don't like this, and this is not in the spirit of
the DFSG or OSD. I won't make a blanket statement, though, that this is a
totally bad thing that should be ignored.
For some people, the mishmash of almost-but-not-quite-incompatible
software out there all implementing some subset or mis-set of open
standards, is a greater threat to the future of software openness than
having all the underlying code to the applications you use. It's not a
perspective the DFSG or OSD needs to adopt, of course, but it's not
incomprehensible.
I think Debian (and OSI) needs to decide whether or not this is a
philosophy they reject, and thus patch the hole in the DFSG/OSD. Or,
ignore it until it becomes an actual issue. It was this kind of
ambiguity, as well as a lack of general public interest in seeing problems
in the OSD/DFSG, that contributed to my resignation from OSI.
Brian
Reply to: