Re: DRAFT d-l summary of the OSL v2.0
Jeremy Hankins wrote:
> 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.
Another possibility is "No restriction of uses which are already allowed
without a license". Although it doesn't deal with people in weird places
where such things *do* require licenses. But if you already need a license
to use the work, I actually wonder if it is free enough to require that
everyone being allowed to use the work be given source. (Since you have to
be given explicit permission to use it, you already have to distribute that
permission, so you already have to distribute something....)
Or should we strike a preemptive blow against such jurisdictions? :-)
--
There are none so blind as those who will not see.
Reply to: