From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1S3DF6-000552-R4 for garchives@archives.gentoo.org; Thu, 01 Mar 2012 21:08:53 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6DA12E0955 for ; Thu, 1 Mar 2012 21:08:52 +0000 (UTC) Received: from foo.stuge.se (foo.stuge.se [212.116.89.98]) by pigeon.gentoo.org (Postfix) with SMTP id C1AE5E07ED for ; Thu, 1 Mar 2012 19:05:38 +0000 (UTC) Received: (qmail 1674 invoked by uid 501); 1 Mar 2012 19:05:36 -0000 Message-ID: <20120301190536.1673.qmail@stuge.se> Date: Thu, 1 Mar 2012 20:05:36 +0100 From: Peter Stuge To: gentoo-embedded@lists.gentoo.org Subject: Re: [gentoo-embedded] Licence compliance - capturing all source files used to make a build? Mail-Followup-To: gentoo-embedded@lists.gentoo.org References: <4F4E3A61.5020208@wildgooses.com> <20120229173928.30124.qmail@stuge.se> <4F4EC477.3070502@wildgooses.com> <20120301033639.11663.qmail@stuge.se> <4F4F3140.1070406@wildgooses.com> <20120301145340.13698.qmail@stuge.se> <4F4FC693.9030204@wildgooses.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-embedded@lists.gentoo.org Reply-to: gentoo-embedded@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F4FC693.9030204@wildgooses.com> X-Archives-Salt: 75e2c6d7-86a1-4672-b579-60eed886ef41 X-Archives-Hash: a254c662c68f7a9b3964bbc877301bcd Ed W wrote: >>> Whilst I guess it should be possible to tear apart catalyst and find out >>> how they do it, does anyone happen to know or have a heads up on the code >>> for catalyst? >> >> The catalyst code has no part in this, but it takes a portage snapshot >> as one of it's inputs, and if you maintain a custom snapshot (with >> only packages you need) then you know what gets used. > > But not all the patches are in the portage tree? Trivial example might > be the kernel where the ebuild is tiny and references an http location > for the patches? Then you would change the kernel ebuild in your snapshot, so that it becomes self-contained. For the specific example of the kernel you could of course just pick vanilla-sources, but the issue is real. > My understanding is that for a GPL licence one should provide a > copy of these patches in the "code dump", not just an http link? > Is that your understanding? I think your understanding is incomplete, and I recommend that you read through the license again. There isn't just a single way to provide the source, but yes, if you have downloaded and included a patch in your binary, then you have to provide that patch yourself, because if you refer to someone else and they stop providing the patch you would no longer be in compliance. > So by implication it's not clear that catalyst does satisfy your GPL > requirements for distribution? I never say it did. I said that it helps with some things. > I suspect something more is probably happening, eg some of the linked > patches probably get included into the source download location and > probably you can pick them up there - however, there are now a LOT of > ways to fetching source and patches and it would be hard to be sure > of 100% coverage? Fourth time: Add bookkeeping into the epatch function. Downloading is irrelevant, especially since sometimes many more patches are downloaded than are actually applied. > Has someone done some actual probing on this? Peter what does catalyst > provide for say gcc/kernel sources in it's source output? All the patches? It's the other way around: You provide a snapshot to catalyst, and catalyst builds kernel from that. You say what you want catalyst to build, and you create the package. You may end up doing more ebuild maintenance, but you likely want to do just that anyway, in order to keep track of what actually goes into your system. //Peter