From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by mail.openembedded.org (Postfix) with ESMTP id 1159F607A4 for ; Fri, 29 Jul 2016 10:58:07 +0000 (UTC) Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id u6TAvvgw017864 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 29 Jul 2016 12:57:58 +0200 Received: from DEFTHW99ERNMSX.ww902.siemens.net (defthw99ernmsx.ww902.siemens.net [139.22.70.141]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTPS id u6TAvvFw025950 (version=TLSv1 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 Jul 2016 12:57:57 +0200 Received: from DEFTHW99ERSMSX.ww902.siemens.net (139.22.70.207) by DEFTHW99ERNMSX.ww902.siemens.net (139.22.70.141) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 29 Jul 2016 12:57:56 +0200 Received: from DENBGAT9EH2MSX.ww902.siemens.net ([169.254.6.75]) by DEFTHW99ERSMSX.ww902.siemens.net ([139.22.70.207]) with mapi id 14.03.0301.000; Fri, 29 Jul 2016 12:57:56 +0200 From: "Meier, Roger" To: Mark Hatle Thread-Topic: [OE-core] [PATCH v3 0/4] license: Sync with SPDX 2.0, pull request Thread-Index: AQHR50fGCeIfK7iAREGNStSKUS7RsaAqsbsAgASDxFqAAAwQPw== Date: Fri, 29 Jul 2016 10:57:55 +0000 Message-ID: References: <1469539192-18406-1-git-send-email-sergeimir@emcraft.com> <1469542336.23580.101.camel@linuxfoundation.org>, <55cb9817-d62f-88bf-e886-b1f18549fbff@windriver.com>, <892B027B-E61A-49EE-9B15-F84516241426@siemens.com> In-Reply-To: <892B027B-E61A-49EE-9B15-F84516241426@siemens.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 Cc: Alexander Dyachenko , Sergei Miroshnichenko , "openembedded-core@lists.openembedded.org" Subject: Re: [PATCH v3 0/4] license: Sync with SPDX 2.0, pull request X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 10:58:08 -0000 Content-Language: de-CH Content-Type: multipart/alternative; boundary="_000_FB46AF37B9054CC69594B768A258470Dsiemenscom_" --_000_FB46AF37B9054CC69594B768A258470Dsiemenscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Now including the list as I'm subscriber now... Am 29.07.2016 um 11:14 schrieb Meier, Roger (BT CPS R&D ZG FW CCP) >: Hi Mark Am 26.07.2016 um 16:18 schrieb Mark Hatle >: On 7/26/16 9:12 AM, Richard Purdie wrote: On Tue, 2016-07-26 at 16:19 +0300, Sergei Miroshnichenko wrote: Here are the request for a community review for a synchronization with the SPDX License List (git.spdx.org/license-list.git) and adding license operators to meet SPDX 2.0 specification compliance (https://spdx.org/sites/spdx/files/SPDX-2.0.pdf Appendix IV: SPDX License Expression). The whole patch series is way too big to send them to the mailing list (the biggest one is ~3MiB), so please find the diffs via gitweb of the -contrib repo. Whilst we certainly want to collaborate with SPDX, we've never said our LICENSE field should match what SPDX is doing. Your patch appears to unequivocally join them as a 1:1 mapping and I'm not sure this is something we've ever planned or agreed to. These fields do get written into the packages and used in a variety of places. Certainly if we are going to map them 1:1, this is something which would need discussion on the OE architecture list first. I'd be nervous about committing to do that, not knowing or having any influence over what SPDX may do next. SPDX is part of linux foundation and they listen to the open source communi= ties, Jilayne Lovejoy is maintaining the license list and she is very open minded= if we have further questions or have better ideas on the direction of the = spdx license list itself, e.g. for simpler integration into other systems s= uch as OE. Is the intent here to map us 1:1 with SPDX and are you advocating that? I agree. This needs to be set as part of the OE Architecture first. I don= 't object to the format or contents of the change -- just that it's a pretty b= ig change for how things work. I was not aware of a seperate architecture list, sorry. The goal here is to reduce efforts on license compliance by using the well = known SPDX license list. There are two approaches * having a SPDX license list beside of the OE license list * reuse the SPDX license list as suggested via this patch series Also looking over the patches, the changes to the license text (common-lice= nses) need some more explanation. The comment says it syncs to the spdx license = list. But mostly what I see are simply format changes that actually make it harde= r for developers to read the license text. Is there any reference/explanation as to why the formatting changes are required/suggested/etc? The licenses are directly from the spdx license list and having them in syn= c with the spdx license list makes it much easier to maintain in the future= . Just synch with latest license list as soon as a new version is published= . Some licenses do already have some place holders for copyright holders, whi= ch is part of the license matching rules, that's why you see some special f= ields, see http://spdx.org/spdx-license-list/matching-guidelines Best! Roger --Mark Cheers, Richard --_000_FB46AF37B9054CC69594B768A258470Dsiemenscom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Now including the list as I'm subscriber now...

Am 29.07.2016 um 11:14 schrieb Meier, Roger (BT CPS R&D ZG FW CCP) <= r.meier@siemens.com>:

Hi Mark

Am 26.07.2016 um 16:18 schrieb Mark Hatle <mark.hatle@windriver.com>:

On 7/26/16 9:12 AM, Richard Purdie wrote:
On Tue, 2016-07-26 at 16:19 +0300, Serg= ei Miroshnichenko wrote:
Here are the request for a community review= for a synchronization
with the SPDX License List (git.spdx.org/license-list.git) and ad= ding
license operators to meet SPDX 2.0 specific= ation compliance
(https://spdx.org/sites/spdx/files/SPDX-2.0.pdf Appendi= x IV: SPDX
License Expression).

The whole patch series is way too big to se= nd them to the mailing
list (the biggest one is ~3MiB), so please = find the diffs via gitweb
of the -contrib repo.

Whilst we certainly want to collaborate wit= h SPDX, we've never said our
LICENSE field should match what SPDX is doi= ng. Your patch appears to
unequivocally join them as a 1:1 mapping an= d I'm not sure this is
something we've ever planned or agreed to. = These fields do get written
into the packages and used in a variety of = places.

Certainly if we are going to map them 1:1, = this is something which
would need discussion on the OE architectur= e list first. I'd be nervous
about committing to do that, not knowing or= having any influence over
what SPDX may do next.

SPDX is part of linux foundation and they listen to the open source communi= ties,
Jilayne Love= joy is maintaining the license list and she is very open minded if we have = further questions or have better ideas on the direction of the spdx license= list itself, e.g. for simpler integration into other systems such as OE.

Is the intent here to map us 1:1 with SPDX = and are you advocating that?

I agree.  This needs to be set as part of the OE Architecture fi= rst.  I don't
object to the format or contents of the change -- just that it's a pr= etty big
change for how things work.
I was not aware of a seperate architecture list, sorry.
The goal here is to reduce efforts on license compliance by using the = well known SPDX license list.

There are two approaches
* having a SPDX license list beside of the OE license list
* reuse the SPDX license list as suggested via this patch series


Also looking over the patches, the changes to the license text (commo= n-licenses)
need some more explanation.  The comment says it syncs to the sp= dx license list.
But mostly what I see are simply format changes that actually make it= harder
for developers to read the license text.
Is there any reference/explanation as to why the formatting chan= ges are
required/suggested/etc?

The licenses are = directly from the spdx license list and having them in sync with the spdx l= icense list makes it much easier to maintain in the future. Just synch with= latest license list as soon as a new version is published.
Some license= s do already have some place holders for copyright holders, which is part o= f the license matching rules, that's why you see some special fields, see&n= bsp;http://spdx.org/spdx-license-list/matching-guidelines

Best!=
Roger=


--Mark

Cheers,

Richard


--_000_FB46AF37B9054CC69594B768A258470Dsiemenscom_--