[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Referencing the DFSG [Re: DRAFT summary of the OPL; feedback requested]

Don Armstrong <don@donarmstrong.com> writes:
> On Wed, 10 Mar 2004, Jeremy Hankins wrote:

>> The interesting part of the claim in a summary isn't that
>> restrictions on modifying make a license non-free, but that the
>> license restricts modifying.  The summary doesn't describe the DFSG,
>> it describes the license.
> Obviously. But in describing a specific case, it's rather trivial to
> say "This section restricts modification (DFSG §3)." This allows
> others reading your arguments to recognize their foundations.

The foundations are already clear: the DFSG.  I'm not convinced that
explicitly specifying a paragraph is better than implicitly specifying a

>> You think that the sections of the DFSG provide a useful taxonomy of
>> non-free licenses?
> In some circumstances, yes. By seeing which clauses of the DFSG are in
> violation, it becomes much easier for our ftp-masters to see if there
> is something in the license that would restrict the work from being
> able to even be redistributed in non-free, as an example.
> Additionally, it helps others who are attempting to interpret the DFSG
> to see licenses which have preiviously failed sections of it and
> understand the line between Free and non-free.

This I absolutely disagree with, and is just the idea that I hoped not
to encourage by not including section numbers.  As this is more of a
claim than an argument I can't actually refute your reasoning, since you
haven't given it.  The only thing I can say is that reducing the reasons
for a license to be considered non-free to "violates DFSG section N" is
a gross simplification, and can't in any way improve license analysis.
Of course, we'll (I hope!) include more than that in the summaries.  But
I suspect that those who aren't as interested in the legal details will
gloss over that, and simply think in terms of DFSG sections.

>> That would be very surprising, as I don't believe it was written
>> with that in mind.
> Works often end up in more than the role they were designed for.

Of course.  But coming up with a good taxonomy is Hard(tm).  The idea
that Bruce Perens happened upon one by accident while writing the DFSG
is very surprising indeed.  Perhaps he has a turing-complete compost
heap as well?

What's far more likely is that it will function (badly) as a taxonomy
and introduce unnoticed misconceptions and errors.  This is a far more
common occurrence, even when the categorization was developed
deliberately.  The best thing that can happen is it simply won't work at

>> I guess we'd have to do a survey of licenses in order to have hard
>> data to support or deny this idea.  But my sense (based on my
>> experience reading d-l) is that useful categories of license tend to
>> be largely orthogonal to the way the DFSG is split into sections.
>> Licenses don't tend to neatly and simply fail some section of the
>> DFSG.
> No, they usually tend to fail multiple sections, and get all sorts of
> things wrong, some of which aren't even included in the DFSG.

They also tend to fail particular sections in all sorts of very
different ways, and fail different sections in very similar ways.
That's what being orthogonal is all about.

>> I think that the idea that the DFSG neatly and simply captures the
>> ways that licenses can be non-free is very much tied to the idea
>> that the DFSG could be used as a definition.
> Obviously. But we're not talking about "capturing" here.

Then what are you talking about?  If the section of the DFSG a license
fails doesn't capture anything, why include that datum?

> If your
> contention that a license is not free is based upon the DFSG, it
> should state so.

See my first paragraph (quoted) above.  My claim *isn't* that it
violates the DFSG, but that it restricts modification.  Once you
establish that it restricts modification, the rest is trivial.  Thus
what you're saying applies very well for things like the dissident test,
as referring to that is a stand in for more argumentation.  But DFSG
section numbers don't stand in for much of anything.

>> > There are licenses which violate specific sections of the DFSG. We
>> > can use that information to compare licenses and become better at
>> > interpreting the clauses of the DFSG in an appropriate manner.
>> Can you give an example, or provide more detail? 
> When I'm examining licenses that have a strange set of wording, and
> seem to fail a particular portion of the DFSG, I often want to go back
> and look through the discussion of other licenses with similar terms
> that have also failed the DFSG.

So you want a database of similar terms.  Great idea, though I don't see
how you plan to do it without first coming up with a good taxonomy.
What's that have to do with the DFSG?  Or are you claiming that
everything that fails section 3 of the DFSG will be similar?


A) "Derivative works must include your correct address and phone number."

B) "If you redistribute the original, you must include your address and
   phone number."

C) "If you distribute the original, you must first dance a jig."

D) "You must license any modifications to me under the BSD license."

E) "In order to download this file, you must first dance a jig."

F) "You may not use modified versions unless you give me a copy."

G) "You may not use this program unless you pet a penguin."

Does putting these clauses into categories based on the section of the
DFSG they fail really capture the similarities and differences between
these license terms?

> That allows me to say "licence Foo has a clause with the same net
> effect as license Bar which we found violated DFSG §6 for the reasons
> we delinated in [debian-legal thread]"

If you have an index of similar terms, that would indeed be a possible
benefit.  But indexing on DFSG section is not going to give you that.

Jeremy Hankins <nowan@nowan.org>
PGP fingerprint: 748F 4D16 538E 75D6 8333  9E10 D212 B5ED 37D0 0A03

Reply to: