linux-kernel - Re: [PATCH 01/12] thinkpad_ec: New driver for ThinkPad embedded controller access

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20060806145551.GC30009@thunk.org>
Date:	Sun, 6 Aug 2006 10:55:51 -0400
From:	Theodore Tso <tytso@....edu>
To:	Shem Multinymous <multinymous@...il.com>
Cc:	Andrew Morton <akpm@...l.org>, rlove@...ve.org, khali@...ux-fr.org,
	gregkh@...e.de, alan@...rguk.ukuu.org.uk,
	linux-kernel@...r.kernel.org, hdaps-devel@...ts.sourceforge.net
Subject: Re: [PATCH 01/12] thinkpad_ec: New driver for ThinkPad embedded controller access

On Sun, Aug 06, 2006 at 01:44:02PM +0300, Shem Multinymous wrote:
> On 8/6/06, Andrew Morton <akpm@...l.org> wrote:
> >I suggested a simple solution: Perhaps one of the other project members
> >(ie: one who uses a real name) could also sign off the patches?
> 
> Well, I offer this patch under the GPL, so anyone (including you) can do it.

But who is "I", and how do we know that you really do have the legal
authority to offer the patch under the GPL?  *That's* the whole point
of the DCO.  It is a lightweight version of what the FSF requires,
which is a legal contract asserting the same, with an ink signature
and (at least in some cases) notarized by a public notary.  The
contract has some interesting words in it, including ones where the
signer indemnifies the FSF against any claims for the work that has
been contributed, but it's all there to protect the FSF.

Some have claimed that the FSF approach is too slow, too heavyweight,
and discourages contributions, but there is good legal reasons for why
they ask that of their contributors.  I might not be willing to sign
the FSF's contract, but that's a personal matter between me and the
FSF.  (And given the FSF's position on the GPLv3 and my current
distaste of the discussion drafts, it's just as well that I don't
contribute code to the FSF.)

The DCO is a more lightweight mechanism, which tries to establish a
legal chain of accountability for patches.  But in order to do that,
we need to know who is making the assertion, and a pseudonym defeats
the whole point of the DCO.  No, we're not requiring an ink signature,
and no we're not requiring a notary public to check the identity of
the person signing the contract --- but then again, it's not that hard
to fake the driver's license which the notary public checks.  The
point is that there is a process, and that we ask for a certain level
of assurance.  The fact that the FSF doesn't require DNA samples
doesn't mean that they shouldn't stop doing what they are doing, just
as the fact that we aren't requiring ink signatures and public notary
checks doesn't mean we shouldn't stop doing what we are doing.

> Can you please be more specific? What purpose does this exclusion
> serve, that would be realistically achieved otherwise? You already
> have a GPL license from the author, and a way to contact and uniquely
> identify the author.

For legal reasons, we need a way to to contact and identify the author
in the real world, not just in cyberspace, and a pseudonym doesn't
meet that requirement.

						- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/