linux-kernel - Re: Wasting our Freedom

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: <46F02902.3040003@pobox.com>
Date:	Tue, 18 Sep 2007 15:37:38 -0400
From:	Jeff Garzik <jgarzik@...ox.com>
To:	"Can E. Acar" <can.acar@...-g.com.tr>
CC:	Theodore Tso <tytso@....edu>,
	Claudio Jeker <cjeker@...hard.n-r-g.com>,
	Adrian Bunk <bunk@...nel.org>, misc@...nbsd.org,
	linux-kernel@...r.kernel.org,
	Daniel Hazelton <dhazelton@...er.net>,
	Eben Moglen <moglen@...twarefreedom.org>,
	Lawrence Lessig <lessig_from_web@...ox.com>,
	"Bradley M. Kuhn" <bkuhn@...twarefreedom.org>,
	Matt Norwood <norwood@...twarefreedom.org>
Subject: Re: Wasting our Freedom

Can E. Acar wrote:
> As long as it is not a derived work, Reyk gets to decide who is in the
> copyright. Even if it is a derived work, it is polite to ask.

Additional work went in, thus additional copyrights were added.

> I am really disappointed by all this.  I would have expected that once
> such a patch is suggested (let alone being committed to some public place)

In a purely open development environment, even personal developer trees 
are made public.  That's the way we _want_ development to occur.  Out in 
public, with a full audit trail.

Your implied ideal scenario is tantamount to guaranteeing that mistakes 
are never committed to a public repository anywhere.  Mistakes will 
happen.  Even legal mistakes.  In public.

> some senior/respected/responsible Linux person would tell them what they
> are doing is wrong.  Right from the start.

What you are seeing is an example of mistakes that were caught in 
review, and corrected.

That's how any scalable review process works...  the developer reviews 
his own work.  the team reviews the developer's work.  the maintainer 
reviews the team's work.  the next maintainer reviews.  and so on, to 
the top.

	Jeff

-
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/