Re: [spdx-tech] SPDX - true or false? (was Re: Getting started...)

[Gary O'Neall]

Hi Paul,

In response to your proposal:

> Well, at the point that someone (or some script) asserts license metadata,
I think it may be worth capturing additional metadata, such as
>
> - the date that the assertion is made

For the SBOM case, this is the creation date in the creation information.

For original license declarations in the source code, most (but not all)
source code uses some form of source control system that captures the date
as part of the checkin.

We are also capturing other date/time information as part of the build
profile (e.g. built date for the package) that can be useful.

If there is any additional date/time information we should capture - please
let us know.

> - who (or which program) is making the assertion, preferably with some
indication of their competence/qualifications

For the SBOM, this is the creator field - it can be a person, organization
or tool.  We don't (and in my opinion shouldn't) capture qualification,
competencies in the SBOM itself as these things can change over time and
they are likely in the area of opinions and the SPDX spec tries to stick to
facts.  That being said, most organizations maintain a list of organizations
and individuals they trust for analysis.

For the original code checkin, the source control systems typically capture
the information.

> - the basis for the assertion (e.g. manual inspection, automated checking,
author of the code etc)

Checkout the build profile group - they are working on solving similar use
cases for the SPDX 3.0 release.  Use cases can be found here:
https://github.com/spdx/spdx-3-build-profile/blob/main/usecases.md and
minutes here: https://github.com/spdx/meetings/tree/main/build

I expect the activity in the build group to pick up now that we have the
core model nearly completed.

Gary



> -Original Message-
> From: Spdx-tech@lists.spdx.org  On Behalf Of
Paul
> Sherwood
> Sent: Sunday, January 22, 2023 4:12 AM
> To: David Kemp 
> Cc: spdx-tech@lists.spdx.org
> Subject: Re: [spdx-tech] SPDX - true or false? (was Re: Getting
started...)
> 
> Dave,
> 
> sorry for my late reply - comments inline below...
> 
> On 2023-01-15 16:49, David Kemp wrote:
> > Assigning a License ID to some amorphous "thing" called a package --
> > that can be composed of a web of components created at different times
> > by different authors, and processed by multiple builders at multiple
> > points in a build hierarchy -- is tricky.  The lower down in that
> > hierarchy the easier it is to track - if at the bottom a developer of
> > a leaf (dependency-less) component includes the text of the MIT
> > license in his component, his intent is pretty clear.  At that point
> > an SBOM creator binding a license ID to a package ID can be 1)
> > correct, 2) mistaken, or 3) malicious.  As packages are combined up
> > the dependency tree things only get more complicated, but the
> > correctness possibilities are the same.
> 
> I agree, the potential cases we have are correct, mistaken, maliciously
wrong.
> Without an SBOM there's the additional case of undefined.
> 
> > As Polyphemus learned, you don't accomplish anything if you can't
> > assign names to things.  Not producing SBOMs guarantees that you will
> > fail.
> 
> Hmmm - I think that's a bit strong. Lots of software has been successful
over
> decades without SBOMs :-)
> 
> > Arguing that naming perfection is impossible therefore we should do
> > nothing is not persuasive.
> 
> I'm not arguing for doing nothing. I've identified an issue and am trying
to
> figure out
> 
> a) whether others agree that there's a problem
> b) what is already being done about it
> c) what else could be done
> 
> > As technology gets adopted ISO 9000
> > quality assurance processes and certifications may follow, and pushing
> > to develop QA standards is great.. Until then, caveat emptor.
> > Consumers will have to make judgement calls about provider reliability
> > like they do everywhere else in life.
> 
> True
> 
> >> 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?
> >
> > What is your proposal?  Forbid manually-created metadata? Forbid use
> > of SBOMs entirely? I don't believe that's the straightest path to QA.
> 
> Well, at the point that someone (or some script) asserts licence metadata,
I
> think it may be worth capturing additional metadata, such as
> 
> - the date that the assertion is made
> - who (or which program) is making the assertion, preferab

Re: [spdx-tech] SPDX - true or false? (was Re: Getting started...)

[Paul Sherwood]

Dave,

sorry for my late reply - comments inline below...

On 2023-01-15 16:49, David Kemp wrote:

Assigning a License ID to some amorphous "thing" called a package --
that can be composed of a web of components created at different times
by different authors, and processed by multiple builders at multiple
points in a build hierarchy -- is tricky.  The lower down in that
hierarchy the easier it is to track - if at the bottom a developer of
a leaf (dependency-less) component includes the text of the MIT
license in his component, his intent is pretty clear.  At that point
an SBOM creator binding a license ID to a package ID can be 1)
correct, 2) mistaken, or 3) malicious.  As packages are combined up
the dependency tree things only get more complicated, but the
correctness possibilities are the same.


I agree, the potential cases we have are correct, mistaken, maliciously 
wrong. Without an SBOM there's the additional case of undefined.



As Polyphemus learned, you don't accomplish anything if you can't
assign names to things.  Not producing SBOMs guarantees that you will
fail.


Hmmm - I think that's a bit strong. Lots of software has been successful 
over decades without SBOMs :-)



Arguing that naming perfection is impossible therefore we should do
nothing is not persuasive.


I'm not arguing for doing nothing. I've identified an issue and am 
trying to figure out


a) whether others agree that there's a problem
b) what is already being done about it
c) what else could be done


As technology gets adopted ISO 9000
quality assurance processes and certifications may follow, and pushing
to develop QA standards is great.. Until then, caveat emptor.
Consumers will have to make judgement calls about provider reliability
like they do everywhere else in life.


True


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?


What is your proposal?  Forbid manually-created metadata? Forbid use
of SBOMs entirely? I don't believe that's the straightest path to QA.


Well, at the point that someone (or some script) asserts licence 
metadata, I think it may be worth capturing additional metadata, such as


- the date that the assertion is made
- who (or which program) is making the assertion, preferably with some 
indication of their competence/qualifications
- the basis for the assertion (e.g. manual inspection, automated 
checking, author of the code etc)


br
Paul



Just an opinion,
Dave

On Sun, Jan 15, 2023 at 9:10 AM Dick Brooks
 wrote:


Thanks for your feedback, Paul.

Regarding:
" With regard to licencing, the base premise that a human asserts
licence in
metadata, without qualification, seems risky to me. Is there any
traceability for who makes the assertion in the first place, and on
what
basis? And when the software changes, is there any way to force
reassessment
(or at least reassertion) by someone competent?"

Each supplier decides for themselves the terms and conditions upon
which a
party may use their software, which is expressed in a license. There
is no
right or wrong or anyone to verify that the party issuing the
license is
valid. A user of the software decides to accept the terms and
conditions in
the license, or not. No validation required, the license contains
the terms
and conditions as determined by the party issuing the license.

Thanks,

Dick Brooks

Active Member of the CISA Critical Manufacturing Sector,
Sector Coordinating Council - A Public-Private Partnership

Never trust software, always verify and report! T
http://www.reliableenergyanalytics.com
Email: d...@reliableenergyanalytics.com
Tel: +1 978-696-1788

-Original Message-
From: Paul Sherwood 
Sent: Sunday, January 15, 2023 3:47 AM
To: d...@reliableenergyanalytics.com
Cc: spdx-tech@lists.spdx.org
Subject: Re: [spdx-tech] SPDX - true or false? (was Re: Getting
started...)

Hi Dick

thank you for your comments. Please see my thoughts inline

On 2023-01-14 13:12, Dick Brooks wrote:

There is no escaping manual input from the process that leads to

an

SBOM, SPDX or CycloneDX. Someone has to input the data somewhere

in

order for it to be available at SBOM creation time.


True, but my interest relates to

- repeatable construction of evolving software at scale (where
automation
provides significant benefits)
- safety-critical and security-critical systems

Broadly this leads me towards solutions where, once the manual input
has
occurred, we can aim to enforce rules and/or automation to mitigate
against
errors being introduced.


If you are concerned that manual entry occurs somewhere  in the
process that ultimately results in an SBOM then I don't think this



concern will ever go away.

Manual effort is an inherent part of software creation, and yes,

human

error can, and does occasionally occur.

Re: [spdx-tech] SPDX - true or false? (was Re: Getting started...)

[Gary O'Neall]

Just a few more points to add into this discussion:

- In SPDX, there are 2 properties related to licenses - declared and
concluded.  We created 2 properties rather than one to help with some the
issues listed below.  Declared relates to the metadata found in the package
and concluded is a conclusion reached by the SPDX document creator.  So, if
you trust the judgement of the SPDX document creator, you may be able to
trust the concluded license field.  In my day job, I audit software for
license compliance and produce SPDX documents with concluded licenses - some
of which take quite some time to manually confirm especially if the open
source software package is very old and pre-dates good license compliance
practices.
- In SPDX 2.1 an SPDX Lite[1] Annex was added.  One of the reasons for
adding this Annex was to make it easier for the originator of a package to
add metadata in a machine readable form which would enable downstream
packages to have accurate information from the package originators.
- Over the past 3-4 years, there has been very good adoption of SPDX license
identifiers, SPDX license expressions and clearer license related properties
in package managers.  For example, NPM now includes much more machine
readable license information.

I'm not arguing we are anywhere near our goal of having consistently
reliable machine and human readable license information, but we're making
some good progress.

If you have any specific improvements we can make to the specification
itself, please feel free to open an issue in the SPDX spec repo [2].

Gary


[1] https://spdx.github.io/spdx-spec/v2.3/SPDX-Lite/
[2] https://github.com/spdx/spdx-spec/issues


> -Original Message-
> From: Spdx-tech@lists.spdx.org  On Behalf Of
> Alberto Pianon
> Sent: Sunday, January 15, 2023 10:20 AM
> To: Paul Sherwood 
> Cc: Karsten Klein ; Spdx Tech  t...@lists.spdx.org>
> Subject: Re: [spdx-tech] SPDX - true or false? (was Re: Getting
started...)
> 
> Il 2023-01-15 09:56 Paul Sherwood ha scritto:
> > Hi Karsten,
> >
> > thank you. Please see my comments inline
> >
> > On 2023-01-14 14:10, Karsten Klein wrote:
> >> I would also argue that SPDX does not help you in this context.
> >
> > Well, in principle, I believe that getting people to think about
> > licencing in general is better than not, so SPDX contributes at least
> > in that way. And if we can establish confidence that the metadata is
> > correct, and in line with our expected usage of software, we can
> > obtain some mitigation against licence compliance risk.
> >
> > My concern is specifically the false confidence situation, i.e. where
> > the presence of SPDX metadata may cause people to assume incorrectly
> > that licencing has been properly dealt with
> >
> 
> "properly dealt with" may require a definition too :). There are different
> approaches in dealing with licenses in complex third-party software
> components, that depend both on the tools that are used and on the review
> policy of the IP audit team - policy which in turn may depend on
case-specific
> and context-dependent risk assessments. Such information can hardly, if
not
> at all, be expressed in a machine-readable way.
> 
> A project that may address your concerns is openchainproject.org, aimed at
> building trust in the open source supply chain, with a particular focus on
> license compliance. It is a Linux Foundation project, too, and its
specifications
> recently became an ISO standard.
> 
> Regards,
> 
> Alberto
> array.eu
> 
> 
> 




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#4927): https://lists.spdx.org/g/Spdx-tech/message/4927
Mute This Topic: https://lists.spdx.org/mt/96263894/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] SPDX - true or false? (was Re: Getting started...)

[Alberto Pianon]

Il 2023-01-15 09:56 Paul Sherwood ha scritto:

Hi Karsten,

thank you. Please see my comments inline

On 2023-01-14 14:10, Karsten Klein wrote:

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


Well, in principle, I believe that getting people to think about 
licencing in general is better than not, so SPDX contributes at least 
in that way. And if we can establish confidence that the metadata is 
correct, and in line with our expected usage of software, we can obtain 
some mitigation against licence compliance risk.


My concern is specifically the false confidence situation, i.e. where 
the presence of SPDX metadata may cause people to assume incorrectly 
that licencing has been properly dealt with




"properly dealt with" may require a definition too :). There are 
different approaches in dealing with licenses in complex third-party 
software components, that depend both on the tools that are used and on 
the review policy of the IP audit team - policy which in turn may depend 
on case-specific and context-dependent risk assessments. Such 
information can hardly, if not at all, be expressed in a 
machine-readable way.


A project that may address your concerns is openchainproject.org, aimed 
at building trust in the open source supply chain, with a particular 
focus on license compliance. It is a Linux Foundation project, too, and 
its specifications recently became an ISO standard.


Regards,

Alberto
array.eu


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#4925): https://lists.spdx.org/g/Spdx-tech/message/4925
Mute This Topic: https://lists.spdx.org/mt/96263894/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] SPDX - true or false? (was Re: Getting started...)

[David Kemp]

Assigning a License ID to some amorphous "thing" called a package -- that
can be composed of a web of components created at different times by
different authors, and processed by multiple builders at multiple points in
a build hierarchy -- is tricky.  The lower down in that hierarchy the
easier it is to track - if at the bottom a developer of a leaf
(dependency-less) component includes the text of the MIT license in his
component, his intent is pretty clear.  At that point an SBOM creator
binding a license ID to a package ID can be 1) correct, 2) mistaken, or 3)
malicious.  As packages are combined up the dependency tree things only get
more complicated, but the correctness possibilities are the same.

As Polyphemus learned, you don't accomplish anything if you can't assign
names to things.  Not producing SBOMs guarantees that you will fail.

Arguing that naming perfection is impossible therefore we should do nothing
is not persuasive.  As technology gets adopted ISO 9000 quality assurance
processes and certifications may follow, and pushing to develop QA
standards is great.. Until then, caveat emptor.  Consumers will have to
make judgement calls about provider reliability like they do everywhere
else in life.

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?


What is your proposal?  Forbid manually-created metadata? Forbid use of
SBOMs entirely? I don't believe that's the straightest path to QA.

Just an opinion,
Dave


On Sun, Jan 15, 2023 at 9:10 AM Dick Brooks <
d...@reliableenergyanalytics.com> wrote:

> Thanks for your feedback, Paul.
>
> Regarding:
> " With regard to licencing, the base premise that a human asserts licence
> in
> metadata, without qualification, seems risky to me. Is there any
> traceability for who makes the assertion in the first place, and on what
> basis? And when the software changes, is there any way to force
> reassessment
> (or at least reassertion) by someone competent?"
>
> Each supplier decides for themselves the terms and conditions upon which a
> party may use their software, which is expressed in a license. There is no
> right or wrong or anyone to verify that the party issuing the license is
> valid. A user of the software decides to accept the terms and conditions in
> the license, or not. No validation required, the license contains the terms
> and conditions as determined by the party issuing the license.
>
> Thanks,
>
> Dick Brooks
>
> Active Member of the CISA Critical Manufacturing Sector,
> Sector Coordinating Council - A Public-Private Partnership
>
> Never trust software, always verify and report! T
> http://www.reliableenergyanalytics.com
> Email: d...@reliableenergyanalytics.com
> Tel: +1 978-696-1788
>
> -Original Message-
> From: Paul Sherwood 
> Sent: Sunday, January 15, 2023 3:47 AM
> To: d...@reliableenergyanalytics.com
> Cc: spdx-tech@lists.spdx.org
> Subject: Re: [spdx-tech] SPDX - true or false? (was Re: Getting started...)
>
> Hi Dick
>
> thank you for your comments. Please see my thoughts inline
>
> On 2023-01-14 13:12, Dick Brooks wrote:
> > There is no escaping manual input from the process that leads to an
> > SBOM, SPDX or CycloneDX. Someone has to input the data somewhere in
> > order for it to be available at SBOM creation time.
>
> True, but my interest relates to
>
> - repeatable construction of evolving software at scale (where automation
> provides significant benefits)
> - safety-critical and security-critical systems
>
> Broadly this leads me towards solutions where, once the manual input has
> occurred, we can aim to enforce rules and/or automation to mitigate against
> errors being introduced.
>
> > If you are concerned that manual entry occurs somewhere  in the
> > process that ultimately results in an SBOM then I don't think this
> > concern will ever go away.
> >
> > Manual effort is an inherent part of software creation, and yes, human
> > error can, and does occasionally occur.
>
> You're correct - I expect to remain concerned about human errors, at least
> until the AI community comes up with tools to generate the software without
> human intervention, at which point we'll have no clue about whether the
> metadata is truthful or not :-)
>
> However, for the versioning example I mentioned, we have techniques that
> mitigate very effectively against the problem. A common approach is for
> software versioning to be heavily controlled or even generated by tooling.
> For example, if we use git, we can ensure that only one version of s

Re: [spdx-tech] SPDX - true or false? (was Re: Getting started...)

[Dick Brooks]

Thanks for your feedback, Paul. 

Regarding:
" With regard to licencing, the base premise that a human asserts licence in
metadata, without qualification, seems risky to me. Is there any
traceability for who makes the assertion in the first place, and on what
basis? And when the software changes, is there any way to force reassessment
(or at least reassertion) by someone competent?"

Each supplier decides for themselves the terms and conditions upon which a
party may use their software, which is expressed in a license. There is no
right or wrong or anyone to verify that the party issuing the license is
valid. A user of the software decides to accept the terms and conditions in
the license, or not. No validation required, the license contains the terms
and conditions as determined by the party issuing the license. 

Thanks,

Dick Brooks
  
Active Member of the CISA Critical Manufacturing Sector, 
Sector Coordinating Council - A Public-Private Partnership

Never trust software, always verify and report! T
http://www.reliableenergyanalytics.com
Email: d...@reliableenergyanalytics.com
Tel: +1 978-696-1788

-Original Message-
From: Paul Sherwood  
Sent: Sunday, January 15, 2023 3:47 AM
To: d...@reliableenergyanalytics.com
Cc: spdx-tech@lists.spdx.org
Subject: Re: [spdx-tech] SPDX - true or false? (was Re: Getting started...)

Hi Dick

thank you for your comments. Please see my thoughts inline

On 2023-01-14 13:12, Dick Brooks wrote:
> There is no escaping manual input from the process that leads to an 
> SBOM, SPDX or CycloneDX. Someone has to input the data somewhere in 
> order for it to be available at SBOM creation time.

True, but my interest relates to

- repeatable construction of evolving software at scale (where automation
provides significant benefits)
- safety-critical and security-critical systems

Broadly this leads me towards solutions where, once the manual input has
occurred, we can aim to enforce rules and/or automation to mitigate against
errors being introduced.

> If you are concerned that manual entry occurs somewhere  in the 
> process that ultimately results in an SBOM then I don't think this 
> concern will ever go away.
> 
> Manual effort is an inherent part of software creation, and yes, human 
> error can, and does occasionally occur.

You're correct - I expect to remain concerned about human errors, at least
until the AI community comes up with tools to generate the software without
human intervention, at which point we'll have no clue about whether the
metadata is truthful or not :-)

However, for the versioning example I mentioned, we have techniques that
mitigate very effectively against the problem. A common approach is for
software versioning to be heavily controlled or even generated by tooling.
For example, if we use git, we can ensure that only one version of software
has a given tag.

With regard to licencing, the base premise that a human asserts licence in
metadata, without qualification, seems risky to me. Is there any
traceability for who makes the assertion in the first place, and on what
basis? And when the software changes, is there any way to force reassessment
(or at least reassertion) by someone competent?

br
Paul




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#4923): https://lists.spdx.org/g/Spdx-tech/message/4923
Mute This Topic: https://lists.spdx.org/mt/96263894/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] SPDX - true or false? (was Re: Getting started...)

[Paul Sherwood]

Hi Karsten,

thank you. Please see my comments inline

On 2023-01-14 14:10, Karsten Klein wrote:

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


Well, in principle, I believe that getting people to think about 
licencing in general is better than not, so SPDX contributes at least in 
that way. And if we can establish confidence that the metadata is 
correct, and in line with our expected usage of software, we can obtain 
some mitigation against licence compliance risk.


My concern is specifically the false confidence situation, i.e. where 
the presence of SPDX metadata may cause people to assume incorrectly 
that licencing has been properly dealt with



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.


I'll look into that more deeply - any pointers or recommendations would 
be appreciated.



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


Agreed... and that was triggered by the original discussion within the 
SPDX community :-)


br
Paul


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#4922): https://lists.spdx.org/g/Spdx-tech/message/4922
Mute This Topic: https://lists.spdx.org/mt/96263894/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] SPDX - true or false? (was Re: Getting started...)

[Paul Sherwood]

Hi Dick

thank you for your comments. Please see my thoughts inline

On 2023-01-14 13:12, Dick Brooks wrote:
There is no escaping manual input from the process that leads to an 
SBOM,
SPDX or CycloneDX. Someone has to input the data somewhere in order for 
it

to be available at SBOM creation time.


True, but my interest relates to

- repeatable construction of evolving software at scale (where 
automation provides significant benefits)

- safety-critical and security-critical systems

Broadly this leads me towards solutions where, once the manual input has 
occurred, we can aim to enforce rules and/or automation to mitigate 
against errors being introduced.



If you are concerned that manual entry occurs somewhere  in the process
that ultimately results in an SBOM then I don't think this concern will 
ever

go away.

Manual effort is an inherent part of software creation, and yes, human 
error

can, and does occasionally occur.


You're correct - I expect to remain concerned about human errors, at 
least until the AI community comes up with tools to generate the 
software without human intervention, at which point we'll have no clue 
about whether the metadata is truthful or not :-)


However, for the versioning example I mentioned, we have techniques that 
mitigate very effectively against the problem. A common approach is for 
software versioning to be heavily controlled or even generated by 
tooling. For example, if we use git, we can ensure that only one version 
of software has a given tag.


With regard to licencing, the base premise that a human asserts licence 
in metadata, without qualification, seems risky to me. Is there any 
traceability for who makes the assertion in the first place, and on what 
basis? And when the software changes, is there any way to force 
reassessment (or at least reassertion) by someone competent?


br
Paul



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#4921): https://lists.spdx.org/g/Spdx-tech/message/4921
Mute This Topic: https://lists.spdx.org/mt/96263894/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] SPDX - true or false? (was Re: Getting started...)

[Karsten Klein]

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" mailto:Spdx-tech@lists.spdx.org> on behalf of paul.sherw...@codethink.co.uk 
> 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=sherwood
 

[2] https://github.com/jaraco/keyring/issues/263 

[3] https://github.com/pombredanne/spdx-pypi-pep/issues/1 

[4] 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, 

Re: [spdx-tech] SPDX - true or false? (was Re: Getting started...)

[Dick Brooks]

Paul,

There is no escaping manual input from the process that leads to an SBOM,
SPDX or CycloneDX. Someone has to input the data somewhere in order for it
to be available at SBOM creation time. 

If you are concerned that manual entry occurs somewhere  in the process
that ultimately results in an SBOM then I don't think this concern will ever
go away. 

Manual effort is an inherent part of software creation, and yes, human error
can, and does occasionally occur.

Thanks,

Dick Brooks
  
Active Member of the CISA Critical Manufacturing Sector, 
Sector Coordinating Council - A Public-Private Partnership

Never trust software, always verify and report! T
http://www.reliableenergyanalytics.com
Email: d...@reliableenergyanalytics.com
Tel: +1 978-696-1788

-Original Message-
From: Spdx-tech@lists.spdx.org  On Behalf Of Paul
Sherwood
Sent: Saturday, January 14, 2023 3:31 AM
To: spdx-tech@lists.spdx.org
Subject: [spdx-tech] SPDX - true or false? (was Re: Getting started...)

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=
sherwood
[2] https://github.com/jaraco/keyring/issues/263
[3] https://github.com/pombredanne/spdx-pypi-pep/issues/1
[4] 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 wha

[spdx-tech] SPDX - true or false? (was Re: Getting started...)

[Paul Sherwood]

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=sherwood

[2] https://github.com/jaraco/keyring/issues/263
[3] https://github.com/pombredanne/spdx-pypi-pep/issues/1
[4] 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
[2] https://github.com/jaraco/keyring/issues/263
[3] https://xkcd.com/927/



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#4918): 

Re: [spdx-tech] [GSOC'17] Getting Started

[Philippe Ombredanne]

On Thu, Mar 2, 2017 at 8:30 PM, VAIBHAV GUPTA
<guptavaibhav18...@gmail.com> wrote:
> Hello SPDX Community,
> I am Vaibhav Gupta, student at IIIT, Hyderabad, India. I am interested in
> 'Online Validation Tools' project for GSOC'17. As I am new to open source, I
> will be needing some guidance to initiate the work. Please help me getting
> started.

Welcome Vaibhav and thank you for considering SPDX for the GSOC 2017!

Here is a gist of what this validation tool could be:

1. input would be either one of a full SPDX document as tag/values or
RDF or a simple license expression
2. the output would be a list of SPDX errors, warnings, info and
recommendation and where they occurred exactly in the document or
license expression in a visually easy way to support review.

Tech-wise, I think we are open: I would personally favor using the
Python libraries.
UX-wise this should be available as a web UI and a REST API.

I hope this helps.

-- 
Cordially
Philippe Ombredanne
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

[spdx-tech] [GSOC'17] Getting Started

[VAIBHAV GUPTA]

Hello SPDX Community,
I am Vaibhav Gupta, student at IIIT, Hyderabad, India. I am interested in
'Online Validation Tools' project for GSOC'17. As I am new to open source,
I will be needing some guidance to initiate the work. Please help me
getting started.

Thank you

On Fri, Mar 3, 2017 at 12:04 AM, Kate Stewart <kstew...@linuxfoundation.org>
wrote:

> Hi Vaibhav,
> The spdx-tech list is a self subscribing list.
>
> You can subscribe to it https://lists.spdx.org/mailman/listinfo/spdx-tech
>
> Thanks for your interest.  :-)
>
> Kate
>
> On Thu, Mar 2, 2017 at 12:25 PM, VAIBHAV GUPTA <
> guptavaibhav18...@gmail.com> wrote:
>
>> guptavaibhav18...@gmail.com
>>
>> ___
>> Spdx-tech mailing list
>> Spdx-tech@lists.spdx.org
>> https://lists.spdx.org/mailman/listinfo/spdx-tech
>>
>>
>
>
> --
> Kate Stewart
> Sr. Director of Strategic Programs,  The Linux Foundation
> Mobile: +1.512.657.3669
> Email / Google Talk: kstew...@linuxfoundation.org
>
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: Getting started...

[Kate Stewart]

Just following up on this open action...


> On Thu, Feb 16, 2017 at 12:40 PM, Paul Sherwood <
> paul.sherw...@codethink.co.uk> wrote:
>
>
>> At Kate's talk [1] (can't find the slides online, btw)
>
>
Sorry for the delay,  needed to get some image attributions cleaned up:

Slides can be found at: Making Compliance Easy: Filling in the Missing
Pieces.


Thanks, Kate
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

RE: Getting started...

[Gisi, Mark]

>> Mark' scanner may be constrained by its underlying license detection engine
>> and not catch this alright. I would guess this engine to be fossology.
>> Mark: is this a correct guess?

Wind River's detection approach is to employ multiple scanning technologies + 
plus a voting algorithm (some technologies are better at identifying different 
licenses hence get a higher weight). We continue to add new and remove scanning 
technologies overtime. One problem is that different distros will sometimes 
designate different package level licensing for the same package.  We have 
recently integrated a database that includes human analysis of the package 
licenses that looks at the most popular package level license designation 
(e.g., 4 or 7 distros agree on the same license). 

>> Note that per keyring metadata the correct license is "MIT and Python-2.0"
>> and not just MIT.

The algorithm being discussed here has a specific purpose - *to measure the 
discipline a project in ensuring every file has a license notice*.  The package 
level license (or license found in a meta file) is often worthless or worst - 
deceptive. For example, the case where someone copies files into the Keyring 
project from another project under say the LGPL-2.1 (or GPL, Apache, ...) where 
the other project also only noted LGPL-2.1 (or GPL-2.0, Apache) in a meta file. 
That is, those files are NOT MIT and Python-2.0 so the meta file is misleading. 
If Keyring was more disciplined in putting a license notice in every file there 
is a higher probability they would have added the proper LGPL-2.1 (or GPL, 
Apache, ...) notice. Observation - The more successful a project is, the more 
likely they are to borrow from other projects that use different licensing 
(e.g., busybox, Linux Kernel). What is particularly valuable about SPDX is that 
it allows one to deliver licensing down to the file
  level and to show when licensing is missing. At the time we reviewed Keyring  
