Hello Pierre,

Thanks very much for your comments here. I think this is a helpful part of
the conversation.

I think that it would be worthwhile to schedule a meeting of the Legal
Subcommittee to discuss the points raised in your and Sylvain's emails. I
think your comments about drawing the distinction between Dockerfiles vs.
the actual contents of containers are relevant. I would note also however
that some of the licenses from Sylvain's list go beyond the standard and
common "copyleft" licenses like GPL-2.0. In particular I note the Elastic
License and Server Side Public License on Sylvain's list. These licenses in
particular may be worth discussing with the Legal Subcommittee (as well as
the other copyleft licenses you noted).

*Sylvain*, I was hoping to circle back to my prior question, if there is
feedback here that you can provide then it would be helpful to the Legal
Subcommittee: For the components that you listed at
https://wiki.onap.org/display/DW/ONAP+Operations+Manager, how are these
being used? In other words, in what ways are these incorporated into /
installed by ONAP?

Thanks,
Steve

On Tue, Mar 17, 2020 at 7:38 AM Close, Pierre <pierre.cl...@intl.att.com>
wrote:

> Hello Sylvain, hello Steve,
>
>
>
> Thank you for bringing this to the table.  I’ll try to add my point of
> view on this.
>
>
>
> As far as I know, and I’ll take an example here, MariaDB is not being used
> as a base for a derivative work (being in its own container, at a minimum),
> and in that aspect should be seen differently from copyleft source code –
> it serves for deployment, not as a base for a derivative work.
> Additionally, the fact that we are using containers should isolate them
> from each other, preventing the propagation of copyleft (see my Ps below).
> And, to a broader extent, software living inside “empty” containers is
> already likely to be GPL based.  Viewpoint from Richard Fontana (lawyer and
> counsel at Red Hat) is available here for information:
> https://opensource.com/article/18/1/containers-gpl-and-copyleft
>
>
>
> (What we must do for sure is clearly providing links to the source code of
> those components, since GPL based software requires the source code to be
> made available by any means.)
>
>
>
> Now, as for Dockerfiles, as long as they are living inside ONAP source
> code repositories, their licensing could cause issues when seeking to
> create derivative works from ONAP (GPL forces resulting product license to
> be GPL), either as a whole or in part.  In this situation, if we have
> copyleft licensed Dockerfiles, I believe the ONAP IP / Legal subcommittee
> should discuss them.
>
>
>
> In short, I think that containers should be fine – if we are not
> distributing them as the sole base for ONAP – but files inside source code
> repositories could be a concern.
>
>
>
> Please anyone correct me if I’m wrong and/or if I’m misunderstanding the
> issue, and I’ll be happy to discuss with you all on this topic.
>
>
>
> Thanks and best regards,
>
> Pierre
>
>
>
> Ps: A true problem would arise with the AGPL family of licenses, where
> networking triggers copyleft. For ONAP, unless mistaken, there is no such
> licensed software.
>
>
>
> *From:* onap-tsc@lists.onap.org <onap-tsc@lists.onap.org> *On Behalf Of *Steve
> Winslow
> *Sent:* Monday, March 16, 2020 10:27 PM
> *To:* sylvain.desbure...@orange.com
> *Cc:* Kenny Paul <kp...@linuxfoundation.org>; David McBride <
> dmcbr...@linuxfoundation.org>; onap-...@lists.onap.org;
> onap-tsc@lists.onap.org
> *Subject:* Re: [onap-tsc] [onap-ptl] ONAP codebase license scan, Mar. 2020
>
>
>
> Hi Sylvain,
>
>
>
> Thanks for raising this. The license scans that I run are focused on (1)
> the contents of the ONAP repositories themselves, and (2) the dependencies
> to the extent that the scanning tools are able to identify them. That said,
> if there are other known dependencies that you've separately identified, I
> think it's worth raising them for consideration under the project's IP
> policies.
>
>
>
> For the components that you listed at
> https://wiki.onap.org/display/DW/ONAP+Operations+Manager
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_ONAP-2BOperations-2BManager&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=egpHMB_FvD2vtKMl8pnJCgjhcw9Zx_dFxB44vWLk-iE&m=-PGH3zsKHPJmZDodi2iDDb8XSdTG52-qxQMyII7We00&s=x-RaJas12RAE75_SyNuvkyOmQBce921wQPtMQqmpmho&e=>,
> how are these being used? In other words, in what ways are these
> incorporated into / installed by ONAP?
>
>
>
> Of the components you listed, I see several are under Apache-2.0 (which is
> fine as it matches the project's licenses or other permissive licenses like
> MIT / BSD (which have typically been readily approved). Those that are
> copyleft (such as GPL-2.0 / GPL-3.0) or not OSI-approved licenses (such as
> Elastic License or Server-Side Public License) are likely to be greater
> concern, and particularly in the latter case I do not know that the ONAP
> Legal Subcommittee would recommend that the TSC approve license exceptions
> for these.
>
>
>
> Thanks,
>
> Steve
>
>
>
> On Thu, Mar 12, 2020 at 11:02 AM <sylvain.desbure...@orange.com> wrote:
>
> Hello, I’m fearing to open the pandora box but I have a question around
> the way we install ONAP: in
> https://wiki.onap.org/display/DW/ONAP+Operations+Manager
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_ONAP-2BOperations-2BManager&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=egpHMB_FvD2vtKMl8pnJCgjhcw9Zx_dFxB44vWLk-iE&m=-PGH3zsKHPJmZDodi2iDDb8XSdTG52-qxQMyII7We00&s=x-RaJas12RAE75_SyNuvkyOmQBce921wQPtMQqmpmho&e=>,
> I’ve listed all components that we used around ONAP in order to deploy ONAP.
>
>
>
> I’ve also tried to find per components (and I may have missed some):
>
>    - Their license
>    - The license of their deployment files (Dockerfile)
>
>
>
> I see for example that:
>
>    - Mariadb is GPLv2 and the Dockerfile used for creating the container
>    we use is GPLv3
>    - Mongodb is Server Side Public License and the Dockerfile used for
>    creating the container we use is Apache 2.0
>    - …
>
>
>
> So, are we good with that?
>
> Or do we need to have components in onap deployment only with some
> specific licenses (for the component itself and for the packaging)?
>
> If yes, can you provide a whitelist / blacklist?
>
>
>
>
>
> ---
>
> Sylvain Desbureaux
>
>
>
> *From: *<onap-...@lists.onap.org> on behalf of Steve Winslow <
> swins...@linuxfoundation.org>
> *Reply-To: *"onap-...@lists.onap.org" <onap-...@lists.onap.org>, "
> swins...@linuxfoundation.org" <swins...@linuxfoundation.org>
> *Date: *Tuesday, March 10, 2020 at 4:43 PM
> *To: *"onap-...@lists.onap.org" <onap-...@lists.onap.org>
> *Cc: *"LEFEVRE, CATHERINE" <catherine.lefe...@intl.att.com>, "CLOSE,
> PIERRE" <pierre.cl...@intl.att.com>, "MCCRAY, CHRISTOPHER" <cm6...@att.com>,
> "ittay.st...@att.com" <ittay.st...@att.com>, Kenny Paul <
> kp...@linuxfoundation.org>, David McBride <dmcbr...@linuxfoundation.org>
> *Subject: *[onap-ptl] ONAP codebase license scan, Mar. 2020
>
>
>
> Hello ONAP PTLs,
>
>
>
> I am attaching links to the subprojects results of the most recent ONAP
> codebase license scans. These are based on a scan of the repos as of March
> 5.
>
>
>
> The key findings, as well as the overall license summary, can be found at
> the following address:
>
>
>
>
> https://lfscanning.org/reports/onap/onap-2020-03-0c36f9d6-950d-42e1-8f86-7f0b4759019c.html
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lfscanning.org_reports_onap_onap-2D2020-2D03-2D0c36f9d6-2D950d-2D42e1-2D8f86-2D7f0b4759019c.html&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=qLcfee4a2vOwYSub0bljcQ&m=a9qSC-xVaBVH6VAIuo2n3O0Ym0r1y3xKdDzgQptS8Jc&s=AMkuCVbI7Yl9CC7oXyGq1dS7hINBx2Qzxq715swobgM&e=>
>
>
>
> In particular, the following projects should look at the findings noted
> for them:
>
>    - *ccsdk-distribution*
>    - *multicloud-k8s*
>    - *portal*
>
> The full spreadsheet with a list of all licenses and files can be found at:
>
>
>
>
> https://lfscanning.org/reports/onap/onap-2020-03-0c36f9d6-950d-42e1-8f86-7f0b4759019c.xlsx
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lfscanning.org_reports_onap_onap-2D2020-2D03-2D0c36f9d6-2D950d-2D42e1-2D8f86-2D7f0b4759019c.xlsx&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=qLcfee4a2vOwYSub0bljcQ&m=a9qSC-xVaBVH6VAIuo2n3O0Ym0r1y3xKdDzgQptS8Jc&s=JkmIGjvmWwy78T7nAcQB93yYEAXxeyjKpybldCYLsAA&e=>
>
>
>
> Although these links and its contents are not confidential, they may be
> considered sensitive and should not be generally publicized / uploaded to
> public wikis, etc. Please treat in the same manner that past license scan
> report emails have typically been treated.
>
>
>
> Please take a look at the findings and recommendations available at the
> first URL. There are also separate reports for each subproject, and the
> URLs to those reports can be found in the attached text file.
>
>
>
> I have not yet enabled the JIRA integration that we discussed on the PTL
> call last week. I will be looking to do that for the next monthly scan if
> feasible.
>
>
>
> These reports cover license notices contained in the ONAP codebases
> themselves; as always, build-time dependency licenses are available in
> Sonatype Nexus IQ at https://jenkins.onap.org/view/CLM/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__jenkins.onap.org_view_CLM_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=qLcfee4a2vOwYSub0bljcQ&m=a9qSC-xVaBVH6VAIuo2n3O0Ym0r1y3xKdDzgQptS8Jc&s=5Rck08OX8Q8bwjKpPuODTryIkQnL0e2PZztRu3L2VnQ&e=>,
> and I am continuing to review and update the results there. I will send a
> couple of emails with specific comments on these in the coming days.
>
>
>
> Finally, updated SPDX files for the scan results from each subproject's
> repos can be found at https://github.com/lfscanning/spdx-onap
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_lfscanning_spdx-2Donap&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=qLcfee4a2vOwYSub0bljcQ&m=a9qSC-xVaBVH6VAIuo2n3O0Ym0r1y3xKdDzgQptS8Jc&s=JL9u_YDZkDRzLyEQ2SvUeXjq-P1Nk0nFD6cycxUQ-50&e=>
> .
>
>
>
> Please feel free to let me know if you have any questions. Best,
>
> Steve
>
>
> --
>
> Steve Winslow
> Director of Strategic Programs
> The Linux Foundation
>
> swins...@linuxfoundation.org
>
>
>
> --
>
> Steve Winslow
> Director of Strategic Programs
> The Linux Foundation
>
> swins...@linuxfoundation.org
>
>
>
> --
>
> Steve Winslow
> Director of Strategic Programs
> The Linux Foundation
>
> swins...@linuxfoundation.org
>
> _________________________________________________________________________________________________________________________
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
>
> Thank you.
>
>
>
> --
>
> Steve Winslow
> Director of Strategic Programs
> The Linux Foundation
>
> swins...@linuxfoundation.org
>
> 
>


-- 
Steve Winslow
Director of Strategic Programs
The Linux Foundation
swins...@linuxfoundation.org

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#6062): https://lists.onap.org/g/onap-tsc/message/6062
Mute This Topic: https://lists.onap.org/mt/71903959/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to