On Tue, 23 Jan 2001, Brian Ristuccia wrote:
> It's not an open source license. Term #6 places limitations on distributing
> modified copies.
Erm, so does every copyright license. To be specific, it sounds like
your concern is over adherence to a standard being one of the conditions
for redistribution. I don't see that as a problem, but that standard is
now effectively part of the license, and the standard itself has to come
under DFSG conformance checks - for example, if the standard went beyond
talking about data formats and such, and contained a clause that said,
"you may not reveal the secret key used for decryption to an end-user" a
la CSS, then it would not be OSD-conformant. But if, reductio ad
absurdum, the standard said simply, "the software must communicate on port
80", that wouldn't violate the DFSG.
One way out of it is to do what the SISSL does, which is say, effectively
"you can take one path if you remain conformant to the standard, you can
take another path if you don't wish to remain conformant", and both paths
are DFSG-conformant, thus it doesn't really matter what the text of the
standard is.
> The license attempts to place restrictions on actions
> beyond the scope of copyright via a clickwrap/shrinkwrap/implicit acceptance
> mechanism.
Yep, you're right, those restrictions on how it can be used does make it
non-DFSG-free. In context of the above, someone should be able to modify
and use the software in a way not conformant to the MPEG-4 specifications,
but the license is fine in saying that modification can't be redistributed
(just as I can't distribute software that violates the GPL).
> Additionaly, it attempts to discriminate against use by persons
> engaged in certain fields of endeavor.
How so? Those who wish to use some snippet of the software in another
application, you mean? That may be unfortunate, but that's not a "field
of endeavor". At least IMHO, of course.
Brian
