using third party library

using third party library

[Vijay Khemka]

[-- Attachment #1: Type: text/plain, Size: 495 bytes --]

Hi,
I want to use following library from open source which is under MIT license, please let me know if there is any restriction to use this in our openbmc package.
https://github.com/ArashPartow/exprtk/

Also I need to write simple recipe to include this so please let me know what is the best location to put this recipe as well. As I am thinking of using this for virtual sensors then I can put under Sensors or if there is better place to put this then please advise.

Regards
-Vijay

[-- Attachment #2: Type: text/html, Size: 2353 bytes --]

Re: using third party library

[Nancy Yuen]

[-- Attachment #1: Type: text/plain, Size: 836 bytes --]

Would the recipe belong in OpenEmbedded
<https://layers.openembedded.org/layerindex/branch/master/recipes/>?

On Wed, Jul 29, 2020 at 12:52 PM Vijay Khemka <vijaykhemka@fb.com> wrote:

> Hi,
>
> I want to use following library from open source which is under MIT
> license, please let me know if there is any restriction to use this in our
> openbmc package.
>
> https://github.com/ArashPartow/exprtk/
>
>
>
> Also I need to write simple recipe to include this so please let me know
> what is the best location to put this recipe as well. As I am thinking of
> using this for virtual sensors then I can put under Sensors or if there is
> better place to put this then please advise.
>
>
>
> Regards
>
> -Vijay
>


-- 

Nancy Yuen

•

Google Platforms

•

yuenn@google.com

•

Google LLC

[-- Attachment #2: Type: text/html, Size: 4760 bytes --]

Re: using third party library

[Ed Tanous]

On Wed, Jul 29, 2020 at 12:52 PM Vijay Khemka <vijaykhemka@fb.com> wrote:
>
> Hi,
>
> I want to use following library from open source which is under MIT license, please let me know if there is any restriction to use this in our openbmc package.
>
> https://github.com/ArashPartow/exprtk/
>

Upfront, there are some important questions you should ask to save
yourself time on the backend:
1. What binary size on disk does the package add?  Is this in line
with the value it's adding?
2. Is the library of sufficient quality and modernization to be able
to be used under the openbmc c++ coding guidelines?
3. Does the library have regular releases that we can target?
4. Does the library accept patches?
5. Does the library compile under our current compiler settings?
(ideally without warnings)
6. Is the library secure against security testing tools like fuzzers?
7. What license does the library have?  (I suspect MIT will be fine,
as we pull in other MIT components)

In the specific case of this library, looking at the grammar
definition, and given how many features are allowed in the language, I
worry that we're opening ourselves up to lots of expressions that
really shouldn't be done in a virtual sensor parser.  String
modification, slicing, and comparisons for example, probably don't
make sense in the context of sensors.  If/else blocks, and loops also
worry me in the context of a runtime-read config file.  Looking at the
language spec, it's basically another programming language.  If
there's a mechanism to limit the grammar, I think I'd be a lot more ok
with it, although my previous concerns on your design review still
stand.

>
>
> Also I need to write simple recipe to include this so please let me know what is the best location to put this recipe as well. As I am thinking of using this for virtual sensors then I can put under Sensors or if there is better place to put this then please advise.

I'm guessing openembedded would be the best place for this, as the
component is not specific to openbmc.  I don't think sensors is the
right place to put this (as it's not a sensor).

Re: using third party library

[Vijay Khemka]

[-- Attachment #1: Type: text/plain, Size: 1600 bytes --]

There is no recipe available. It is just a github project and either we can add as a SRC_URI+ into our recipe or write a new recipe to build a package. This is header only library, all sources are in header file itself. So we should be able to just add as SRC_URI. I have no idea about how licensing will work here.

Regards
-Vijay

From: Nancy Yuen <yuenn@google.com>
Date: Wednesday, July 29, 2020 at 1:04 PM
To: Vijay Khemka <vijaykhemka@fb.com>
Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: using third party library

Would the recipe belong in OpenEmbedded<https://urldefense.proofpoint.com/v2/url?u=https-3A__layers.openembedded.org_layerindex_branch_master_recipes_&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=v9MU0Ki9pWnTXCWwjHPVgpnCR80vXkkcrIaqU7USl5g&m=T93ZFsXz-VlaEYPF0IPFthFQNLEdJcHepq3jdE86nZA&s=xIU3AlzaXFYSCWfAHQjPQmpk7ScIw8x0POGcBBe0Xz4&e=>?

On Wed, Jul 29, 2020 at 12:52 PM Vijay Khemka <vijaykhemka@fb.com<mailto:vijaykhemka@fb.com>> wrote:
Hi,
I want to use following library from open source which is under MIT license, please let me know if there is any restriction to use this in our openbmc package.
https://github.com/ArashPartow/exprtk/

Also I need to write simple recipe to include this so please let me know what is the best location to put this recipe as well. As I am thinking of using this for virtual sensors then I can put under Sensors or if there is better place to put this then please advise.

Regards
-Vijay


--

Nancy Yuen

•

Google Platforms

•

yuenn@google.com<mailto:yuenn@google.com>

•

Google LLC


[-- Attachment #2: Type: text/html, Size: 6982 bytes --]

Re: using third party library

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 1222 bytes --]

On Thu, Jul 30, 2020 at 08:32:00PM +0000, Vijay Khemka wrote:
> There is no recipe available. It is just a github project and either we can add as a SRC_URI+ into our recipe or write a new recipe to build a package. This is header only library, all sources are in header file itself. So we should be able to just add as SRC_URI. I have no idea about how licensing will work here.
> 

I don't think you should add an additional SRC_URI onto your package in
order to get this dependency even though it is header-only.  There are
other header-only repositories that have recipes, such as nlohmann-json.

If you were to add this as an SRC_URI it would complicate the LICENSE
setting in your recipe because your code is Apache but you're also
including an MIT component.  It is clearer to simply have another recipe
that is MIT licensed, as appropriate.

The recommendation that "this belongs in openembedded" means we probably
shouldn't be carrying around the recipe for it ourselves since it has
potentially wider applicability than OpenBMC.  We [you] can contribute
the recipe upstream to OE and we'll get it indirectly that way.  We
similarlly did this for 'libmimetic' recently.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: using third party library

[Vijay Khemka]

Thanks Patrick,
I like the idea to have separate recipe in openembedded, let me look for including this recipe in openembedded.

Regards
-Vijay

On 7/31/20, 6:08 AM, "Patrick Williams" <patrick@stwcx.xyz> wrote:

    On Thu, Jul 30, 2020 at 08:32:00PM +0000, Vijay Khemka wrote:
    > There is no recipe available. It is just a github project and either we can add as a SRC_URI+ into our recipe or write a new recipe to build a package. This is header only library, all sources are in header file itself. So we should be able to just add as SRC_URI. I have no idea about how licensing will work here.
    > 

    I don't think you should add an additional SRC_URI onto your package in
    order to get this dependency even though it is header-only.  There are
    other header-only repositories that have recipes, such as nlohmann-json.

    If you were to add this as an SRC_URI it would complicate the LICENSE
    setting in your recipe because your code is Apache but you're also
    including an MIT component.  It is clearer to simply have another recipe
    that is MIT licensed, as appropriate.

    The recommendation that "this belongs in openembedded" means we probably
    shouldn't be carrying around the recipe for it ourselves since it has
    potentially wider applicability than OpenBMC.  We [you] can contribute
    the recipe upstream to OE and we'll get it indirectly that way.  We
    similarlly did this for 'libmimetic' recently.

    -- 
    Patrick Williams