several years back it did not have a proper meta file license designation. It 
is for these various reasons Keyring deserved a failing License Coverage grade. 

- Mark



  










-Original Message-
From: Philippe Ombredanne [mailto:pombreda...@nexb.com] 
Sent: Monday, February 20, 2017 2:24 AM
To: spdx-tech@lists.spdx.org
Cc: Gisi, Mark; Schuberth, Sebastian; Paul Sherwood; Kate Stewart
Subject: Re: Getting started...

On Sat, Feb 18, 2017 at 5:58 PM, Paul Sherwood <paul.sherw...@codethink.co.uk> 
wrote:
> On 2017-02-18 04:54, Gisi, Mark wrote:
>>>> 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.
>>
>>
>> Wind River has provided a free SPDX creation service for more than
>> three years including the dashboard view:
>>  http://spdx.windriver.com/pkg_upload.aspx
>>
>> We did this to allow one to obtain instance access to the SPDX
>> creation process to promote the adoption of SPDX.  All you need is a
>> software package and an email address (actually you only need an email
>> since we provide sample packages as well). We make it so easy that
>> even your grandmother can create an SPDX file - provide she has an
>> email account (at least that was a core design principle  that guided
>> us).
>
>
> Given that the service you're mentioning is proprietary, I'm not sure
> whether the algorithm is the same as what led to Kate's slide or not. But in
> any case the keyring upstream maintainer points out that his licensing is
> detected at https://pypi.org/project/keyring/ and it seems that the service
> Kate used did not detect it.

Paul, Kate:
keyring is actually using the standard Pypi metadata to document its license
in its setup.py file [1] and this contains proper identification.

Note that per keyring metadata the correct license is "MIT and Python-2.0"
and not just MIT.

Mark' scanner may be constrained by its underlying license detection engine
and not catch this alright. I would guess this engine to be fossology.
Mark: is this a correct guess?

Now, the latest ScanCode toolkit [2] detects keyring's two licenses correctly.

ScanCode [2] is open source software and now has emerging support for
SPDX contributed by Sebastian Schuberth.

See also several related comments in this issue Paul entered on keyring [3]

[1] https://pypi.python.org/pypi?:action=list_classifiers
[2] https://github.com/nexB/scancode-toolkit/
[3] https://github.com/jaraco/keyring/issues/263#issuecomment-281035598

-- 
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombreda...@nexb.com
DejaCode : What's in your code?! at http://www.dejacode.com
nexB Inc. at http://www.nexb.com
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Re: Getting started...

[Philippe Ombredanne]

On Sat, Feb 18, 2017 at 5:58 PM, Paul Sherwood
 wrote:
> On 2017-02-18 04:54, Gisi, Mark wrote:
 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.
>>
>>
>> Wind River has provided a free SPDX creation service for more than
>> three years including the dashboard view:
>>  http://spdx.windriver.com/pkg_upload.aspx
>>
>> We did this to allow one to obtain instance access to the SPDX
>> creation process to promote the adoption of SPDX.  All you need is a
>> software package and an email address (actually you only need an email
>> since we provide sample packages as well). We make it so easy that
>> even your grandmother can create an SPDX file - provide she has an
>> email account (at least that was a core design principle  that guided
>> us).
>
>
> Given that the service you're mentioning is proprietary, I'm not sure
> whether the algorithm is the same as what led to Kate's slide or not. But in
> any case the keyring upstream maintainer points out that his licensing is
> detected at https://pypi.org/project/keyring/ and it seems that the service
> Kate used did not detect it.

Paul, Kate:
keyring is actually using the standard Pypi metadata to document its license
in its setup.py file [1] and this contains proper identification.

Note that per keyring metadata the correct license is "MIT and Python-2.0"
and not just MIT.

Mark' scanner may be constrained by its underlying license detection engine
and not catch this alright. I would guess this engine to be fossology.
Mark: is this a correct guess?

Now, the latest ScanCode toolkit [2] detects keyring's two licenses correctly.

ScanCode [2] is open source software and now has emerging support for
SPDX contributed by Sebastian Schuberth.

See also several related comments in this issue Paul entered on keyring [3]

[1] https://pypi.python.org/pypi?:action=list_classifiers
[2] https://github.com/nexB/scancode-toolkit/
[3] https://github.com/jaraco/keyring/issues/263#issuecomment-281035598

-- 
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombreda...@nexb.com
DejaCode : What's in your code?! at http://www.dejacode.com
nexB Inc. at http://www.nexb.com
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

RE: Getting started...

[Schuberth, Sebastian]

Thanks Mark for reminding me of that service. When I tried it in the past I had 
some (minor) issues with it, and will send my feedback to s...@windriver.com 
with you in CC.

