Date   

Re: Combined version of LGPL + GPL 3.0

Max Mehl
 

Hi Jilayne,

(Taking out -tech as per earlier request)

~ J Lovejoy [2021-07-28 16:36 +0200]:
Do I understand correctly that FSF still doesn't think of LGPL-3.0 as an
exception to GPL-3.0 (even though functionally and structurally it is)
and thus wants us all now to identify LGPL-3.0 as a conjunctive license
expression, using and?
Yes, that was a suggestion made by Matija in the discussion we've had.
It was turned down by FSF.

What is the implication of just LGPL-3.0 at this point, then? What
happens in terms of backward compatibility for everyone already using
that identifier?

I appreciate you looking into this, but it really would have helped to
be involved.
We didn't think this was so controversial to be honest.

Again, my point of view is that this improves the situation for users,
especially those of REUSE: so far, when adding the LGPL-3.0 license from
SPDX to their repo for LGPL-3.0 licensed code, the license text was
incomplete as it required the GPL-3.0 license to be present as well.
That's unintuitive and would have required special clauses in tooling
like REUSE.

Now, we have a concatenated version. The license effectively did not
change from my perspective, now it's just complete and intuitive. But
IANAL.

Please note that the official LGPL text by FSF has not been altered. The
concatenated version is an alternative format.

As had been discussed here before, LGPL more aptly belongs on the
exceptions list to be used with the WITH operator.
Again, full ack. But my understanding was that SPDX did not want to go
this route as the license steward (FSF) does not consider it an
exception but a separate license.

In any case, any change like this is not inconsequential for existing
users of SPDX and all scenarios need to be fully discussed (as we
learned last time we made a major change in our identifiers for the
FSF). Is this change initiated by REUSE or FSF?
I cannot speak for FSF, just REUSE and the FSFE, REUSE's coordinator.

REUSE obviously does not intent to change SPDX identifiers or cause
compliance issues. I, too, dislike the -only/-or-later special cases,
which is also why my motivation was to get rid of this special case that
two license texts for one license have to be shipped.

I am afraid that compliance issues have been caused *before* this change
as the downloaded LGPL-3.0 license was not complete.

Best,
Max

--
Max Mehl - Programme Manager - Free Software Foundation Europe
Contact and information: https://fsfe.org/about/mehl | @mxmehl
Become a supporter of software freedom: https://fsfe.org/join


Re: Combined version of LGPL + GPL 3.0

J Lovejoy
 

On 7/28/21 4:35 AM, Max Mehl wrote:
Hi Philippe,

(I mistyped the spdx-tech address, fixed here)

~ Philippe Ombredanne [2021-07-28 12:04 +0200]:
On Wed, Jul 28, 2021 at 11:01 AM Max Mehl <max.mehl@...> wrote:
In the scope of REUSE we've noticed [^1] that just providing LPGL-3.0* –
as downloaded from SPDX – in a repo does not suffice as it requires its
mother license, GPL-3.0*. LGPL could be seen as an exception to GPL, but
it's not treated as such by the FSF.

Matija and I discussed that with FSF and the different options we have
to suit SPDX, REUSE and other downstreams. We found a compromise: there
is now an officially acknowledged license text that contains both
LGPL-3.0 and GPL-3.0:

https://www.gnu.org/licenses/lgpl+gpl.txt
Has this been discussed publicly?
The ticket in the reuse-tool is public, the discussions with FSF were
private with John Sullivan and Donald Robertson.
This is a problem. We already went down this road with having back-and-forth conversations with FSF (by way of Richard Stallman and John Sullivan) in 2018 when Richard Stallman wanted us to change the identifiers to be more clear about -only and -or-later. The mode of communication ended up being a mixture of off-list and on-list, which I never was very comfortable with and which made for a lot of extra work. I'm not in favor of repeating that.

If there is something that the FSF, REUSE, or any other community wants addressed related to SPDX identifiers, that conversation needs to begin here - on the open mailing list which anyone can join and for which all the archives are available.

I have copied John and Don on this email directly so they are aware.

I have moved the tech team to bcc - for general awareness, as any such change could impact tooling. Once a conversation is kicked off on this list, we can pull the tech team in at the appropriate time.

Thanks,
Jilayne


Re: Combined version of LGPL + GPL 3.0

J Lovejoy
 

