Subject:
Re: [discuss] licence problems
From:
Rick Moen ####@####.####
Date:
26 Sep 2008 15:55:04 +0100
Message-Id: <20080926145501.GE1041@linuxmafia.com>
Quoting Jean-Daniel Dodin ####@####.####
> well, in this case, you have to quote or link real trustable source
> (sorry, nor your opinion nor mine have any legal value)
I'm unclear on why we're talking about this, anyway. In the case of
document patches, the maintainer can merely decline to accept patches
offered under any terms other than those of the main document, and then
whether your view about what the term "dual-licensing" either does mean
or should mean is completely irrelevant.
So, your series of questions and arguments would seem irrelevant to
LDP's situation in the first place. If you care to debate the matter,
maybe you should go over to OSI's license-discuss and see if anyone
cares to discuss it, as I don't really see the point in our context.
> but it seems the same to all the document linked from this wikipedia
> page.
Let's look at that. The Software Freedom Law Center -- one of the few
that I really respect (though one must always be aware that they push
the FSF agenda) -- for example, includes:
A more complicated case occurs when a developer makes copyrightable
changes to a permissive-licensed file that the developer is
incorporating into a GPLd program. Developers in this situation
typically apply the GPL to their modifications. (However, it is possible
for the developer instead to contribute new code under permissive terms,
such as the permissive license that governs the unmodified file. We
discuss that case in section 2.3.)
Even though the permissive license of the external project grants legal
permission to incorporate code from that project into a GPLd
project, the developer of the GPLd project must nonetheless comply
with the notice preservation requirement in the permissive license.
[...]
Developers of GPLd projects sometimes wish to allow certain parts
of their work to remain available to other projects under permissive
terms. Most commonly, the goal is to facilitate ongoing cross-project
collaboration with other developers. One common example is that of a
GPLd project that includes some code that can be shared with
another project under the modified BSD license.
Contributions made to a GPLd project are typically themselves
licensed under the terms of the GPL. If project maintainers have some
files that should remain wholly under permissive terms, the stewards of
the codebase should take great care to obtain explicit licensing assent
from each contributor to (or patcher of) the file in question. The
contributor should signify clear agreement that his changes are
permissive-licensed.
[...]
The other half of the question is whether the non-GPL license presents
any obstacle to incorporation of the code it covers into a larger work
that is covered as a whole by the GPL's copyleft. For most who are
familiar with such licenses, the answer might appear to be obvious, but
it deserves some attention. The terms of permissive licenses allow
unlimited modification and redistribution in source or binary form, so
long as the stated minimal notice preservation requirements are met. An
isolated reading of these simple licenses, in ignorance of historical
community practice, can in some cases support more than one
interpretation, depending on whether certain permissions are implicit or
explicit and on the treatment of that difference under local law.
From the beginnings of their use, however, the permissive licenses have
been understood by their licensors and licensees alike to permit the
code they cover to be incorporated within larger works covered as a
whole by more restrictive terms, including more restrictive FOSS
licenses like the GPL as well as, indeed, by proprietary licenses. This
understanding represents the uninterrupted, longstanding practice and
expectation of the global information technology industry, including
both its free and proprietary divisions, with vast commercial reliance
on the result. As such, disruption of the established interpretation of
the permissive licenses is neither likely nor desirable.
Which is correct.
> This alone seems to say that the word "dual licencing" is not
> sufficient to set the definition, or where is the true definition?
It's certainly true that there are a lot of confused and/or
contrary-minded people out there who have been known to use the term
"dual licensing" to mean peculiar things. That is one reason why I was
quite explicit in what I meant when I recommended the practice to
Senthil Kumaran, and cited a working example.
The SFLC article alludes to chowderheads out there using the term to
mean other things, though it's polite about the matter:
Developers sometimes attempt to explicitly "dual license"
their code under the GPL and a permissive license. The term "dual
licensing" is most properly used to refer to giving the recipient a
choice of being a licensee under "license A" or "license
B". Unfortunately, the term is also commonly used to describe
different kinds of licensing arrangements.
So, let us say that I recommended to Senthil what I and other longtime
discussers of licensing regard as a sensible and useful understanding of
the term "dual licensing", rather than any number of peculiar and dumb
ones.
And any belief that a creator of a derivative work somehow gains the
power to "relicense" (to GPL or anything else) code borrowings from
third parties is simply, objectively unclear on the nature of property
law. SFLC is, predictably, clear on this point:
Once all relevant copyright holders in the relevant files have been
identified, their assent to relicensing of the work must be secured.
Relicensing is possible only with explicit _permission_ of the relevant
copyright owner. (I stress this because computerists have often made
the error of assuming otherwise because of wording like that of GPLv2
clause 3b, somehow failing to notice that they're assuming the right to
act like the owner of someone else's property. I try to warn them
otherwise, so they won't get into legal trouble with copyright owners.)
And unless the relevant property owner quite literally says "You have my
permission to strip part of my terms of use from this work, in handing
copies to downstream users", I'd suggest that only an extremely reckless
person would assume that privilege concerning a right very clearly
reserved to copyright owners by law.
I assure you, I issued no such right in my licensing on the WordPerfect
for Linux FAQ, and think that the author's intention in my and all
similar situations is abundantly clear, from the circumstances and our
wording -- and would be really clear to any judge.
> Notice, I don't challenge the facts under the dual licencing, only the
> use of the words as it.
OK, fine. Some other people have been known to use the term
"dual-licensing" to mean any number of very peculiar things. I did not
mean those other things, and was very clear on what I meant. Are we
done, please?
