Re: EPL-2.0 final text (was: meeting tomorrow, general update)

2017-09-15 Thread Richard Fontana 
On Fri, Sep 15, 2017 at 02:08:15PM -0700, W. Trevor King wrote:
> On Fri, Sep 15, 2017 at 01:10:44PM -0400, Wayne Beaton wrote:
> > Exhibit A - Form of Secondary Licenses Notice
> > 
> > "This Source Code may also be made available under the following 
> > Secondary Licenses when the conditions for such availability set forth 
> > in the Eclipse Public License, v. 2.0 are satisfied: {name license(s),
> > version(s), and exceptions or additional permissions here}."
> 
> This seems like the new version.  The OSI still hasn't published their
> approved text [1], although they were originally considering the “This
> Source Code is also Distributed under” wording [2] and that's what
> they approved [3].  The text change is under OCI discussion in [4],
> but that just started yesterday.  We probably want to wait and see how
> the change shakes out in the OSI before stamping an ID for the final
> text.

This is now probably sufficiently resolved for purposes of the SPDX
legal group. See:
https://lists.opensource.org/pipermail/license-review/2017-September/003090.html

Richard


> [1]: https://opensource.org/licenses/alphabetical
> [2]: 
> https://lists.opensource.org/pipermail/license-review/2017-June/003048.html
>  Subject: [License-review] For Approval: Eclipse Public LIcense version 
> 2.0
>  Date: Thu Jun 15 19:50:51 UTC 2017
> [3]: 
> https://lists.opensource.org/pipermail/license-review/2017-August/003074.html
>  Subject: [License-review] For Approval: Eclipse Public LIcense version 
> 2.0
>  Date: Thu Aug 10 17:11:18 UTC 2017
> [4]: 
> https://lists.opensource.org/pipermail/license-review/2017-September/003082.html
>  Subject: [License-review] New Exhibit A for EPLv2
>  Date: Thu Sep 14 21:11:06 UTC 2017
> 
> -- 
> This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
> For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy



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

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

Re: Package licensing part I - the approach - was Github example

2017-09-15 Thread W. Trevor King 
On Fri, Sep 15, 2017 at 06:02:00AM +, Gisi, Mark wrote:
> How does one define “accurate and complete” when a package’s “top
> level” license does not represent all the files contained within the
> package (think license diversity).  Although there was no standard
> agreement on what “accurate and complete” meant, I got the strong
> impression looking at the customer’s spreadsheet that a package’s
> top level license was not enough.

If you're going to look through the package an conclude licenses for
each file (a good idea when you need this level of detail), then
you'll have declared/concluded licenses for each file (or parts of
files, if you use snippets).  Once you've collected that, an “accurate
and complete” license for the package would be the AND-ed combination
of all the file/snippet licenses.

However, in many cases there will be content in those packages that is
not ending up in the final device (e.g. documentation, some license
files, project management and policy information, …) that someone
shipping a device does not care about.  Those file/snippet licenses
won't matter to them (unless they are interested in pushing doc
patches back upstream, or some such).

So I'd recommend just providing those customers with file/snippet
granularity and find a workflow that does not bother with “package
licenses”.

If they can't support that level of granularity, ask them to provide
you with a list of files/snippets they care about and only AND their
licenses to conclude a selected-project-subset license.

If they can't provide a list of files/snippets they care about and can
only accept conclusions at the package level, then they're going to
get things like “GPL-3.0 AND Verbatim” for a package that includes
GPL-3.0 code and the text of the GPL 3.0.  But the Verbatim license
contains no onerous conditions for someone shipping devices, so they
probably won't mind.

> There are obviously other types of open source users who do not
> share the same compliance challenges as Stakeholder #1. Consider
> businesses that provides Software as a Service (SaaS) where the lion
> share of the open source runs in the data center as opposed to being
> distributed on millions of devices. Think of Facebook, Netflix,
> Airbnb, and Lyft. For SaaS provider’s software distribution is
> typically not a consideration (except perhaps for the apps you
> download onto your phone). The license compliance complexity and
> risk profile for a SaaS provider is very low compared to device
> makers, their need for SPDX file level licensing information tends
> to very low, if at all.