Hi Max,

Do I understand correctly that FSF still doesn't think of LGPL-3.0 as an exception to GPL-3.0 (even though functionally and structurally it is) and thus wants us all now to identify LGPL-3.0 as a conjunctive license expression, using and?

If that is the case, then I don't see what needs to be added to the SPDX License List, as AND works with any two (or more) licenses.

What is the implication of just LGPL-3.0 at this point, then? What happens in terms of backward compatibility for everyone already using that identifier?

I appreciate you looking into this, but it really would have helped to be involved.

As had been discussed here before, LGPL more aptly belongs on the exceptions list to be used with the WITH operator. 

In any case, any change like this is not inconsequential for existing users of SPDX and all scenarios need to be fully discussed (as we learned last time we made a major change in our identifiers for the FSF). Is this change initiated by REUSE or FSF?

Happy to have a chat offline to understand more of the background, if need be, so we can better identify the right path forward.

Thanks,
Jilayne

(have not read other responses yet)



On 7/28/21 3:01 AM, Max Mehl wrote:

Hi all,

In the scope of REUSE we've noticed [^1] that just providing LPGL-3.0* –
as downloaded from SPDX – in a repo does not suffice as it requires its
mother license, GPL-3.0*. LGPL could be seen as an exception to GPL, but
it's not treated as such by the FSF.

Matija and I discussed that with FSF and the different options we have
to suit SPDX, REUSE and other downstreams. We found a compromise: there
is now an officially acknowledged license text that contains both
LGPL-3.0 and GPL-3.0:

  https://www.gnu.org/licenses/lgpl+gpl.txt

Now my request: can we get this combined version into SPDX' license list
data, e.g. [^2]?

Best,
Max


[^1]: https://github.com/fsfe/reuse-tool/issues/86

[^2]: https://github.com/spdx/license-list-data/blob/master/text/LGPL-3.0-or-later.txt



Re: Combined version of LGPL + GPL 3.0

Karsten Klein
 


Re: [spdx-tech] Combined version of LGPL + GPL 3.0

Max Mehl
 

~ Alexios Zavras [2021-07-28 13:09 +0200]:
I think this has nothing to do with spdx-tech and it's probably best addressed by opening a ticket at https://github.com/spdx/license-list-XML/issues.
OK, sorry for including them then.

I think we could have the LGPL-3.0* texts be the current ones plus an optional concatenation of the GPL-3.0 text.

Max, the new combined text does not seem to be referenced in https://www.gnu.org/licenses (yet?). Do you know if they plan to update the page to include a link to it?
They added this as an additional format on the lgpl page (LGPL+GPL):
https://www.gnu.org/licenses/lgpl-3.0.en.html

Best,
Max

--
Max Mehl - Programme Manager - Free Software Foundation Europe
Contact and information: https://fsfe.org/about/mehl | @mxmehl
Become a supporter of software freedom: https://fsfe.org/join


Re: [spdx-tech] Combined version of LGPL + GPL 3.0

Alexios Zavras
 

I think this has nothing to do with spdx-tech and it's probably best addressed by opening a ticket at https://github.com/spdx/license-list-XML/issues.

I think we could have the LGPL-3.0* texts be the current ones plus an optional concatenation of the GPL-3.0 text.

Max, the new combined text does not seem to be referenced in https://www.gnu.org/licenses (yet?). Do you know if they plan to update the page to include a link to it?


-- zvr

-----Original Message-----
From: Spdx-tech@... <Spdx-tech@...> On Behalf Of Max Mehl
Sent: Wednesday, 28 July, 2021 12:35
To: Spdx-legal@...
Cc: SPDX-legal <spdx-legal@...>; spdx-tech@...
Subject: Re: [spdx-tech] Combined version of LGPL + GPL 3.0

Hi Philippe,

(I mistyped the spdx-tech address, fixed here)

~ Philippe Ombredanne [2021-07-28 12:04 +0200]:
On Wed, Jul 28, 2021 at 11:01 AM Max Mehl <max.mehl@...> wrote:
In the scope of REUSE we've noticed [^1] that just providing
LPGL-3.0* – as downloaded from SPDX – in a repo does not suffice as
it requires its mother license, GPL-3.0*. LGPL could be seen as an
exception to GPL, but it's not treated as such by the FSF.

Matija and I discussed that with FSF and the different options we
have to suit SPDX, REUSE and other downstreams. We found a
compromise: there is now an officially acknowledged license text that
contains both
LGPL-3.0 and GPL-3.0:

https://www.gnu.org/licenses/lgpl+gpl.txt
Has this been discussed publicly?
The ticket in the reuse-tool is public, the discussions with FSF were private with John Sullivan and Donald Robertson.

Now my request: can we get this combined version into SPDX' license
list data, e.g. [^2]?
[^1]: https://github.com/fsfe/reuse-tool/issues/86
[^2]:
https://github.com/spdx/license-list-data/blob/master/text/LGPL-3.0-o
r-later.txt
I think that you stated explicitly this is not a new license, just a
clarification (optional one?) that providing both texts when
referencing LGPL-3* is better.
How could one ever handle this sanely in practice? If this is not a
new license, why would you need a new license identifier? If this is a
new license, or a new previsously unstated requirement of the LGPL 3
it would need some wide open and public discussion IMHO.
Sorry if this has been unclear. I do not request a new license identifier but an amendment of the full text version. LGPL-3.0* requires the GPL-3.0 text, and FSF has officially provided a concatenated version.

For SPDX and other downstreams it would just make sense to use the "complete" version IMHO, as it meets users expectations.

Some examples of the new and updated clarity issues this brings:

Say I stumbled on the text at
https://www.gnu.org/licenses/lgpl+gpl.txt in some project... is this
project using the LGPL only or the LGPL and the GPL that apply? It is
impossible to disambiguate which one applies short of a statement by
the authors that they mean the GPL not to apply but that only the LGPL
should be considered there and that the GPL text is there only for
reference.
The top of the file quite clearly states that this is about the LGPL.

But of course, just from this text it's unclear how the actual code is licensed, but that's a common problem in repos using multiple licenses.
That's why SPDX license identifiers make a lot of sense, and also why the REUSE way of storing license texts is so useful.

It's very clear if you store the above license text under `LICENSES/LGPL-3.0-or-later.txt` and mark the files with
`SPDX-License-Identifier: LGPL-3.0-or-later`.

What if a project contains both GPL3 and LGPL 3-licensed code? They
could use the exact same text as above and I would still not be able
to disambiguate short of extra statements.
Well, in the example above, that wouldn't be any problem. You can have both GPL and LGPL licensed code in your repo, and by using SPDX expressions you can even dual-license selected files if you wanted.
Again, just by having a LICENSE file things are ambiguous anyway.

And what's the alternative for LGPL-3.0? Just using the text that SPDX provides currently is not compliant as the license requires the GPL-3.0 to be present. What changed now is that there is an official upstream combined version, so SPDX should use it.

Now say the author added a license identifier in the code saying that
this is "LGPL-3.0-only"... did they forget to reference the GPL text
in the combined text above? Or is this really just LGPL? Or is some
part of the code GPL-licensed but not marked as such? I cannot say for
sure either and I would not trust that. I still need some more
explicit statements to get clarity.

IMHO the status of the LGPL as a self standing text or whether it
needs to be accompanied by the GPL text has been a jolly mess of
ambiguity since the release of the L/GPL3*.

I cannot see how the FSF releasing a text that combines two texts
makes it any better, to the contrary: it just adds even more ambiguity
and confusion. Even more so if there has been no public discussion on
the topic.

I cannot fathom how this kind of confusion, uncertainty and doubt is
helpful to anyone producing or consuming LGPL-licensed code.
I get your point, and it's also not the most ideal outcome, but as written above I think the situation improved.

And of course we need explicit statements, and thanks to the combination of SPDX and REUSE that's a common best practice.

Best,
Max

--
Max Mehl - Programme Manager - Free Software Foundation Europe Contact and information: https://fsfe.org/about/mehl | @mxmehl Become a supporter of software freedom: https://fsfe.org/join





Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928


Re: Combined version of LGPL + GPL 3.0

Max Mehl
 

Hi Philippe,

(I mistyped the spdx-tech address, fixed here)

~ Philippe Ombredanne [2021-07-28 12:04 +0200]:
On Wed, Jul 28, 2021 at 11:01 AM Max Mehl <max.mehl@...> wrote:
In the scope of REUSE we've noticed [^1] that just providing LPGL-3.0* –
as downloaded from SPDX – in a repo does not suffice as it requires its
mother license, GPL-3.0*. LGPL could be seen as an exception to GPL, but
it's not treated as such by the FSF.

Matija and I discussed that with FSF and the different options we have
to suit SPDX, REUSE and other downstreams. We found a compromise: there
is now an officially acknowledged license text that contains both
LGPL-3.0 and GPL-3.0:

https://www.gnu.org/licenses/lgpl+gpl.txt
Has this been discussed publicly?
The ticket in the reuse-tool is public, the discussions with FSF were
private with John Sullivan and Donald Robertson.

Now my request: can we get this combined version into SPDX' license list
data, e.g. [^2]?
[^1]: https://github.com/fsfe/reuse-tool/issues/86
[^2]: https://github.com/spdx/license-list-data/blob/master/text/LGPL-3.0-or-later.txt
I think that you stated explicitly this is not a new license, just a
clarification (optional one?) that providing both texts when
referencing LGPL-3* is better.
How could one ever handle this sanely in practice? If this is not a
new license, why would you need a new license identifier? If this is a
new license, or a new previsously unstated requirement of the LGPL 3
it would need some wide open and public discussion IMHO.
Sorry if this has been unclear. I do not request a new license
identifier but an amendment of the full text version. LGPL-3.0* requires
the GPL-3.0 text, and FSF has officially provided a concatenated
version.

For SPDX and other downstreams it would just make sense to use the
"complete" version IMHO, as it meets users expectations.

Some examples of the new and updated clarity issues this brings:

Say I stumbled on the text at
https://www.gnu.org/licenses/lgpl+gpl.txt in some project... is this
project using the LGPL only or the LGPL and the GPL that apply? It is
impossible to disambiguate which one applies short of a statement by
the authors that they mean the GPL not to apply but that only the LGPL
should be considered there and that the GPL text is there only for
reference.
The top of the file quite clearly states that this is about the LGPL.

But of course, just from this text it's unclear how the actual code is
licensed, but that's a common problem in repos using multiple licenses.
That's why SPDX license identifiers make a lot of sense, and also why
the REUSE way of storing license texts is so useful.

It's very clear if you store the above license text under
`LICENSES/LGPL-3.0-or-later.txt` and mark the files with
`SPDX-License-Identifier: LGPL-3.0-or-later`.

What if a project contains both GPL3 and LGPL 3-licensed code? They
could use the exact same text as above and I would still not be able
to disambiguate short of extra statements.
Well, in the example above, that wouldn't be any problem. You can have
both GPL and LGPL licensed code in your repo, and by using SPDX
expressions you can even dual-license selected files if you wanted.
Again, just by having a LICENSE file things are ambiguous anyway.

And what's the alternative for LGPL-3.0? Just using the text that SPDX
provides currently is not compliant as the license requires the GPL-3.0
to be present. What changed now is that there is an official upstream
combined version, so SPDX should use it.

Now say the author added a license identifier in the code saying that
this is "LGPL-3.0-only"... did they forget to reference the GPL text
in the combined text above? Or is this really just LGPL? Or is some
part of the code GPL-licensed but not marked as such? I cannot say for
sure either and I would not trust that. I still need some more
explicit statements to get clarity.

IMHO the status of the LGPL as a self standing text or whether it
needs to be accompanied by the GPL text has been a jolly mess of
ambiguity since the release of the L/GPL3*.

I cannot see how the FSF releasing a text that combines two texts
makes it any better, to the contrary: it just adds even more ambiguity
and confusion. Even more so if there has been no public discussion on
the topic.

I cannot fathom how this kind of confusion, uncertainty and doubt is
helpful to anyone producing or consuming LGPL-licensed code.
I get your point, and it's also not the most ideal outcome, but as
written above I think the situation improved.

And of course we need explicit statements, and thanks to the combination
of SPDX and REUSE that's a common best practice.

Best,
Max

--
Max Mehl - Programme Manager - Free Software Foundation Europe
Contact and information: https://fsfe.org/about/mehl | @mxmehl
Become a supporter of software freedom: https://fsfe.org/join


Re: Combined version of LGPL + GPL 3.0

Philippe Ombredanne
 

Hey Max,
You wrote:

On Wed, Jul 28, 2021 at 11:01 AM Max Mehl <max.mehl@...> wrote:
In the scope of REUSE we've noticed [^1] that just providing LPGL-3.0* –
as downloaded from SPDX – in a repo does not suffice as it requires its
mother license, GPL-3.0*. LGPL could be seen as an exception to GPL, but
it's not treated as such by the FSF.

Matija and I discussed that with FSF and the different options we have
to suit SPDX, REUSE and other downstreams. We found a compromise: there
is now an officially acknowledged license text that contains both
LGPL-3.0 and GPL-3.0:

https://www.gnu.org/licenses/lgpl+gpl.txt
Has this been discussed publicly?

Now my request: can we get this combined version into SPDX' license list
data, e.g. [^2]?
[^1]: https://github.com/fsfe/reuse-tool/issues/86
[^2]: https://github.com/spdx/license-list-data/blob/master/text/LGPL-3.0-or-later.txt
I think that you stated explicitly this is not a new license, just a
clarification (optional one?) that providing both texts when
referencing LGPL-3* is better.
How could one ever handle this sanely in practice? If this is not a
new license, why would you need a new license identifier? If this is a
new license, or a new previsously unstated requirement of the LGPL 3
it would need some wide open and public discussion IMHO.

Some examples of the new and updated clarity issues this brings:

Say I stumbled on the text at
https://www.gnu.org/licenses/lgpl+gpl.txt in some project... is this
project using the LGPL only or the LGPL and the GPL that apply? It is
impossible to disambiguate which one applies short of a statement by
the authors that they mean the GPL not to apply but that only the LGPL
should be considered there and that the GPL text is there only for
reference.

What if a project contains both GPL3 and LGPL 3-licensed code? They
could use the exact same text as above and I would still not be able
to disambiguate short of extra statements.

Now say the author added a license identifier in the code saying that
this is "LGPL-3.0-only"... did they forget to reference the GPL text
in the combined text above? Or is this really just LGPL? Or is some
part of the code GPL-licensed but not marked as such? I cannot say for
sure either and I would not trust that. I still need some more
explicit statements to get clarity.

IMHO the status of the LGPL as a self standing text or whether it
needs to be accompanied by the GPL text has been a jolly mess of
ambiguity since the release of the L/GPL3*.

I cannot see how the FSF releasing a text that combines two texts
makes it any better, to the contrary: it just adds even more ambiguity
and confusion. Even more so if there has been no public discussion on
the topic.

I cannot fathom how this kind of confusion, uncertainty and doubt is
helpful to anyone producing or consuming LGPL-licensed code.

--
Cordially
Philippe Ombredanne


Combined version of LGPL + GPL 3.0

Max Mehl
 

Hi all,

In the scope of REUSE we've noticed [^1] that just providing LPGL-3.0* –
as downloaded from SPDX – in a repo does not suffice as it requires its
mother license, GPL-3.0*. LGPL could be seen as an exception to GPL, but
it's not treated as such by the FSF.

Matija and I discussed that with FSF and the different options we have
to suit SPDX, REUSE and other downstreams. We found a compromise: there
is now an officially acknowledged license text that contains both
LGPL-3.0 and GPL-3.0:

https://www.gnu.org/licenses/lgpl+gpl.txt

Now my request: can we get this combined version into SPDX' license list
data, e.g. [^2]?

Best,
Max


[^1]: https://github.com/fsfe/reuse-tool/issues/86

[^2]: https://github.com/spdx/license-list-data/blob/master/text/LGPL-3.0-or-later.txt

--
Max Mehl - Programme Manager - Free Software Foundation Europe
Contact and information: https://fsfe.org/about/mehl | @mxmehl
Become a supporter of software freedom: https://fsfe.org/join


proposal for Fedora to start using SPDX identifiers

J Lovejoy
 

Hi SPDX-legal,

I've been chatting to some of the Fedora folks about adopting the use of SPDX license identifiers in its package spec files. I just posted a comment/ proposal to a PR that was opened some time ago, See  https://pagure.io/packaging-committee/pull-request/971#

As some of you may remember, SPDX-legal undertook adding many licenses on the Fedora Good list back in 2013-14 time frame. I have since looked at the current Fedora Good list and updated a comparison doc, see: https://docs.google.com/spreadsheets/d/1fi5SVzyCAL0UDravvkS6Us4lFwRiQy-l3qTUEkY92U0/edit#gid=243613621

