Hi Paul,

I would also argue that SPDX does not help you in this context.

However, there are tools available - most of them also supporting SPDX - that 
enable you to establish a license monitoring for the software assets you 
consume or provide.

Initiatives - such as the PEP driven by Phillipe - drive improvement, based on 
the observed monitoring results.

Regards,
Karsten


On 14.01.23, 09:31, "Paul Sherwood" <[email protected] 
<mailto:[email protected]> on behalf of [email protected] 
<mailto:[email protected]>> wrote:


Hi folks,


five years ago (!) I raised some questions on this list about SPDX in 
the email below. I'd love to link to the thread, but as far as I can 
tell the messages have been lost from the public archive [1].


The answers caused me to lose interest in SPDX, because


- SPDX tooling had in fact led to false claims about the mis-licensing 
of the keyring project [2] (you had one job... :-) )
- most of my questions didn't get any comment or response at all


Now I've been asked/advised to look again at SPDX, to figure out whether 
my original concerns have been addressed. Obviously since 2017 the 
project has grown in stature and importance. I'm please to see that 
Philippe Ombredanne picked up on part of the original keyring discussion 
for python projects [3] and ran with it all the way to a pep [4].


However it's not obvious to me whether the underlying issue still 
remains, so I'd like to explain it as follows:


- in many situations, people create metadata manually, to signify some 
property of a project or document
- even with the best intentions, human-crafted metadata may or may not 
correctly describe the property it claims to represent
- for example people often put "Version X" in the header of a Word 
document - then someone else edits the doc, but fails to update the 
header. We now have two different versions of the document, both 
claiming to be "Version X"
- or someone specifies licence that they believe applies for a project, 
as metadata in a build tool (e.g. yocto bitbake recipe). Then someone 
adds additional content to the project, where a different licence 
applies, but no-one updates the metadata


So the underlying problem I see is that manually created metadata can be 
misleading and lead to false confidence (as demonstrated by the keyring 
example). What mechanisms can be applied to ensure that license 
assertions based on SPDX metadata are actually true?


br
Paul


[1] 
https://lists.spdx.org/g/spdx/search?p=created%2C0%2Cdmg%2C20%2C1%2C0%2C0&q=sherwood
 
<https://lists.spdx.org/g/spdx/search?p=created%2C0%2Cdmg%2C20%2C1%2C0%2C0&amp;q=sherwood>
[2] https://github.com/jaraco/keyring/issues/263 
<https://github.com/jaraco/keyring/issues/263>
[3] https://github.com/pombredanne/spdx-pypi-pep/issues/1 
<https://github.com/pombredanne/spdx-pypi-pep/issues/1>
[4] https://github.com/python/peps/pull/1625 
<https://github.com/python/peps/pull/1625>


On 2017-02-16 18:40, Paul Sherwood wrote:
> Hi all,
> I attended a couple of SPDX-relvant talks at OSLS and am now trying to
> get from 'vaguely aware and positive' to 'practitioner/advocate' in
> the shortest possible time.
> 
> I'll begin by stating I'm supportive of anything that will actually
> improve the reliability, efficiency and effectiveness of complex
> software delivery. In theory SPDX can be that, so here I am.
> 
> Now - I'm a newbie and you can only get first-impressions from those,
> so here are mine:
> 
> - the website is no use to me at all. I need to know how to get
> started in the smallest number of steps
> - don't force me to read all the background, explain licensing etc...
> just tell me what i need to DO
> - you've moved to GitHub but there are still bugzilla links lying
> around. please use GitHub issues and be done
> - maybe worth trying to get a CII badge for SPDX :)
> 
> Moving onto my own experiences with SPDX so far
> - interesting conversation with Gary O'Neall, as a result of which I
> understand some of the context and issues more
> - so far I'm failing to understand what to *do* with it for the
> projects I am involved in
> 
> At Kate's talk [1] (can't find the slides online, btw) she showed a
> Wind River dashboard which mentioned that the WR scanner
> (proprietary?) identified keyring as having no license info.
> 
> While the talk was happening I raised this as an issue upstream [2].
> 
> Basically, he would be an ideal candidate for adopting SPDX - he wants
> to avoid confusion and licensing errors. But he has gone his own way
> (even while acknowledging the 'too many standards' joke) because when
> he checked out the SPDX project it 'seems it's not well defined what
> it means to include SPDX metadata."
> 
> I completely agree with him. On the SPDX homepage, there should be the
> equivalent of hello world instructions, for maintainers to follow, in
> clear english.
> 
> Bonus points if the text answers all of the following questions:
> 
> - can I just create one file, and leave everything else as-is, or do i
> need to edit all my copyrightable files to insert metadata?
> - what precisely do I put in my files? (and bear in mind I have C,
> python, Assembler, Go, Javascript, haskell, generated code, yaml,
> json, bitmaps etc)
> - should i delete existing license texts? what if someone else put them 
> there?
> - do i still need LICENSE, COPYING or similar files?
> - is this a one-shot deal? once i've 'done SPDX' do i ever need to
> think about it again for my project?
> - if I make a mistake (eg spurious license files lying around) what 
> happens?
> 
> Thanks for reading
> 
> br
> Paul
> 
> [1] https://osleadershipsummit2017.sched.com/event/9Ki3?iframe=no 
> <https://osleadershipsummit2017.sched.com/event/9Ki3?iframe=no>
> [2] https://github.com/jaraco/keyring/issues/263 
> <https://github.com/jaraco/keyring/issues/263>
> [3] https://xkcd.com/927/ <https://xkcd.com/927/>















-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#4920): https://lists.spdx.org/g/Spdx-tech/message/4920
Mute This Topic: https://lists.spdx.org/mt/96263894/21656
Group Owner: [email protected]
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-


Reply via email to