Maybe the risk is lower, but they have the same issue.  For example,
the AGPL-3.0 has explicit requriments for this use case [1].  Where
detailed licensing is expensive, SaaS providers end up cutting
corners.  But if everyone was doing things right, SaaS providers would
have the same audit-trail robustness that you attribute to device
shippers.

> Many of the products you use (or drive) are created by Stakeholder
> #1. If they lack sufficient file level licensing information…

And nobody is arguing for removing file/snippet granularity (just like
nobody is arguing for removing LicenseRef [2]).  So what problems does
SPDX not address for either of these use cases?

Cheers,
Trevor

[1]: 
https://github.com/spdx/license-list-XML/blob/f1522b5cc61bde64d9b38af05204fdb93c02eef8/src/AGPL-3.0.xml#L480-L494
[2]: https://lists.spdx.org/pipermail/spdx-legal/2017-September/002184.html
 Subject: Re: GPLv2 - Github example
 Date: Tue, 12 Sep 2017 09:45:38 -0700
 Message-ID: <20170912164538.gg30...@valgrind.tremily.us>

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

EPL-2.0 final text (was: meeting tomorrow, general update)

2017-09-15 Thread W. Trevor King 
On Fri, Sep 15, 2017 at 01:10:44PM -0400, Wayne Beaton wrote:
> Exhibit A - Form of Secondary Licenses Notice
> 
> "This Source Code may also be made available under the following 
> Secondary Licenses when the conditions for such availability set forth 
> in the Eclipse Public License, v. 2.0 are satisfied: {name license(s),
> version(s), and exceptions or additional permissions here}."

This seems like the new version.  The OSI still hasn't published their
approved text [1], although they were originally considering the “This
Source Code is also Distributed under” wording [2] and that's what
they approved [3].  The text change is under OCI discussion in [4],
but that just started yesterday.  We probably want to wait and see how
the change shakes out in the OSI before stamping an ID for the final
text.

Cheers,
Trevor

[1]: https://opensource.org/licenses/alphabetical
[2]: https://lists.opensource.org/pipermail/license-review/2017-June/003048.html
 Subject: [License-review] For Approval: Eclipse Public LIcense version 2.0
 Date: Thu Jun 15 19:50:51 UTC 2017
[3]: 
https://lists.opensource.org/pipermail/license-review/2017-August/003074.html
 Subject: [License-review] For Approval: Eclipse Public LIcense version 2.0
 Date: Thu Aug 10 17:11:18 UTC 2017
[4]: 
https://lists.opensource.org/pipermail/license-review/2017-September/003082.html
 Subject: [License-review] New Exhibit A for EPLv2
 Date: Thu Sep 14 21:11:06 UTC 2017

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: License identifiers sufficient to avoid loss of information in DeclaredLicense

2017-09-15 Thread W. Trevor King 
On Fri, Sep 15, 2017 at 11:19:04AM +, Gisi, Mark wrote:
> >> 3.15 Declared License
>
> The problem with this field does not lie with the LEL but with the values the 
> "field" will accept.
>
>   "This field lists the licenses that have been declared by the
>   authors of The package.  "
>
> It should probably accept a list of LELs. For example if the top
> level directory had the following license files:
>
> COPYING.GPL-2.0
> COPYING.LGPL-2.0
>
> Then the declared license field should accept the "list" of LELs:
> GPL-2.0, LGPL-2.1

I don't consider the presence of a license file to be a declaration of
package license [1].  A package which includes those files might
declare (in a README, or package.json, etc.) that it is:

  LGPL-2.0

Or it might contain a LGPL-2.0 library and a GPL-2.0 tool which
consumes that libary, and declare somewhere else that it is:

  LGPL-2.0 AND GPL-2.0

Or maybe they've decided to allow downstream consumers to choose to
fork off more-viral projects and dual licensed:

  LGPL-2.0 OR GPL-2.0

Without an explicit package license declaration (in a README,
package.json, etc.) the declared package license is NOASSERTION.  If
you can tell consumers “The author wasn't clear, but I've concluded
that this package is ‘LGPL-2.0 AND GPL-2.0’”, that's useful
information.  If you can tell consumers “I haven't checked, but the
package author claims this is ‘LGPL-2.0 AND GPL-2.0’” that's useful
information.  If all you can tell consumers is “I found text for the
LGPL-2.0 and GPL-2.0 licenses but haven't concluded anything” that is
less useful.

Licensee, which only looks for stand-alone license files [2], at least
attempts to avoid concluding a license when it finds multiple licence
files [3] although it has a special case for the LGPL family, since
that license is usually split over two files [4].  And that sort of
heuristic is fine for calculating the concluded licenses, especially
when the results come with big as-is caveat [5].  They're not saying
that the presence of the license files constitutes a license
*declaration*.

Cheers,
Trevor

[1]: https://lists.spdx.org/pipermail/spdx-legal/2017-September/002205.html
 Subject: Re: License identifiers sufficient to avoid loss of
   information in DeclaredLicense (was: GPLv2 - Github example)
 Date: Thu, 14 Sep 2017 13:10:36 -0700
 Message-ID: <20170914201036.gd30...@valgrind.tremily.us>
[2]: https://github.com/benbalter/licensee/blob/v9.2.1/docs/what-we-look-at.md
[3]: https://github.com/benbalter/licensee/issues/114
[4]: https://github.com/benbalter/licensee/pull/203
[5]: https://developer.github.com/v3/licenses/

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: License identifiers sufficient to avoid loss of information in DeclaredLicense (was: GPLv2 - Github example)

2017-09-15 Thread W. Trevor King 
On Fri, Sep 15, 2017 at 12:01:32PM +, Zavras, Alexios wrote:
> Besides the case of GPL version numbers, isn't the issue similar to
> when we have cases like where you have a package that simply says
> "This program is under the BSD license"

This is definitely a similar case.  The difference is that the GPL
family have internal wording for this case [1], while the BSDs do not.

> The author "declared" something, but the SPDX spec is not really
> useful, since the value of the field is a license (or a license
> expression) and not a free form text. None of the licenses in the
> SPDX license list can be used as "PackageLicenseDeclared". Do we put
> a list of the 15 or so BSD variants, or disregard the declaration by
> stating "NOASSERTION"?

I would say NOSSERTION, because I don't think you're discarding much
information.  If you wanted to represent this case, you'd need a new
license expression operator for “or maybe they meant”.  That doesn't
seem particularly actionable to me, and I'd want to take a closer look
at a project if the best-estimate (a trusted conclusion when we have
one, and a declared call or unreliable conclusion when we don't)
involved such an operator.

> Taking it further, suppose that by looking at the actual wording of
> the license text in files, you might decide that the author is
> talking about BSD-3-Clause-No-Nuclear-License (in the nice case
> where all the files use the same text). But isn't this a "Concluded"
> rather than a "Declared" field?

If there are license terms in the header that match
BSD-3-Clause-No-Nuclear-License, then that seems like a pretty clear
declaration of BSD-3-Clause-No-Nuclear-License for those files, and
that would go in LicenseInfoInFile.  I think that could inform your
concluded package license, but it should not impact the declared
package license.

Cheers,
Trevor

[1]: 
https://github.com/spdx/license-list-XML/blob/f1522b5cc61bde64d9b38af05204fdb93c02eef8/src/GPL-1.0.xml#L167-L168

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: meeting tomorrow, general update

2017-09-15 Thread Wayne Beaton 
I had intended to attend the call, but entered the coordinates incorrectly
in my calendar. My apologies for missing.

The EPL-2.0 as it exists on the Eclipse Foundation website contains the
actual and final text.

landing page: http://www.eclipse.org/legal/epl-2.0
html: https://www.eclipse.org/org/documents/epl-2.0/EPL-2.0.html
plaintext: https://www.eclipse.org/org/documents/epl-2.0/EPL-2.0.txt

You'll notice that I've been using what I expect will be the SPDX code in
the URLs.

For consistency with the URL for the EPL-1.0, we've created a "bonus" HTML
URL:

https://www.eclipse.org/legal/epl-v20.html

I've attached it here in HTML and plaintext formats.

Wayne

On Thu, Sep 14, 2017 at 4:22 PM, J Lovejoy  wrote:

> Indeed.
>
> While we didn’t get to discuss this on the call today as we ran out of
> time, I think it’s a no-brainer that it should be added to the license list
> and that aspect probably does not need discussion :)  If there is some
> oddity as to how it gets added due to the Exhibit (which I admittedly, have
> not investigated/thought about thoroughly yet), that needs to be addressed.
>
> but it would be good to have some assurance that this is the actual and
> final text of the 2.0 version… !!!
>
> Jilayne
>
>
>
> On Sep 14, 2017, at 2:17 PM, Dennis Clark  wrote:
>
> Richard, Trevor,
>
> Thanks very much for the heads-up about the license text change and
> corresponding details. Yes, Unversioned license changes are, ahem,
> exciting.
>
> Regards,
> Dennis Clark
>
>
> On Thu, Sep 14, 2017 at 12:38 PM, W. Trevor King  wrote:
>
>> On Thu, Sep 14, 2017 at 02:36:01PM -0400, Richard Fontana wrote:
>> > Note that the EPL-2.0 text, at the canonical eclipse.org URL, and
>> > specifically Exhibit A, has been changed since this was first
>> > discussed on spdx-legal…
>>
>> Unversioned license changes… exciting :p.  I also see that the initial
>> post to spdx-legal@ [1] didn't include the license text as an
>> attachment (part of the official submission policy [2]), which makes
>> it hard to ensure that everyone is talking about the same thing.
>> Comparing the current content of [3] with [4], the differences are:
>>
>>   $ diff -u EPL-2.0-GitHub EPL-2.0-canonical
>>   --- EPL-2.0-GitHub 2017-08-21 19:58:57.0 -0700
>>   +++ EPL-2.0-canonical  2017-09-06 12:03:33.0 -0700
>>   @@ -261,10 +261,10 @@
>>
>>Exhibit A - Form of Secondary Licenses Notice
>>
>>   -"This Source Code is also Distributed under one
>>   -or more Secondary Licenses, as those terms are defined by
>>   -the Eclipse Public License, v. 2.0: {name license(s),version(s),
>>   -and exceptions or additional permissions here}."
>>   +"This Source Code may also be made available under the following
>>   +Secondary Licenses when the conditions for such availability set forth
>>   +in the Eclipse Public License, v. 2.0 are satisfied: {name license(s),
>>   +version(s), and exceptions or additional permissions here}."
>>
>>  Simply including a copy of this Agreement, including this Exhibit A
>>  is not sufficient to license the Source Code under Secondary
>> Licenses.
>>
>> and a lack of a trailing newline in [3].
>>
>> Cheers,
>> Trevor
>>
>> [1]: https://lists.spdx.org/pipermail/spdx-legal/2017-August/002134.html
>>  Subject: New License/Exception Request: EPL-2.0
>>  Date: Mon, 21 Aug 2017 20:52:44 -0400
>>  Message-ID:

RE: License identifiers sufficient to avoid loss of information in DeclaredLicense (was: GPLv2 - Github example)

2017-09-15 Thread Zavras, Alexios 
Besides the case of GPL version numbers, isn't the issue similar to when we 
have cases like where you have a package that simply says
"This program is under the BSD license"

The author "declared" something, but the SPDX spec is not really useful, since 
the value of the field is a license (or a license expression) and not a free 
form text. None of the licenses in the SPDX license list can be used as 
"PackageLicenseDeclared". Do we put a list of the 15 or so BSD variants, or 
disregard the declaration by stating "NOASSERTION"?

Taking it further, suppose that by looking at the actual wording of the license 
text in files, you might decide that the author is talking about 
BSD-3-Clause-No-Nuclear-License (in the nice case where all the files use the 
same text). But isn't this a "Concluded" rather than a "Declared" field?

-- zvr -

-Original Message-
From: spdx-legal-boun...@lists.spdx.org 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of Gisi, Mark
Sent: Friday, 15 September, 2017 13:19
To: Bradley M. Kuhn ; SPDX-legal 
Subject: RE: License identifiers sufficient to avoid loss of information in 
DeclaredLicense (was: GPLv2 - Github example)


Quick clarification:

>> I admit that I don't know how exactly to express such as Declarations. 
>> What is quite clear from this discussion, though, is that the 
>> Conclusions that people make about such Declarations vary.  Mark Gisi 
>> Concludes most of these examples as NOASSERTION.
>> I Conclude most of them are GPLv1-or-later.

The examples addressed Conclude License (files and package) but not the 
Declared License.
Furthermore, I only made a comment about Example 4. I agreed with the file 
Concluded License designations for Examples 1-3. Including Example 3 = GPL-1.0+.

And yes, for Example 4 I concluded NOASSERTION for each of the four files that 
have zero licensing info in them. There are many scenarios where those files 
could be something other than GPL. For example, one or more source files could 
have been copied from an Apache project or a commercial code based. I have 
encountered two cases in as many years where commercial code was copied  into a 
project with a GPL-2.0 file in the top directory. In one case the commercial 
license notice was retained in the file and in the other the notice was 
removed. Another situation I encountered ~5 years ago: someone admittedly 
removed the BSD license notices from several files he copied into his GPL 
project. He just assumed that they were now under the GPL-2.0 and the BSD 
notices were confusing and unnecessary! I had to explain he was violating the 
BSD license. 

As for Example 4, for me, hope is not a strategy. NOASSERTION.

>>
>> 3.15 Declared License
>>

The problem with this field does not lie with the LEL but with the values the 
"field" will accept. 

"This field lists the licenses  that have been declared by the authors 
of 
The package.  "
It should probably accept a list of LELs. For example if the top level 
directory had the following license files:

COPYING.GPL-2.0
COPYING.LGPL-2.0 

Then the declared license field should accept the "list" of LELs: GPL-2.0, 
LGPL-2.1

This approach is simple and probably handles 95% + cases.

- Mark


-Original Message-
From: spdx-legal-boun...@lists.spdx.org 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of Bradley M. Kuhn
Sent: Wednesday, September 13, 2017 11:47 AM
To: SPDX-legal
Subject: License identifiers sufficient to avoid loss of information in 
DeclaredLicense (was: GPLv2 - Github example)

Since the Legal call where we first began discussing what Jilayne has called 
the "Github examples", I've been thinking about this question regularly.

I do agree wholeheartedly with Richard Fontana's point that SPDX both has 
stakeholders who use the license identifiers outside of SPDX (and that SPDX as 
a project lauds such uses).  SPDX should indeed think about those users.
I'm primarily one of those users to the extent I use SPDX.

However, for the purposes of this discussion, I suggest we return to first 
principles in the SPDX specification.  So I asked myself, what job does SPDX 
expect license identifiers to do?  I went to the SPDX spec and looked at
this:
   3.15 Declared License
 3.15.1 Purpose: This field lists the licenses that have been declared by 
