From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id B56E1E0132F for ; Mon, 26 Mar 2012 14:02:48 -0700 (PDT) Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga101.ch.intel.com with ESMTP; 26 Mar 2012 14:02:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,217";a="81827854" Received: from orsmsx604.amr.corp.intel.com ([10.22.226.87]) by AZSMGA002.ch.intel.com with ESMTP; 26 Mar 2012 14:02:46 -0700 Received: from orsmsx102.amr.corp.intel.com (10.22.225.129) by orsmsx604.amr.corp.intel.com (10.22.226.87) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 26 Mar 2012 14:02:45 -0700 Received: from orsmsx101.amr.corp.intel.com ([169.254.8.154]) by ORSMSX102.amr.corp.intel.com ([169.254.1.160]) with mapi id 14.01.0355.002; Mon, 26 Mar 2012 14:02:45 -0700 From: "Rifenbark, Scott M" To: Rudolf Streif , "yocto@yoctoproject.org" Thread-Topic: [yocto] can all of the licensing discussion be centralized in an appendix? Thread-Index: AQHNC5JS6DKagFuvQkamcltRImRZSpZ9D7iA Date: Mon, 26 Mar 2012 21:02:44 +0000 Message-ID: <41DEA4B02DBDEF40A0F3B6D0DDB12379451766F4@ORSMSX101.amr.corp.intel.com> References: In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.140] MIME-Version: 1.0 Subject: Re: can all of the licensing discussion be centralized in an appendix? X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 21:02:49 -0000 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_41DEA4B02DBDEF40A0F3B6D0DDB12379451766F4ORSMSX101amrcor_" --_000_41DEA4B02DBDEF40A0F3B6D0DDB12379451766F4ORSMSX101amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Rudi, I would like you to examine the "latest" documents (the ones under developm= ent). I have added some new licensing information and would like your feed= back for this upcoming version. There are licensing discussions in both th= e latest versions of the BSP Guide and the reference manual. Since, at the= moment, the BSP Guide is included as a chapter in the reference manual, I'= ll point you to the latest version of the reference manual: http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.htm= l. Thanks, Scott From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org= ] On Behalf Of Rudolf Streif Sent: Monday, March 26, 2012 2:52 PM To: yocto@yoctoproject.org Subject: Re: [yocto] can all of the licensing discussion be centralized in = an appendix? >> there's *way* too much coverage of licensing sprinkled throughout. >> most people are not going to care about licensing until the time comes >> to maybe start distributing their BSP. The ability of collecting licensing information, tracking license changes a= nd providing the license information automatically with the images and pack= ages for deployment is in my opinion a major feature of Yocto albeit undere= stimated. Most people will only appreciate it once they have to deliver tha= t information with a product for the end user. However, it starts much earl= ier, with the recipe. How to include licensing tracking information with your recipe needs to be = part of the section explaining how to write recipes of the reference manual= . In both, the current 1.1 and the upcoming 1.1.1, versions of the manual t= he license tracking section is a little disjoint from the sections explaini= ng how to add packages/recipes in my opinion. The examples include the lice= nse tracking info, of course because otherwise the sanity checker will not = allow building the recipe, but they don't explain that you actually need it= (unless you use LICENSE =3D "CLOSED"). Since the license tracking and deployment feature follows the rule "garbage= in, garbage out" the manual cannot stress enough providing the correct inf= o in particular when writing recipes for upstream projects. Side note: And nice features for a future release are SPDX info (already wo= rked on as far as I know) and providing the license info in ${TMPDIR}/deplo= y/licenses according to the images in ${TMPDIR}/images so that one knows wh= at licenses are in use for what image. That would be very convenient when b= uilding multiple images with different package content. Rudi --_000_41DEA4B02DBDEF40A0F3B6D0DDB12379451766F4ORSMSX101amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Rudi,

 <= /p>

I would like you to exami= ne the “latest” documents (the ones under development).  I= have added some new licensing information and would like your feedback for this upcoming version.  There are licensing discussions in both the l= atest versions of the BSP Guide and the reference manual.  Since, at t= he moment, the BSP Guide is included as a chapter in the reference manual, = I’ll point you to the latest version of the reference manual:

 <= /p>

http://www.= yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html.=

 <= /p>

 <= /p>

Thanks,

Scott

 <= /p>

From: yocto-bo= unces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Rudolf Streif
Sent: Monday, March 26, 2012 2:52 PM
To: yocto@yoctoproject.org
Subject: Re: [yocto] can all of the licensing discussion be centrali= zed in an appendix?

 

>> there's *way= * too much coverage of licensing sprinkled throughout.
>> most people are not going to care about licensing until the time c= omes
>> to maybe start distributing their BSP.

The ability of collecting licensing information, tra= cking license changes and providing the license information automatically w= ith the images and packages for deployment is in my opinion a major feature= of Yocto albeit underestimated. Most people will only appreciate it once they have to deliver that information = with a product for the end user. However, it starts much earlier, with the = recipe.

 

How to include licensing tracking information with y= our recipe needs to be part of the section explaining how to write recipes = of the reference manual. In both, the current 1.1 and the upcoming 1.1.1, v= ersions of the manual the license tracking section is a little disjoint from the sections explaining how to = add packages/recipes in my opinion. The examples include the license tracki= ng info, of course because otherwise the sanity checker will not allow buil= ding the recipe, but they don't explain that you actually need it (unless you use LICENSE =3D "CLOSED= ").

 

Since the license tracking and deployment feature fo= llows the rule "garbage in, garbage out" the manual cannot stress= enough providing the correct info in particular when writing recipes for u= pstream projects.

 

Side note: And nice features for a future release ar= e SPDX info (already worked on as far as I know) and providing the license = info in ${TMPDIR}/deploy/licenses according to the images in ${TMPDIR}/imag= es so that one knows what licenses are in use for what image. That would be very convenient when building mul= tiple images with different package content.

 

Rudi

--_000_41DEA4B02DBDEF40A0F3B6D0DDB12379451766F4ORSMSX101amrcor_--