The good news is that the vast majority (~80%) of the Fedora Good licenses can already be represented with SPDX identifiers or expressions. Research will be needed for Fedora licenses that are not on the SPDX License List and we will likely see some additional requests for new licenses.

For any of you who are here and Fedora enthusiasts, help with researching some of the licenses and (eventually) updating existing Fedora package license info once this all moves forward would be greatly appreciated. It would also be good to think about ways to collaborate into ways to automate any cross-functional processes going forward so that we stay in sync.

Ideas there are greatly welcome!  Stay tuned!

Jilayne


meeting today

J Lovejoy
 

Hi all,

We have our regular meeting today at 10am mountain time via https://meet.jit.si/SPDXLegalMeeting

We will focus on what can  be wrapped up for the 3.14 release at the end of this month!

Thanks,
Jilayne


Invitation: SPDX legal team meeting - 2021 updated @ Every 2 weeks from 12pm to 1pm on Thursday from Thu Jun 10 to Sat Jan 1, 2022 (EDT) (spdx-legal@lists.spdx.org)

Steve Winslow
 

You have been invited to the following event.

SPDX legal team meeting - 2021 updated

When
Every 2 weeks from 12pm to 1pm on Thursday from Thu Jun 10 to Sat Jan 1, 2022 Eastern Time - New York
Where
https://meet.jit.si/SPDXLegalMeeting (map)
Calendar
spdx-legal@...
Who
swinslow@... - organizer
spdx-legal@...

Going (spdx-legal@...)?   All events in this series:   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account spdx-legal@... because you are an attendee of this event.

To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar.

Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More.


Licensing regarding SPDX CC-By-3.0 output

relaysignal@...
 

Hello all, I had a quick question or two. I hope this is the right place to ask.

I am using the License Checker plugin to build a JSON list of all licenses in my React/Gatsby project.
This plugin uses a number of SPDX-adjacent plugins to basically loop through each folder in "node_modules" and check the package.json file's SPDX license against a SPDX list of some sort.
As far as I can tell, the outputted JSON from License Checker never grabs any information directly from SPDX, but merely verifies that, say the package's license "MIT" matches the SPDX identifier "MIT".

The only SPDX licensing I can see is from the SPDX-Exceptions, SPDX Expression Parse, and SPDX-Ranges packages where the SPDX information is licensed under Creative Commons Attribution License 3.0 Unported (SPDX: "CC-BY-3.0"). The other plugins, such as SPDX Satisfies, do not mention SPDX's licensing.

My questions are:
  • Since this implementation of the SPDX material seems to be "server-side" and not outputted in the JSON or included as JS files, do I need to attribute SPDX in a public webpage?
  • If I need to attribute SPDX, if I have done so already but did not include a link to SPDX and the material title (as per CC-BY-3.0) is my license terminated?
  • Is "SPDX is Copyright © 2010-2015 Linux Foundation and its Contributors. Licensed under the Creative Commons Attribution License 3.0 Unported. All other rights are expressly reserved." a valid enough attribution line?

Thank you!


Invitation: SPDX Legal team meeting @ Thu May 27, 2021 12pm - 1pm (EDT) (spdx-legal@lists.spdx.org)

Steve Winslow
 

You have been invited to the following event.

SPDX Legal team meeting

When
Thu May 27, 2021 12pm – 1pm Eastern Time - New York
Where
https://meet.jit.si/SPDXLegalMeeting (map)
Calendar
spdx-legal@...
Who
swinslow@... - organizer
spdx-legal@...

Going (spdx-legal@...)?   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account spdx-legal@... because you are an attendee of this event.

To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar.

Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More.


Re: License list 3.13 release status update

Steve Winslow
 

A quick update to note that the issues in the license list publisher have been resolved. Many thanks as always to Gary O'Neall for helping to address this today!

Version 3.13 of the SPDX License List has now been tagged in the license-list-data repo at https://github.com/spdx/license-list-data/releases/tag/v3.13, and published to the SPDX website at https://spdx.org/licenses.

Best,
Steve


On Thu, May 20, 2021 at 10:06 AM Steve Winslow <swinslow@...> wrote:
Hello spdx-legal list,

I wanted to share a quick update on the version 3.13 release of the SPDX License List.

We have tagged and pushed the 3.13 release in the license-list-XML repo. [1] However, an issue has come up with the license list publisher automation that carries the tagged / released version info over into the license-list-data repo [2], which is where the ready-for-publication formats of the license list are updated before being uploaded to the main website. [3]

I'm working with the SPDX tech team to resolve this, and the 3.13 license list will be published to the website once this is resolved. I'll follow up with an email to this list after it is live.

Best,
Steve


--
Steve Winslow
VP, Compliance and Legal
The Linux Foundation


--
Steve Winslow
VP, Compliance and Legal
The Linux Foundation


License list 3.13 release status update

Steve Winslow
 

Hello spdx-legal list,

I wanted to share a quick update on the version 3.13 release of the SPDX License List.

We have tagged and pushed the 3.13 release in the license-list-XML repo. [1] However, an issue has come up with the license list publisher automation that carries the tagged / released version info over into the license-list-data repo [2], which is where the ready-for-publication formats of the license list are updated before being uploaded to the main website. [3]

I'm working with the SPDX tech team to resolve this, and the 3.13 license list will be published to the website once this is resolved. I'll follow up with an email to this list after it is live.

Best,
Steve


--
Steve Winslow
VP, Compliance and Legal
The Linux Foundation


Re: Meeting today, May 13

Jonas Smedegaard
 

Quoting J Lovejoy (2021-05-13 17:56:55)
Is using the phone dial-in still objectionable or not an option? Just
wondering.
Not acceptable to me, sorry. Thanks for asking.

To clarify, it is not that I can't but that I won't:

I want progress in the areas of Free software, Open Source Hardware,
Open standards, and federated networking. In situations where there is
a reasonable choice, I insist on using those.

I find it reasonably possible - i.e. easily available and easily usable
- to use Free software and Open standards for realtime A/V meetings, so
I respectfully decline to use non-free or closed-protocol alternatives.


See you on the other side... :-)


- Jonas

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

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


Re: Meeting today, May 13

J Lovejoy
 

Jonas,

Is using the phone dial-in still objectionable or not an option? Just wondering.

Thanks!
Jilayne

On 5/13/21 8:38 AM, Jonas Smedegaard wrote:

Quoting Steve Winslow (2021-05-13 16:08:57)
We will use the same Zoom link as previously for today's meeting, but 
I expect to be changing it to Jitsi for future meetings.
I won't use Zoom, so will look forward to the switch to Jitsi.

Enjoy the meeting,

 - Jonas



Re: Meeting today, May 13

Jonas Smedegaard
 

Quoting Steve Winslow (2021-05-13 16:08:57)
We will use the same Zoom link as previously for today's meeting, but
I expect to be changing it to Jitsi for future meetings.
I won't use Zoom, so will look forward to the switch to Jitsi.

Enjoy the meeting,

- Jonas

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

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


Meeting today, May 13

Steve Winslow
 

Hello SPDX legal team,

The next regularly-scheduled SPDX legal team meeting will be today, Thursday, May 13, at 9AM PDT / noon EDT.

For today's call, we will be finalizing a last couple issues for 3.13 before I push the release shortly, and then turning to 3.14 issues.

We will use the same Zoom link as previously for today's meeting, but I expect to be changing it to Jitsi for future meetings.

Best,
Steve

= = = = =


One tap mobile
+13126266799,,93441586616# US (Chicago)
+16465588656,,93441586616# US (New York)

Dial by your location
        +1 312 626 6799 US (Chicago)
        +1 646 558 8656 US (New York)
        +1 301 715 8592 US (Washington D.C)
        +1 346 248 7799 US (Houston)
        +1 669 900 6833 US (San Jose)
        +1 253 215 8782 US (Tacoma)
        855 880 1246 US Toll-free
        877 369 0926 US Toll-free
        +1 647 558 0588 Canada
        +1 778 907 2071 Canada
        +1 204 272 7920 Canada
        +1 438 809 7799 Canada
        +1 587 328 1099 Canada
        +1 647 374 4685 Canada
        855 703 8985 Canada Toll-free
Meeting ID: 934 4158 6616
Find your local number: https://zoom.us/u/aBKeucSql


--
Steve Winslow
VP, Compliance and Legal
The Linux Foundation

321 - 340 of 3278