the
 authors of the package.  Any license information that
 does not originate from the package authors,
 e.g. license information from a third party repository,
 should not be included in this field.
   (URL: https://spdx.org/spdx-specification-21-web-version#h.1hmsyys ) 

I began to think carefully about this question, what *is* the "Declared 
License" -- by the package authors -- in the examples at 
https://wiki.spdx.org/view/Legal_Team/only-operator-proposal#Examples_.2F_Challenges
?

I admit that I don't know how exactly to

RE: Package licensing part I - the approach - was Github example

2017-09-15 Thread Gisi, Mark 
Thank you Richard, Kyle and Trevor for providing insights into what is 
important to Stakeholder #2 (developers).



Before we proceed to the next step, I would like to provide insights into what 
is important to Stakeholder #1. It might be helpful to understand because one 
of the catalysts for creating SPDX was Stakeholder #1's license compliance 
challenges.



Stakeholder #1

---

A typical Stakeholder #1 would be a device maker that embeds software into the 
products they manufacture. Think of the typical manufacturers for TVs, 
printers, network routers, cameras, smart thermostats, automobiles, industrial 
robots, elevators, train control systems, wind turbines, medical devices, and 
so forth. Also think of all the “Things” in the Internet of Things. We are 
talking about billions of devices[1]. Linux combined with other open source 
solutions typically serve as the nervous system of those devices and represents 
the lion share of the software that runs on them. Each time a device sold 
(distributed) it triggers a set of license obligations that are typically more 
complex than other types of open source use cases (e.g., SaaS). Compliance at 
the file level is particularly relevant. Most device makers are committed to 
doing the right thing - i.e., they want to provide all the required source 
code, attribution notices, copies of license and so forth. Although not every 
company takes compliance to the same level, many of the device manufactures are 
quite advanced. They need to comply with the licensing of the libraries and 
binaries that end up on their device’s runtime. To determine the licensing for 
each of the libraries and binaries, the device maker needs to understand  the 
licensing of the source files from which they were constructed. Therefore the 
file level license is very important whereas the top level package license is 
much less so.



File level compliance can be challenging. Well managed open source projects 
typically include a license notice in every file, but unfortunately many 
projects do not. Furthermore, the more successful a project is, the more it 
shares (and borrows) code with other projects that are potentially under 
different licenses. This leads to license diversity at the file level, a 
byproduct of successful sharing and a reality that we need to embrace. SPDX 
facilitates the management of license diversity while making missing license 
information transparent. SPDX data is a valuable input into a device maker’s 
compliance program.



I have come to understand the concerns of Stakeholder #1 through contract 
negotiations I participated in with Wind River customers (largely device 
makers). In the past customers use to include all kinds of language on what 
defines open source and how they wanted licensing information delivered (often 
in their own custom spreadsheet format). The words that made me pause every 
time were: “we need you to provide *accurate and compete* licensing information 
for each Linux package”. How does one define “accurate and complete” when a 
package’s “top level” license does not represent all the files contained within 
the package (think license diversity). Although there was no standard agreement 
on what “accurate and complete” meant, I got the strong impression looking at 
the customer’s spreadsheet that a package’s top level license was not enough. 
SPDX played a valuable role whenever a customer tried to define what open 
source was and what their licensing reporting expectations were.  I replaced 
their language with the promise to deliver licensing  information using SPDX, 
the Linux community’s license reporting standard. All the concerns around 
“accurate and complete” went away. Furthermore, the time and cost saving by 
having to deal with just one format vs hundreds was significant.



SPDX is Not for Everyone:

---

There are obviously other types of open source users who do not share the same 
compliance challenges as Stakeholder #1. Consider businesses that provides 
Software as a Service (SaaS) where the lion share of the open source runs in 
the data center as opposed to being distributed on millions of devices. Think 
of Facebook, Netflix, Airbnb, and Lyft. For SaaS provider’s software 
distribution is typically not a consideration (except perhaps for the apps you 
download onto your phone). The license compliance complexity and risk profile 
for a SaaS provider is very low compared to device makers, their need for SPDX 
file level licensing information tends to very low, if at all.



Hard to Ignore Stakeholder #1:

-

Many of the products you use (or drive) are created by Stakeholder #1. If they 
lack sufficient file level licensing information it becomes much more difficult 
and costly to deliver the source code and attribution notices you deserve (and 
the source code authors expect). All in all, SPDX enables device makers to