All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joshua Watt <jpewhacker@gmail.com>
To: Thomas Thorne <Thomas.Thorne@net2edge.com>,
	"Burton, Ross" <ross.burton@intel.com>
Cc: "yocto@yoctoproject.org" <yocto@yoctoproject.org>
Subject: Re: Using A Proprietary Closed License Inside A Layer & Its Recipes
Date: Fri, 16 Jun 2017 08:14:44 -0500	[thread overview]
Message-ID: <1497618884.2549.1.camel@gmail.com> (raw)
In-Reply-To: <DB6PR0701MB1879F68989431486E48F7FF6D3C10@DB6PR0701MB1879.eurprd07.prod.outlook.com>

On Fri, 2017-06-16 at 09:12 +0000, Thomas Thorne wrote:
> >> Is it only possible to use the special
> >> LICENSE = "CLOSED"
> >> license for licenses not already placed in the main license
> directory?
> >
> > Yes, there's special-case logic for 'CLOSED'.  Can you not just use
> that for your internal pieces?  It's special-cased in a few places.
>  
> I can use CLOSED.  I just wanted to ensure I was following the
> recommended or best practice. 
>  
> As this is an internal thing it should be OK for now.  I was
> wondering what would happen if a closed licenses was updated, as
> nothing would currently note the md5 change. 

FWIW: We created a proprietary license file called files/common-
licenses/company.txt in our proprietary layer, then added the following
to layer.conf:

 COMPANY_COMMON_LICENSES := '${@os.path.normpath("${LAYERDIR}/files/com
mon-licenses")}'
 BB_HASHBASE_WHITELIST_append = " COMPANY_COMMON_LICENSES"

Then a recipe can get the "standard" proprietary license by doing:

 LIC_FILES_CHKSUM =
"file://${COMPANY_COMMON_LICENSES}/company.txt;md5=9b1139fa1fcb869069db
eecca44350a5"

It works pretty well and also make it clear what license the recipe is
under. I believe that the BB_HASHBASE_WHITELIST was necessary at the
time to prevent changes in the project working path from causing a full
rebuild of the all proprietary packages and so that the sstate
signatures would match regardless, but I might be wrong about it being
necessary.

>  
>  
> The mega manual mentions CLOSED in 7 places.  One of those places
> also lists "Proprietary" as a value so I could used either in some
> cases.  Based on my reading of the manual "Proprietary" would not be
> exempt from setting up the LIC_FILES_CHKSUM, but CLOSED would be. 



  reply	other threads:[~2017-06-16 13:14 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-15 14:52 Using A Proprietary Closed License Inside A Layer & Its Recipes Thomas A. F. Thorne MEng AUS MIET
2017-06-15 19:33 ` Burton, Ross
2017-06-16  9:12   ` Thomas Thorne
2017-06-16 13:14     ` Joshua Watt [this message]
2017-06-16 18:00       ` Khem Raj
2017-06-16 18:11         ` Joshua Watt
2017-06-19 16:33           ` Thomas Thorne
  -- strict thread matches above, loose matches on Subject: below --
2017-06-16  8:59 gmane

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1497618884.2549.1.camel@gmail.com \
    --to=jpewhacker@gmail.com \
    --cc=Thomas.Thorne@net2edge.com \
    --cc=ross.burton@intel.com \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.