Regards,
Sebastian


> -Original Message-
> From: spdx-tech-boun...@lists.spdx.org [mailto:spdx-tech-
> boun...@lists.spdx.org] On Behalf Of Gisi, Mark
> Sent: Saturday, February 18, 2017 5:55
> To: Paul Sherwood <paul.sherw...@codethink.co.uk>; spdx-
> t...@lists.spdx.org
> Subject: RE: Getting started...
> 
> Hi Paul,
> 
> >> 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.
> 
> Wind River has provided a free SPDX creation service for more than three
> years including the dashboard view:
> 
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fspd
> x.windriver.com%2Fpkg_upload.aspx=01%7C01%7C%7Cb9734961a9c94
> 3f5340e08d457ba59ae%7C6d4034cd72254f72b85391feaea64919%7C1=
> RqSMWkkA9PqbURVS7i0bOMEtIh60EH26y978U7Akkjc%3D=0
> 
> We did this to allow one to obtain instance access to the SPDX creation
> process to promote the adoption of SPDX.  All you need is a software
> package and an email address (actually you only need an email since we
> provide sample packages as well). We make it so easy that even your
> grandmother can create an SPDX file - provide she has an email account (at
> least that was a core design principle  that guided us).
> 
> Best,
> - Mark
> 
> ___
> Spdx-tech mailing list
> Spdx-tech@lists.spdx.org
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.spdx.org%2Fmailman%2Flistinfo%2Fspdx-
> tech=01%7C01%7C%7Cb9734961a9c943f5340e08d457ba59ae%7C6d403
> 4cd72254f72b85391feaea64919%7C1=RRon4I%2F80lZUgHWCdzepjcOC
> CdSbY2JNKFfgJ7UP0oY%3D=0
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

RE: Getting started...

[Wheeler, David A]

Paul Sherwood:
>>- maybe worth trying to get a CII badge for SPDX :)

Kate Stewart:
> For spdx-tools - yes, worth discussing.

I’m technical lead of the CII badge project.  Yes, I’d *really* like to see 
that for spdx-tools, FOSSology, and other SPDX-related OSS projects.

If there’s any way that we can help, please let us know!!

It’s very straightforward – just have anyone on the specific project (not 
necessarily the lead) go to:
  https://bestpractices.coreinfrastructure.org/
and click on “Get Your Badge Now!”.  It’s basically a web form, and we even try 
to fill in some of the answers for you (by looking at the data at the project 
site).  It typically takes an hour or less to fill in the form, so it’s not a 
huge investment of time.   Many people find that their project is doing most of 
it, and there’s only a few things the project isn’t doing.  You can then decide 
if you want to do them.. but most projects agree that they’re good things, so 
they go do them & come back to finish the form (and get the badge).  Then you 
can show off the badge - which provides potential users some evidence that 
you're actively working to create good results.

You do NOT have to be perfect to get started.  Just get started.

> We are interacting with the CII project 
and have been taking input on how to hook up security information into SPDX, as 
well
as providing input to them on best practices for projects from a licensing 
perspective. ;-)

I can confirm that we’ve been actively talking with the SPDX community 
(including Kate Stewart!) about the criteria.  The current “passing” criteria 
already specifically require license statement as a SPDX license expression, 
and we’ve already received some great ideas for higher-level badge criteria.  
We’re certainly not strangers; on my own time I wrote a tutorial on SPDX, and 
obviously I’m on this mailing list.

Of course, we’d love to have even more feedback.  We’d love to have suggestions 
on our draft higher-level criteria:
  
https://github.com/linuxfoundation/cii-best-practices-badge/blob/master/doc/other.md
If you have ideas, please create an issue:
  https://github.com/linuxfoundation/cii-best-practices-badge/issues

--- David A. Wheeler

___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

RE: Getting started...

[Paul Sherwood]

Hi Mark
On 2017-02-18 04:54, Gisi, Mark wrote:
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.


Wind River has provided a free SPDX creation service for more than
three years including the dashboard view:
 http://spdx.windriver.com/pkg_upload.aspx

We did this to allow one to obtain instance access to the SPDX
creation process to promote the adoption of SPDX.  All you need is a
software package and an email address (actually you only need an email
since we provide sample packages as well). We make it so easy that
even your grandmother can create an SPDX file - provide she has an
email account (at least that was a core design principle  that guided
us).


Given that the service you're mentioning is proprietary, I'm not sure 
whether the algorithm is the same as what led to Kate's slide or not. 
But in any case the keyring upstream maintainer points out that his 
licensing is detected at https://pypi.org/project/keyring/ and it seems 
that the service Kate used did not detect it.


br
Paul
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech

Getting started...

[Paul Sherwood]

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
[2] https://github.com/jaraco/keyring/issues/263
[3] https://xkcd.com/927/
___
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech