[Openembedded-architecture] license: Sync with SPDX2.0 proposal
Sergei Miroshnichenko
sergeimir at emcraft.com
Fri Sep 9 13:14:41 UTC 2016
Gentlemen,
Are there any issues left which I need to fix and/or tests to run before
this proposal could be considered for merging?
What I can see right now is lot of links in the following forms:
1) LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/xxx;md5=yyy"
2) LIC_FILES_CHKSUM =
"file://${COREBASE}/meta/files/common-licenses/xxx;md5=yyy"
, so any change in the license files require updating all the affected
recipes at all the layers.
While the community has full control over the license files, are there
any reason to validate their checksums? Will it be harmful to remove
this validation for local files?
Best regards,
Sergei Miroshnichenko
On 08/13/2016 06:00 AM, Khem Raj wrote:
> On 16-08-11 10:09:20, Mark Hatle wrote:
>> On 8/11/16 8:28 AM, Sergei Miroshnichenko wrote:
>>> (continuing discussion started at [1-2] here, at the architecture list
>>> where it belongs)
>>>
>>> Hi all,
>>>
>>> Here [3] is the proposal to merge actual updates from SPDX into
>>> Openembedded-core, resolving inconsistency with the current standard:
>>> - Arrange license file list: remove deprecated ones, add files for
>>> exceptions;
>>> - Fix formatting (non-ASCII symbols, trailing whitespaces, etc.);
>>> - Add support for SPDX 2.0 operators.
>>>
>>> [1]
>>> http://lists.openembedded.org/pipermail/openembedded-core/2016-July/124290.html
>>> [2]
>>> http://lists.openembedded.org/pipermail/openembedded-core/2016-July/124497.html
>>> [3]
>>> http://git.openembedded.org/openembedded-core-contrib/log/?h=sergeimir/spdx2_sync
>>
>> As an FYI -- I'm in favor of making the switch to the SPDX 2 operators, as long
>> as the blacklist and other code is shown to work.
>
> I think it will be a good improvement for next release too.
>
>>
>> I know there are some concerns about where we are in the current release
>> schedule, but assuming it is NOT too disruptive (amount of class code modified
>> vs LICENSE fields modified), I could accept the risk.
>>
>> The formatting, I've got no real opinion either way.
>>
>> Updating the license file list would also be a good thing in my opinion.
>>
>> --Mark
>>
>>> Best regards,
>>> Sergei Miroshnichenko
>>> _______________________________________________
>>> Openembedded-architecture mailing list
>>> Openembedded-architecture at lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>>>
>>
>> _______________________________________________
>> Openembedded-architecture mailing list
>> Openembedded-architecture at lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
More information about the Openembedded-architecture
mailing list