Code is contributed to the Linux kernel under
a number of licenses, but all code must be compatible with version 2 of the GNU
General Public License (GPLv2), which is the license covering the kernel
distribution as a whole. In practice, that means that all code contributions
are covered either by GPLv2 (with, optionally, language allowing distribution
under later versions of the GPL) or the three-clause BSD license. Any
contributions which are not covered by a compatible license will not be
accepted into the kernel.
Copyright assignments are not required (or
requested) for code contributed to the kernel. All code merged into the
mainline kernel retains its original ownership; as a result, the kernel now has
thousands of owners.
One implication of this ownership structure is
that any attempt to change the licensing of the kernel is doomed to almost
certain failure. There are few practical scenarios where the agreement of all
copyright holders could be obtained (or their code removed from the kernel).
So, in particular, there is no prospect of a migration to version 3 of the GPL
in the foreseeable future.
It is imperative that all code contributed to
the kernel be legitimately free software. For that reason, code from anonymous
(or pseudonymous) contributors will not be accepted. All contributors are
required to "sign off" on their code, stating that the code can be
distributed with the kernel under the GPL. Code which has not been licensed as
free software by its owner, or which risks creating copyright-related problems
for the kernel (such as code which derives from reverse-engineering efforts
lacking proper safeguards) cannot be contributed.
Questions about copyright-related issues are
common on Linux development mailing lists. Such questions will normally receive
no shortage of answers, but one should bear in mind that the people answering
those questions are not lawyers and cannot provide legal advice. If you have
legal questions relating to Linux source code, there is no substitute for
talking with a lawyer who understands this field. Relying on answers obtained
on technical mailing lists is a risky affair.
0 comments:
Post a Comment