Re: DRAFT d-l summary of the OSL v2.0
Henning Makholm <henning@makholm.net> writes:
> 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.
Not really. Certain strings are considered acceptable -- keeping a
changelog, for example, or changing the name. The question is which
strings aren't acceptable. That's why we have tests like the Desert
Island test & Dissident test -- they help us to draw a line
distinguishing acceptable restrictions from unacceptable ones. But in
this case the question isn't whether the restriction is significant,
it's what's being restricted.
> 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.
Yes, but this isn't just copyright -- hence the click-wrap. We could,
of course, conclude that without going beyond copyright use restrictions
are impossible, thus not worth mentioning in the DFSG. But then what
about confused folks (or just folks in other jurisdictions?) who claim
use restrictions can come out of copyright? If we accept their claim
(as our policy generally suggests) it's still non-free, even if it
doesn't have a click-wrap.
> 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.
Absolutely. That's why I don't hesitate to say it's non-free, despite
not seeing how to ground that claim. But I do think that not finding a
grounding is a very important thing to note. At the least we should be
explicit about that in the summary, and at best we should try to find a
way to fix the DFSG so this particular issue doesn't show up again.
Frankly, that has the advantage of giving d-l's claims more legitimacy,
because we're following an appropriate procedure for getting this sort
of problem fixed, rather than appearing to be zealots trying to take
control.
>> 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.
But the goal isn't to handle every future kind of non-freeness. Just
this one. In my opinion, when we have a situation where we are
convinced that a clause is non-free despite not being able to ground
that claim in the DFSG we should:
- Provisionally state that we're calling the license non-free
- Come up with language that captures our intuitions on why the clause
isn't free
- Start working to get that language added to the DFSG
Assuming everyone agrees that this clause is non-free, and that no one
is able to point out why in terms of the DFSG, we need to decide how
best to capture this issue (and hopefully this class of issues).
>From what you say above, you see this as fundamentally about use
restrictions. On thinking it over, I think you're right. I'm hesitant
to try to describe it in terms of forced distribution when the GPL
already forces distribution of source code.
For example, one possibility would be to substitute the following for
DFSG #6 (since this is just a more general case):
----
6. No Discrimination Against Types of Use
The license must not restrict anyone from using the work for any
purpose. For example, it may not restrict the work from being used in a
business, from being used for genetic research, or from being used to
provide web services.
----
I can't think of a more conservative change that could be made that
would capture this particular problem.
--
Jeremy Hankins <nowan@nowan.org>
PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
Reply to: