On Wed, Jan 24, 2001 at 06:39:42AM -0800, Brian Behlendorf wrote:
> > Not only does term #6 prohibit me from distributing copies modified in this
> > way, it actually goes as far as trying to prevent me from making such
> > changes in the first place.
>
> Look, I didn't say it was a good thing. I simply said it doesn't violate
> the DFSG, as best I can tell - and I mostly bring this up to ask whether
> or not this is a hole in the DFSG and/or OSD that can be plugged, and
> secondarily whether people think that tying standards conformance to
> distribution rights is a good thing or not.
Read the DFSG again.
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. 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.
In spirit, practice, and language this fails the DFSG.
> > If the program in your reductio ad absurdum
> > argument were Apache, and the copyright holder would accuse me of breech of
> > contract for modifying the software to listen on a different port and accuse
> > me of copyright infringement if I distributed that modified version, we'd
> > all agree that minimum, such a term like #6 in the so-called OpenDivX
> > license violates DFSG #3.
>
> "Must allow" doesn't mean "Must allow unconditionally". The OpenDiVX
> license allows modifications and derived works, it's just that those
> modifications must adhere to a specific set of standards.
I believe you're missing a fundamental point.
> 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.
> I don't like this any more than you do. It's ugly. But to fix it you
> have to make a blanket statement about what the license can say about what
> the code implements - and I'd really be interested in a way to do that
> that doesn't similarly affect the GPL, at least as interpreted by Stallman
> when he came after L. Peter Deutsch regarding linking to readline's API
> from Ghostscript.
There are holes in the DFSG that fixing would be hard. There are holes in
the DFSG that fixing would be easy. This is neither.
--
Joseph Carter <knghtbrd@debian.org> Free software developer
<JHM> Somehow I have more respect for 14 year old Debian developers than
14 year old Certified Microsoft Serfs.
Attachment:
pgpNFuZAa3ieA.pgp
Description: PGP signature