Date   

call today

J Lovejoy
 

Hi,

We have our regularly scheduled call today at noon Eastern US time.

Tech Team Lead, Gary O'Neall, will be joining us to talk about the SPDX Online Tools! https://tools.spdx.org/app/

Jilayne


3.17 License List release

Steve Winslow
 

Hello all,

The version 3.17 release of the license list is now tagged and live at https://spdx.org/licenses.

5 new licenses were added to the list:
The release also included updates to various documentation, adjustments to markup for various licenses and other minor changes.

More details can be found in the release notes at https://github.com/spdx/license-list-XML/releases/tag/v3.17.

Thank you as always to the participants in the SPDX Legal community and license request submitters who contributed to this release.

Steve


Re: versioning of license list

J Lovejoy
 

Thanks all for the confirmation to keep on keepin’ on with our current mode, then!

J.

On Apr 29, 2022, at 7:25 AM, Warner Losh <imp@...> wrote:



On Fri, Apr 29, 2022 at 3:28 AM Bastien <bastien.guerry@...> wrote:
Hi Steve,

"Steve Winslow" <swinslow@...> writes:

> So I'd be inclined to stick with the current M.N format for now, and
> keep incrementing 3.x unless and until we hit a significant enough
> change to bump it to 4.0.

+1 -- semver is not really useful here, and 3.20 looks perfectly fine
in the eyes of developers (and probably beyond.)

I agree here. I think semvar's notions are an imperfect fit for the nature
of the license repo. We've selected major number to indicate a format
(which one could argue is the semantic element that count) and a minor
number for release number that includes additions and minor technical
corrections only. All the 3.x releases are basically compatible from
a format point of view, but have different content. I see no value
other than confusing from introducing a 'tiny' rev to the process
since there's already a quarterly release cadence.

Warner 


Re: Artistic-2.0 derivative - npm License

Till Jaeger
 

Am 02.05.22 um 13:43 schrieb Philippe Ombredanne:
Hi Till:
You have eagle eyes!
On Mon, May 2, 2022 at 10:46 AM Till Jaeger via lists.spdx.org
<jaeger=jbb.de@...> wrote:
I noticed that NPM is using an Artistic-2.0 with additional terms and
conditions:
This is IMHO a total and complete mess and non-sense, eventually non
FOSS at all.
Anyone from Microsoft or GitHub to fix this monstrosity?
Till:
Do you know when this showed up?
I stumbled across this rather by accident because I was looking for information on why NPM uses Artistic-2.0.

Internet Archive does not provide much help:
https://web.archive.org/web/20220315191342/https://docs.npmjs.com/policies/npm-license

Best,
Till


NB: I am adding a rule to ScanCode Toolkit to report this ASAP.
--
Cordially
Philippe


Re: Artistic-2.0 derivative - npm License

Jonas Smedegaard
 

Quoting Philippe Ombredanne (2022-05-02 13:43:56)
On Mon, May 2, 2022 at 10:46 AM Till Jaeger via lists.spdx.org
<jaeger=jbb.de@...> wrote:
I noticed that NPM is using an Artistic-2.0 with additional terms
and conditions:
This is IMHO a total and complete mess and non-sense, eventually non
FOSS at all.
Anyone from Microsoft or GitHub to fix this monstrosity?
Release notes for npm v2.14.13 contains the following:

npm-the-CLI is licensed under the terms of the [Artistic License
2.0](https://github.com/npm/npm/blob/8d79c1a39dae908f27eaa37ff6b23515d505ef29/LICENSE),
which is a liberal open-source license that allows you to take this
code and do pretty much whatever you like with it (that is, of course,
not legal language, and if you're doing anything with npm that leaves
you in doubt about your legal rights, please seek the review of
qualified counsel, which is to say, not members of the CLI team, none
of whom have passed the bar, to my knowledge). At the same time the
primary registry the CLI uses when looking up and downloading packages
is a commercial service run by npm, Inc., and it has its own [Terms of
Use](https://www.npmjs.com/policies/terms).
So seems to me (assuming licensing hasn't changed since v2.14.13) the
command-line tool *is* freely licensed, and only when describing
npm-as-a-whole-including-online-service is it not free.


- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private


Re: Artistic-2.0 derivative - npm License

Philippe Ombredanne
 

Hi Till:
You have eagle eyes!

On Mon, May 2, 2022 at 10:46 AM Till Jaeger via lists.spdx.org
<jaeger=jbb.de@...> wrote:
I noticed that NPM is using an Artistic-2.0 with additional terms and
conditions:
This is IMHO a total and complete mess and non-sense, eventually non
FOSS at all.
Anyone from Microsoft or GitHub to fix this monstrosity?

Till:
Do you know when this showed up?
NB: I am adding a rule to ScanCode Toolkit to report this ASAP.
--
Cordially

Philippe


Artistic-2.0 derivative - npm License

Till Jaeger
 

Hi all,

I noticed that NPM is using an Artistic-2.0 with additional terms and
conditions:

-----------------

npm License

Copyright (c) npm, Inc. and Contributors All rights reserved.

npm is released under the Artistic License 2.0, subject to additional
terms that are listed below.

The text of the npm License follows and the text of the additional terms
follows the Artistic License 2.0 terms:
...

---------------

https://docs.npmjs.com/policies/npm-license


It seems that people there are not familiar of what is the goal of a
license. Otherwise they wouldn't have used the following additional term:

"Additional policies relating to, and restrictions on use of, npm
products and services are available on the npm website. All such
policies and restrictions, as updated from time to time, are hereby
incorporated into this license agreement. By using npm, you acknowledge
your agreement to all such policies and restrictions."

Hence, the license text may vary dpending on an update of such policies.
I guess this makes it difficult to provide a SPDX-Identifier. Any
thoughts on this?

Best regards,

Till


Re: versioning of license list

Warner Losh
 



On Fri, Apr 29, 2022 at 3:28 AM Bastien <bastien.guerry@...> wrote:
Hi Steve,

"Steve Winslow" <swinslow@...> writes:

> So I'd be inclined to stick with the current M.N format for now, and
> keep incrementing 3.x unless and until we hit a significant enough
> change to bump it to 4.0.

+1 -- semver is not really useful here, and 3.20 looks perfectly fine
in the eyes of developers (and probably beyond.)

I agree here. I think semvar's notions are an imperfect fit for the nature
of the license repo. We've selected major number to indicate a format
(which one could argue is the semantic element that count) and a minor
number for release number that includes additions and minor technical
corrections only. All the 3.x releases are basically compatible from
a format point of view, but have different content. I see no value
other than confusing from introducing a 'tiny' rev to the process
since there's already a quarterly release cadence.

Warner 


Re: versioning of license list

Bastien
 

Hi Steve,

"Steve Winslow" <swinslow@...> writes:

So I'd be inclined to stick with the current M.N format for now, and
keep incrementing 3.x unless and until we hit a significant enough
change to bump it to 4.0.
+1 -- semver is not really useful here, and 3.20 looks perfectly fine
in the eyes of developers (and probably beyond.)

All best,

--
Bastien Guerry


Re: versioning of license list

Steve Winslow
 

Thanks all!

One note just for consideration here: the version numbering for the License List has at least a syntactic meaning also within the spec itself, for SPDX documents:  see https://spdx.github.io/spdx-spec/document-creation-information/#67-license-list-version-field

That defines it as a "Major.Minor" format. That could be changed for a future release of the SPDX spec of course, but I expect that would be a breaking change if it went to something like semver.

So I'd be inclined to stick with the current M.N format for now, and keep incrementing 3.x unless and until we hit a significant enough change to bump it to 4.0.

At four releases a year, that should give us *does some quick math* roughly another 20 years before we hit a Y2K issue with the minor version number, so I think we should be fine for now  :)

Steve

On Thu, Apr 28, 2022 at 5:02 PM Sebastian Crane <seabass-labrax@...> wrote:
Dear Jilayne,

> We only have changed the major number when there was a major change - adding
> license expression operators for 2.0; changing to XML format and major
> change to GNU identifiers or 3.0. I don't really foresee a major change of
> that nature on the horizon (good!). This would mean we just keeping going
> with 3.y - is that normal?

Yes, I would say that's pretty normal for software projects. Incrementing the
major version usually indicates that upgrading to that version would break
something for existing users that rely on the data, so 3.16 to 3.17 would be
'correct' for this release (which shouldn't break anything!)

If we were going full 'semantic versioning' (formalised at https://semver.org/
), however, we'd also have a 'patch level' version for releases that only fix
existing licenses and don't add any new ones: 3.17.0 would become 3.17.1 if
there were no new licenses or exceptions added between those releases.

I don't have a strong desire to change it though, rest assured :)

Best wishes,

Sebastian






Re: versioning of license list

Sebastian Crane
 

Dear Jilayne,

We only have changed the major number when there was a major change - adding
license expression operators for 2.0; changing to XML format and major
change to GNU identifiers or 3.0. I don't really foresee a major change of
that nature on the horizon (good!). This would mean we just keeping going
with 3.y - is that normal?
Yes, I would say that's pretty normal for software projects. Incrementing the
major version usually indicates that upgrading to that version would break
something for existing users that rely on the data, so 3.16 to 3.17 would be
'correct' for this release (which shouldn't break anything!)

If we were going full 'semantic versioning' (formalised at https://semver.org/
), however, we'd also have a 'patch level' version for releases that only fix
existing licenses and don't add any new ones: 3.17.0 would become 3.17.1 if
there were no new licenses or exceptions added between those releases.

I don't have a strong desire to change it though, rest assured :)

Best wishes,

Sebastian


Re: versioning of license list

Alan Tse
 

I don’t think it’s an issue. To developers, 3.20 is normal and won’t be confused as 3.2.

 

I would advocate moving to semantic versioning where it uses a triplet (e.g. 3.20.0) and each part of the triplet has a meaning when it’s incremented. It may not matter since SPDX doesn’t release frequently enough to do “fix” only releases which would be 3.20.1, but at least it signals to downstream users that if the major version changes (e.g., 4.0.0) that the API may have broken.

 

Another benefit of semantic versioning is you can adopt tools like semantic release to automatically make the next version with a changelog.

 

 

From: <Spdx-legal@...> on behalf of J Lovejoy <opensource@...>
Date: Thursday, April 28, 2022 at 10:55 AM
To: "Spdx-legal@..." <Spdx-legal@...>
Subject: versioning of license list

 

CAUTION: This email originated from outside of Western Digital. Do not click on links or open attachments unless you recognize the sender and know that the content is safe.

 

Hi all,

As I was adding milestones to the Github repo for the next couple releases, I wondered... do we just keep going with 3.18, 3.19, 3.20... (and 3.20 looks a lot like 3.2, but I guess that was also the case with 3.10 and it wasn't an issue)?

We only have changed the major number when there was a major change - adding license expression operators for 2.0; changing to XML format and major change to GNU identifiers or 3.0. I don't really foresee a major change of that nature on the horizon (good!). This would mean we just keeping going with 3.y - is that normal?

Interesting to hear thoughts on this from more software-versioning-traditions savvy people :)

Jilayne


versioning of license list

J Lovejoy
 

Hi all,

As I was adding milestones to the Github repo for the next couple releases, I wondered... do we just keep going with 3.18, 3.19, 3.20... (and 3.20 looks a lot like 3.2, but I guess that was also the case with 3.10 and it wasn't an issue)?

We only have changed the major number when there was a major change - adding license expression operators for 2.0; changing to XML format and major change to GNU identifiers or 3.0. I don't really foresee a major change of that nature on the horizon (good!). This would mean we just keeping going with 3.y - is that normal?

Interesting to hear thoughts on this from more software-versioning-traditions savvy people :)

Jilayne


legal team meeting today

J Lovejoy
 

Hi all,

We have our regularly scheduled legal team meeting today in about an hour - at noon Eastern Daylight Savings time.

We’ll focus on clearing out any tasks, issues, PRs for the 3.17 release!

Jilayne


Re: SPDX Online Tools Maintence

Sebastian Crane
 

This is a wonderful improvement! It's an announcement worthy of the
'topic' for our #spdx IRC channel :)

Best wishes,

Sebastian


Re: SPDX Online Tools Maintence

Steve Winslow
 

Thank you Gary, Rohit and the GSoC students! I saw that the test license requests are coming through, so thanks for that in particular  :)

Steve

On Wed, Apr 13, 2022 at 4:16 PM Gary O'Neall <gary@...> wrote:

The SPDX online tools upgrade is now complete.

 

This release upgrades our Python version from 2.7 to version 3.X moving us to a more supported software base.  There are also several improvements.  The release notes can be found here: https://github.com/spdx/spdx-online-tools/releases/tag/v1.0.6

 

Please checkout the new upgrade at https://tools.spdx.org/

 

If you run into any issues or have a suggested improvement, please submit them here: https://github.com/spdx/spdx-online-tools/issues

 

Thanks to Rohit and the GSoC students and contributors who did a majority of the work.

 

Regards,
Gary

 

From: Gary O'Neall <gary@...>
Sent: Wednesday, April 13, 2022 7:52 AM
To: 'Spdx-tech@...' <Spdx-tech@...>; 'SPDX-legal' <Spdx-legal@...>
Cc: 'Rohit Lodha' <rohit.lodhartg@...>
Subject: SPDX Online Tools Maintence

 

Just FYI – We will be doing a significant upgrade to the SPDX online tools this morning.  The SPDX online tools will be offline this morning for a few minutes to a few hours depending on how the upgrade goes.

 

My apologies for any inconvenience.

 

Regards,
Gary

 

-------------------------------------------------

Gary O'Neall

Principal Consultant

Source Auditor Inc.

Mobile: 408.805.0586

Email: gary@...

CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.

 


Re: SPDX Online Tools Maintence

Gary O'Neall
 

The SPDX online tools upgrade is now complete.

 

This release upgrades our Python version from 2.7 to version 3.X moving us to a more supported software base.  There are also several improvements.  The release notes can be found here: https://github.com/spdx/spdx-online-tools/releases/tag/v1.0.6

 

Please checkout the new upgrade at https://tools.spdx.org/

 

If you run into any issues or have a suggested improvement, please submit them here: https://github.com/spdx/spdx-online-tools/issues

 

Thanks to Rohit and the GSoC students and contributors who did a majority of the work.

 

Regards,
Gary

 

From: Gary O'Neall <gary@...>
Sent: Wednesday, April 13, 2022 7:52 AM
To: 'Spdx-tech@...' <Spdx-tech@...>; 'SPDX-legal' <Spdx-legal@...>
Cc: 'Rohit Lodha' <rohit.lodhartg@...>
Subject: SPDX Online Tools Maintence

 

Just FYI – We will be doing a significant upgrade to the SPDX online tools this morning.  The SPDX online tools will be offline this morning for a few minutes to a few hours depending on how the upgrade goes.

 

My apologies for any inconvenience.

 

Regards,
Gary

 

-------------------------------------------------

Gary O'Neall

Principal Consultant

Source Auditor Inc.

Mobile: 408.805.0586

Email: gary@...

CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.

 


SPDX Online Tools Maintence

Gary O'Neall
 

Just FYI – We will be doing a significant upgrade to the SPDX online tools this morning.  The SPDX online tools will be offline this morning for a few minutes to a few hours depending on how the upgrade goes.

 

My apologies for any inconvenience.

 

Regards,
Gary

 

-------------------------------------------------

Gary O'Neall

Principal Consultant

Source Auditor Inc.

Mobile: 408.805.0586

Email: gary@...

CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.

 


Re: [spdx] - Do we need a SPDX-License-Identifier for full copyright?

Till Jaeger
 

Am 06.04.22 um 10:02 schrieb Matija Šuklje:
Die 6. 04. 22 et hora 01:07 J Lovejoy scripsit:
Or is an empty SPDX-License-Identifier always saying that no license has
been chosen and full copyright applies? We think an empty identifier is
ambiguous and also could mean that no license decision has been made yet
or the license is not listed with SPDX. Or should we discuss to
introduce an "SPDX-License-Identfier: Full Copyright" - whatever this
means at the creator's jurisdiction.
To my understanding of the spec the following should indicate full copyright:

`SPDX-License-Identfier: NONE`

<https://spdx.github.io/spdx-spec/file-information/#85-concluded-license-field>

… but I can agree in practice some ambiguity can creep in, esp. when some
people scan and audit (I’m guilty of this sometimes as well) they might not
bother to apply the license ID to all files that the license applies to, but
failed to mention the license in the file itself.
What about "LicenseRef"?
https://spdx.dev/spdx-specification-21-web-version/#h.1v1yuxt
https://reuse.software/faq/#custom-license

Accordingly, this would be:

# SPDX-License-Identifier: LicenseRef-NoLicense

Could someone clarify what to use?

Best,
Till


Re: [spdx] - Do we need a SPDX-License-Identifier for full copyright?

Matija Šuklje
 

Die 6. 04. 22 et hora 01:07 J Lovejoy scripsit:
Or is an empty SPDX-License-Identifier always saying that no license has
been chosen and full copyright applies? We think an empty identifier is
ambiguous and also could mean that no license decision has been made yet
or the license is not listed with SPDX. Or should we discuss to
introduce an "SPDX-License-Identfier: Full Copyright" - whatever this
means at the creator's jurisdiction.
To my understanding of the spec the following should indicate full copyright:

`SPDX-License-Identfier: NONE`

<https://spdx.github.io/spdx-spec/file-information/#85-concluded-license-field>

… but I can agree in practice some ambiguity can creep in, esp. when some
people scan and audit (I’m guilty of this sometimes as well) they might not
bother to apply the license ID to all files that the license applies to, but
failed to mention the license in the file itself.


cheers,
Matija
--
gsm: tel:+386.41.849.552
www: https://matija.suklje.name
xmpp: matija.suklje@...
matrix: @silverhook:matrix.org

161 - 180 of 3281