From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 646B61381F3 for ; Sat, 15 Dec 2012 13:53:24 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7673C21C044; Sat, 15 Dec 2012 13:53:14 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id A202C21C081 for ; Sat, 15 Dec 2012 13:52:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id DD3D133DC98 for ; Sat, 15 Dec 2012 13:52:43 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5.5 tests=[AWL=-1.365, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.024, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1]) by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poKjSP_sSbVl for ; Sat, 15 Dec 2012 13:52:38 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id EBF6A33DCAD for ; Sat, 15 Dec 2012 13:52:37 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TjsAW-0001H7-0P for gentoo-dev@gentoo.org; Sat, 15 Dec 2012 14:52:44 +0100 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 15 Dec 2012 14:52:43 +0100 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 15 Dec 2012 14:52:43 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: [gentoo-project] eudev project announcement Date: Sat, 15 Dec 2012 13:52:21 +0000 (UTC) Message-ID: References: <50CBF400.2060104@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT 04c43ec /usr/src/portage/src/egit-src/pan2) Cc: gentoo-project@lists.gentoo.org X-Archives-Salt: a54f2d99-1cb9-400a-a5ae-0db30b84e5b0 X-Archives-Hash: 36f5a16724ecb1fcbf88af0288d7c191 Rich Freeman posted on Sat, 15 Dec 2012 07:48:29 -0500 as excerpted: > On Fri, Dec 14, 2012 at 10:52 PM, Richard Yao wrote: >> The systemd developers were in the middle of a transition to >> the LGPL >> from the GPL when we forked. We inherited the code in the middle of >> that transition and we see no reason to pursue a different course. >> Therefore, all future changes that we make to eudev will be available >> under the LGPL. > > Not sure what the driver is to use LGPL, but in general the Gentoo > social contract requires that all contributions be made under GPLv2+ or > the CC BY-SAv2+. I'm sure exceptions can be made if they make sense and > are aligned with Gentoo's mission (likely something that would fall on > the Foundation to approve). If eudev were a non-Gentoo project then > Gentoo could depend on it as long as it used any OSI-approved license. > > Why not just use GPLv2+? The LGPL is compatible, so this would not > prevent us from merging udev changes. > > Not suggesting that we shouldn't use the LGPL if there is a good reason > to do so that is aligned with Gentoo's mission. I would just like to > understand the reason for it. The biggest reason surely must be two-way license compatibility with udev, allowing patch-flow both ways. As I said in an earlier post, at least from my perspective, the ideal outcome would be that the very presence of eudev creates conditions where the reasons why it was forked no longer exist, and the two projects can ultimately remerge. Surely, as a fork the PR problems are bad enough, and we don't want to be the ones deliberately throwing legal/license road blocks into the way of two-way patch-flow, making the situation worse. If the conditions that triggered eudev forking don't improve, let it be due to decisions from the OTHER side, not due to decisions here. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman