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

Re: DFSG FAQ (draft)

Barak Pearlmutter <barak@cs.may.ie> writes:

> With a little help, I've composed a draft DFSG FAQ.  It meant as an
> introduction to issues discussed on debian-legal, with some general
> background material to help bring naive readers up from ground zero.
>  http://people.debian.org/~bap/dfsg-faq.html

Here are a few suggestions:

You may want to mention the pine license fiasco wrt question #3, as
it's an excellent example of a license that would ordinarily have been
considered free, but the copyright holder had an odd interpretation of
the license which we decided to honor, thus making it non-free.

7. (d), answer:
No, not unless the clickwrap stuff can be removed.  In principle one
could put the GPL in a clickwrap and the license would be perfectly
fine.  But once you add a requirement that the software must be
distributed via the clickwrap, or that clickwrap code can not be
removed from the software your license becomes non-free.  Since
clickwraps without such a requirement are a bit pointless, clickwrap
licenses are virtually always non-free.

In 7 (g) & (h) you mention adding suggestions that are not part of the
license.  Whether these suggestions are part of the license text (even
if optional) is left ambiguous.  The advantage to being part of the
license text, of course, is that it becomes a sort of "invariant text"
that must follow the work.  I'm not saying we should necessarily
change that, mind, we may *want* that to be ambiguous so as to avoid
folks adding lots of extraneous text to licenses.

In the answer to question 9 it might be worth noting the question of
whether or not things can actually be released into the public
domain.  My understanding is that debian-legal generally quietly
re-interprets such claims as an extremely permissive license.

11 A:
In order for two licenses to be compatible it must be possible to
mingle code under both licenses in a new work.  When this is done the
result is that the terms of both licenses must be met for the work as
a whole.  The GNU GPL makes this feature of copyright law explicit by
stating that if you cannot for any reason (e.g., because of another
license) meet the terms of the GPL, the GPL grants no rights at all.
In order for a license to be GPL compatible, then, you must be able to
meet both the terms of the GPL and the other license simultaneously.

12 A: (should probably be combined with 13)
When a work is released under a dual license the recipient is
explicitly given the option to choose which license to apply to a
derivative work.  Someone making modifications may include new
code under the GPL (thus making the result strictly GPL) or the
alternative license (thus selecting the alternate license).  The GPL
is particularly common in dual licenses because it allows the code to
link with the large number of GPL code out there, or to be pulled into
GPL works.
(I'm not sure where you want to go with the bit about "dual GNU
GPL/Artistic" or "dual GNU GPL/QPL".)

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

Reply to: