Re: DRAFT d-l summary of the OSL v2.0
Scripsit Jeremy Hankins <nowan@nowan.org>
> The bigger issue, though, is that I didn't provide a DFSG section for
> the first problem. The closest the DFSG comes to prohibiting use
> restrictions is #6 ("No Discrimination Against Fields of Endeavor"), but
> I'm uncomfortable using that for this issue -- is "deploying software
> without providing source" a field of endeavor)?. If "a specific field
> of endeavor" is intended that broadly, it should be reworded, IMHO.
The explanation we usually give is that it is implicit that the
freedoms required by the DFSG must not have any strings attached.
A right that has uncommon strings attached (such as forced
distribution) is consideret not to be there when we consider a
license.
There is no DFSG #0 that requires the right to *run* the program,
because the prevailing legal opinion is that copyright cannot restrict
use in the first place. If the license demands that one accepts a
restriction on use as a condition on getting the other rights the DFSG
requires, is an attached string. As such, it renders all of the other
rights void for the purposes of applying the DFSG to it.
The DFSG is an imperfect document - back when it was written its
authors could not conceive of all the strange ways people have since
tried to erode the freedom of their software. Therefore, it is not
always possible to cite a particulare phrase in the DFSG as an
explanation why a license feature is non-free. That does not make it
any less non-free, however. That's why the G is for Guidelines.
> Perhaps we should think about language to add to the DFSG for this
> kind of case?
I wish you luck. But we can never be sure that any formulation of the
DFSG will describe exactly the next kind of non-freeness we come
across.
--
Henning Makholm "`Update' isn't a bad word; in the right setting it is
useful. In the wrong setting, though, it is destructive..."
Reply to: