Date   

FW: Invalid SPDX identifier in Linux source tree

Mark Atwood (Amazon.com)
 

I just got this note from one of my developers.

 

Is he correct? Should we or someone send a patch to Linux project?

 

..m

 

 

From: REDACTED

Sent: Tuesday, May 5, 2020 8:26 AM
To: Atwood, Mark <atwoodm@...>
Subject: Invalid SPDX identifier in Linux source tree

 

Mark,

Sorry for the delay, I'm long overdue in forwarding this to you.

https://github.com/torvalds/linux/blob/master/include/uapi/linux/i2c-dev.h

Contains the following invalid SPDX identifier:

/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */


The SPDX list of license identifiers (https://spdx.org/licenses/) does not include GPL-2.0+ in any form.  The closest would (presumably) be GPL-2.0-or-later.

---

 


License list - 3.9 timing update and pending issues

Steve Winslow
 

Hello spdx-legal list,

In light of the upcoming updates to the SPDX website hosting, we are pushing back the release date for the 3.9 license list by two weeks. We are now targeting the release for May 15, with an end date for new PRs targeted for May 10.

This also gives folks a bit more time to get in reviews / feedback on whether particular license requests should be approved, and to prepare PRs for approved requests. I expect that the next legal team call on May 7 will be the close-out or push-to-3.10 decision point for all remaining 3.9 issues.

In light of that, I'd encourage folks to review the list of open issues for 3.9, available at:

Comments in the issues threads are welcome, and even simple "+1" notes are helpful if you are in favor of adding a proposed license under the updated license inclusion guidelines [1].

In particular, I'd like to highlight a few requests for new open hardware and source available licenses. Feedback for these in the issue threads would be particularly welcome, to see if there is consensus for whether to add them for 3.9 in light of the updated guidelines:

1) CERN-OHL-2.0-S -- https://github.com/spdx/license-list-XML/issues/1011 and two variants linked from that issue as well. Noting significant support from the open hardware community as indicated in https://github.com/spdx/license-list-XML/pull/1015, and would like to get some additional thumbs-up from other SPDX reviewers to get this one in.


3) BUSL-1.1 (Business Source License) -- https://github.com/spdx/license-list-XML/issues/995

Best,
Steve



--
Steve Winslow
Director of Strategic Programs
The Linux Foundation


Re: I know you're probably tired of talking about the Python license, but...

Armijn Hemel - Tjaldur Software Governance Solutions
 

hello,

Hi all, I'm Mary, long time lurker. 
I searched the wiki, the meeting minutes, and messages, but I couldn't find an answer to my question. Sorry if it is a repeat. 

My problem is not with the ancient Python versions, or the stacked licenses listed for 2.0+. It's a matching guidelines issue for the Python-2.0 license text.
PSF lists its version numbers inside the license text, and the SPDX matching guidelines don't say specifically that I can ignore them, though I want to. There is also a slight change in wording (bold, below), and additional copyright years in clause 2, but not substantive differences. However, I follow the license list and the matching guidelines very strictly. 

SPDX License list Python-2.0 says: 
1. This LICENSE AGREEMENT is between the Python Software Foundation ("PSF"), and the Individual or Organization ("Licensee") accessing and otherwise using this software ("Python") in source or binary form and its associated documentation.

More recent (since 2001, wow) PSF license statements include whichever version inside the license text found in source code files, most recent one for example:
1. This LICENSE AGREEMENT is between the Python Software Foundation ("PSF"), and the Individual or Organization ("Licensee") accessing and otherwise using Python 3.8.2 software in source or binary form and its associated documentation.


I downloaded the 3.8.2 release from python.org and this only seems to be true for one variant of the license text that is used in the PC version of Python:


https://github.com/python/cpython/blob/master/PC/store_info.txt#L101

and *not* in the main license file in the source code. It is also on the website: https://docs.python.org/3.9/license.html

I did find that there are a few variants out there that are possibly not covered:

https://github.com/python/cpython/blob/master/LICENSE

(years around line 75)


https://github.com/python/cpython/blob/master/Doc/license.rst


(different years again)

So basically they have three different license variants in their code base, sigh...


armijn
-- 
Armijn Hemel, MSc
Tjaldur Software Governance Solutions


I know you're probably tired of talking about the Python license, but...

mhardy@...
 

Hi all, I'm Mary, long time lurker. 
I searched the wiki, the meeting minutes, and messages, but I couldn't find an answer to my question. Sorry if it is a repeat. 

My problem is not with the ancient Python versions, or the stacked licenses listed for 2.0+. It's a matching guidelines issue for the Python-2.0 license text.
PSF lists its version numbers inside the license text, and the SPDX matching guidelines don't say specifically that I can ignore them, though I want to. There is also a slight change in wording (bold, below), and additional copyright years in clause 2, but not substantive differences. However, I follow the license list and the matching guidelines very strictly. 

SPDX License list Python-2.0 says: 
1. This LICENSE AGREEMENT is between the Python Software Foundation ("PSF"), and the Individual or Organization ("Licensee") accessing and otherwise using this software ("Python") in source or binary form and its associated documentation.

More recent (since 2001, wow) PSF license statements include whichever version inside the license text found in source code files, most recent one for example:
1. This LICENSE AGREEMENT is between the Python Software Foundation ("PSF"), and the Individual or Organization ("Licensee") accessing and otherwise using Python 3.8.2 software in source or binary form and its associated documentation.

The matching guidelines say: Text that can be considered omitable for matching purposes is indicated in the SPDX License List template with mark-up and in the corresponding HTML pages with colored text.

Is this the kind of variation that fits within the matching guidelines? Or, do we simply need to update the SPDX entry for Python-2.0 with colored text so it can flex on these minor changes across the modern versions? The old licenses in the stack aren't going to change, so it seems like an easy fix.

This isn't just a version 3 thing, I have seen this on v2.4 files recently.

If this has already been planned for the next license list update, I apologize. I may have missed it in the meeting minutes.

Thank you! Mary


Re: documentation/examples of License Ref?

Luis Villa
 

Thanks, Steve and Kyle. The link to the draft is particularly helpful.

I don't want to rehash the many, many discussions about which licenses should be included in the official list; suffice to say, are there any best practices folks here are aware of for naming these? I saw https://github.com/nexB/scancode-toolkit/issues/532 re namespacing but that's about it.


On Fri, Apr 17, 2020 at 9:46 AM Steve Winslow <swinslow@...> wrote:
Hi Luis, hope you (and others) are staying safe and healthy as well.

Echoing Kyle, "LicenseRef-" is part of the spec syntax and is defined in Appendix IV of the spec. [1] In an actual SPDX document, it would be defined in a corresponding "Other License" section. [2]

In the v2.2 release of the spec (for which a release candidate was circulated this morning), the spec now explicitly clarifies that LicenseRefs can be used in short-form identifiers in source code. [3] REUSE has also implemented this in their spec and described a mechanism for including the corresponding license text directly in a repo.

Hope this helps!
Steve

(links below are to sections of the v2.2 release candidate)

[4] https://reuse.software/spec/, search for "LicenseRef"

On Fri, Apr 17, 2020 at 12:39 PM Kyle Mitchell <kyle@...> wrote:
Luis,

`LicenseRef-*` is technically part of the license expression
syntax, too.  But it mostly comes up in the context of
(private, shared) SPDX XML files.  I'm not aware of any
package managers that leverage it as a way for package
authors to express their own license terms.

--
Kyle Mitchell, attorney // Oakland // (510) 712 - 0933





--
Steve Winslow
Director of Strategic Programs
The Linux Foundation


Re: documentation/examples of License Ref?

Gary O'Neall
 

Hi Richard,

Here are some minutes from a previous review mentioning a potential long term solution for non-listed exceptions: https://wiki.spdx.org/view/Legal_Team/Archive/license_expression_syntax

I also recall a discussion on the topic. It has been a while (and my memory is far from perfect), but I recall the conclusion being not to introduces such a construct at the time due to the additional complexity and the assumption that any non-listed exception text would require a similar level of manual review as reviewing the full LicenseRef.

Gary

-----Original Message-----
From: Spdx-legal@... <Spdx-legal@...> On Behalf Of
Richard Fontana
Sent: Friday, April 24, 2020 2:08 PM
To: spdx-legal@...
Subject: Re: documentation/examples of License Ref?

If you have a standard license text (that maps to one of the SPDX license
identifiers) coupled with some additional nonstandardized terms, which are not
captured by anything in the exceptions list (which IIRC are not supposed to
cover supplementary restrictive terms anyway, though I seem to remember a
debate many years ago about that topic), would the only SPDX-sanctioned way
of expressing this be to use a LicenseRef for the whole expression? For
example, suppose you have a project that says it's licensed under GPL version 2
along with an attribution-like requirement for web services (this is a real case I
was pointed to today, see:
https://github.com/drwetter/testssl.sh/blob/3.0.1/Readme.md#license )

To represent that in SPDX notation, I assume you wouldn't refer to "GPL-2.0"
unless you prefixed it with a LicenseRef, something like LicenseRef-GPL-2.0-
Web-Services-Attribution
where "GPL-2.0" doesn't particularly have any precise connection to the SPDX
GPL-2.0 identifier, but might have the benefit of communicating to humans
that the license in question here is, in part, textually-intact GPL version 2.

This is a common enough case, though, that I wonder if there is some value to
having a way of representing it in an SPDX expression that uses the official
SPDX identifier in an official sort of way, not prefixed by LicenseRef. Maybe
you'd have to define a new operator and perhaps SPDX wouldn't want to go
down that road. I assume from reading the spec that LicenseRef can't be used
inside an expression to cover just the identifier that follows the WITH operator.

Richard

On Fri, Apr 17, 2020 at 12:49 PM Steve Winslow
<swinslow@...> wrote:

Hi Luis, hope you (and others) are staying safe and healthy as well.

Echoing Kyle, "LicenseRef-" is part of the spec syntax and is defined
in Appendix IV of the spec. [1] In an actual SPDX document, it would
be defined in a corresponding "Other License" section. [2]

In the v2.2 release of the spec (for which a release candidate was circulated
this morning), the spec now explicitly clarifies that LicenseRefs can be used in
short-form identifiers in source code. [3] REUSE has also implemented this in
their spec and described a mechanism for including the corresponding license
text directly in a repo.

Hope this helps!
Steve

(links below are to sections of the v2.2 release candidate)

[1]
https://spdx.github.io/spdx-spec/v2-draft/appendix-IV-SPDX-license-exp
ressions/ [2]
https://spdx.github.io/spdx-spec/v2-draft/6-other-licensing-informatio
n-detected/ [3]
https://spdx.github.io/spdx-spec/v2-draft/appendix-V-using-SPDX-short-
identifiers-in-source-files/, scroll to the bottom [4]
https://reuse.software/spec/, search for "LicenseRef"

On Fri, Apr 17, 2020 at 12:39 PM Kyle Mitchell <kyle@...> wrote:

Luis,

`LicenseRef-*` is technically part of the license expression syntax,
too. But it mostly comes up in the context of (private, shared) SPDX
XML files. I'm not aware of any package managers that leverage it as
a way for package authors to express their own license terms.

--
Kyle Mitchell, attorney // Oakland // (510) 712 - 0933



--
Steve Winslow
Director of Strategic Programs
The Linux Foundation
swinslow@...


--
Richard Fontana
Senior Commercial Counsel
Red Hat, Inc.
+1 212 689-4350 (mobile)



Re: documentation/examples of License Ref?

Steve Winslow
 

Hi Richard,

Thanks for this -- all good points and I agree, in the example you gave I'd represent it in the way you described.

As an FYI, regarding custom exceptions (and agreed that the example you gave wouldn't fit into the "exception list" category) -- there is an open issue for consideration in the 3.0 version of the SPDX spec, to add "ExceptionRef-" syntax that would explicitly permit custom exceptions to be used after WITH in SPDX license expressions. See https://github.com/spdx/spdx-spec/issues/153 and feel free to weigh in with thoughts  :)

Steve


On Fri, Apr 24, 2020 at 5:08 PM Richard Fontana <rfontana@...> wrote:
If you have a standard license text (that maps to one of the SPDX
license identifiers) coupled with some additional nonstandardized
terms, which are not captured by anything in the exceptions list
(which IIRC are not supposed to cover supplementary restrictive terms
anyway, though I seem to remember a debate many years ago about that
topic), would the only SPDX-sanctioned way of expressing this be to
use a LicenseRef for the whole expression? For example, suppose you
have a project that says it's licensed under GPL version 2 along with
an attribution-like requirement for web services (this is a real case
I was pointed to today, see:
https://github.com/drwetter/testssl.sh/blob/3.0.1/Readme.md#license )

To represent that in SPDX notation, I assume you wouldn't refer to
"GPL-2.0" unless you prefixed it with a LicenseRef, something like
LicenseRef-GPL-2.0-Web-Services-Attribution
where "GPL-2.0" doesn't particularly have any precise connection to
the SPDX GPL-2.0 identifier, but might have the benefit of
communicating to humans that the license in question here is, in part,
textually-intact GPL version 2.

This is a common enough case, though, that I wonder if there is some
value to having a way of representing it in an SPDX expression that
uses the official SPDX identifier in an official sort of way, not
prefixed by LicenseRef. Maybe you'd have to define a new operator and
perhaps SPDX wouldn't want to go down that road. I assume from reading
the spec that LicenseRef can't be used inside an expression to cover
just the identifier that follows the WITH operator.

Richard

On Fri, Apr 17, 2020 at 12:49 PM Steve Winslow
<swinslow@...> wrote:
>
> Hi Luis, hope you (and others) are staying safe and healthy as well.
>
> Echoing Kyle, "LicenseRef-" is part of the spec syntax and is defined in Appendix IV of the spec. [1] In an actual SPDX document, it would be defined in a corresponding "Other License" section. [2]
>
> In the v2.2 release of the spec (for which a release candidate was circulated this morning), the spec now explicitly clarifies that LicenseRefs can be used in short-form identifiers in source code. [3] REUSE has also implemented this in their spec and described a mechanism for including the corresponding license text directly in a repo.
>
> Hope this helps!
> Steve
>
> (links below are to sections of the v2.2 release candidate)
>
> [1] https://spdx.github.io/spdx-spec/v2-draft/appendix-IV-SPDX-license-expressions/
> [2] https://spdx.github.io/spdx-spec/v2-draft/6-other-licensing-information-detected/
> [3] https://spdx.github.io/spdx-spec/v2-draft/appendix-V-using-SPDX-short-identifiers-in-source-files/, scroll to the bottom
> [4] https://reuse.software/spec/, search for "LicenseRef"
>
> On Fri, Apr 17, 2020 at 12:39 PM Kyle Mitchell <kyle@...> wrote:
>>
>> Luis,
>>
>> `LicenseRef-*` is technically part of the license expression
>> syntax, too.  But it mostly comes up in the context of
>> (private, shared) SPDX XML files.  I'm not aware of any
>> package managers that leverage it as a way for package
>> authors to express their own license terms.
>>
>> --
>> Kyle Mitchell, attorney // Oakland // (510) 712 - 0933
>>
>>
>>
>
>
> --
> Steve Winslow
> Director of Strategic Programs
> The Linux Foundation
> swinslow@...
>



--
Richard Fontana
Senior Commercial Counsel
Red Hat, Inc.
+1 212 689-4350 (mobile)






--
Steve Winslow
Director of Strategic Programs
The Linux Foundation


Re: documentation/examples of License Ref?

Richard Fontana
 

If you have a standard license text (that maps to one of the SPDX
license identifiers) coupled with some additional nonstandardized
terms, which are not captured by anything in the exceptions list
(which IIRC are not supposed to cover supplementary restrictive terms
anyway, though I seem to remember a debate many years ago about that
topic), would the only SPDX-sanctioned way of expressing this be to
use a LicenseRef for the whole expression? For example, suppose you
have a project that says it's licensed under GPL version 2 along with
an attribution-like requirement for web services (this is a real case
I was pointed to today, see:
https://github.com/drwetter/testssl.sh/blob/3.0.1/Readme.md#license )

To represent that in SPDX notation, I assume you wouldn't refer to
"GPL-2.0" unless you prefixed it with a LicenseRef, something like
LicenseRef-GPL-2.0-Web-Services-Attribution
where "GPL-2.0" doesn't particularly have any precise connection to
the SPDX GPL-2.0 identifier, but might have the benefit of
communicating to humans that the license in question here is, in part,
textually-intact GPL version 2.

This is a common enough case, though, that I wonder if there is some
value to having a way of representing it in an SPDX expression that
uses the official SPDX identifier in an official sort of way, not
prefixed by LicenseRef. Maybe you'd have to define a new operator and
perhaps SPDX wouldn't want to go down that road. I assume from reading
the spec that LicenseRef can't be used inside an expression to cover
just the identifier that follows the WITH operator.

Richard

On Fri, Apr 17, 2020 at 12:49 PM Steve Winslow
<swinslow@...> wrote:

Hi Luis, hope you (and others) are staying safe and healthy as well.

Echoing Kyle, "LicenseRef-" is part of the spec syntax and is defined in Appendix IV of the spec. [1] In an actual SPDX document, it would be defined in a corresponding "Other License" section. [2]

In the v2.2 release of the spec (for which a release candidate was circulated this morning), the spec now explicitly clarifies that LicenseRefs can be used in short-form identifiers in source code. [3] REUSE has also implemented this in their spec and described a mechanism for including the corresponding license text directly in a repo.

Hope this helps!
Steve

(links below are to sections of the v2.2 release candidate)

[1] https://spdx.github.io/spdx-spec/v2-draft/appendix-IV-SPDX-license-expressions/
[2] https://spdx.github.io/spdx-spec/v2-draft/6-other-licensing-information-detected/
[3] https://spdx.github.io/spdx-spec/v2-draft/appendix-V-using-SPDX-short-identifiers-in-source-files/, scroll to the bottom
[4] https://reuse.software/spec/, search for "LicenseRef"

On Fri, Apr 17, 2020 at 12:39 PM Kyle Mitchell <kyle@...> wrote:

Luis,

`LicenseRef-*` is technically part of the license expression
syntax, too. But it mostly comes up in the context of
(private, shared) SPDX XML files. I'm not aware of any
package managers that leverage it as a way for package
authors to express their own license terms.

--
Kyle Mitchell, attorney // Oakland // (510) 712 - 0933



--
Steve Winslow
Director of Strategic Programs
The Linux Foundation
swinslow@...


--
Richard Fontana
Senior Commercial Counsel
Red Hat, Inc.
+1 212 689-4350 (mobile)


Re: CERN-OHL

Steve Winslow
 

Hello Andrew,

Thanks for submitting these three for consideration. If you're available to join today, you're of course welcome, though today's discussion will be focusing on finalizing the items for the 3.9 release. I'd expect that these submissions will be included in consideration for 3.10, so if you'd prefer to join the next subsequent meeting on May 7, that would be great too.

Best,
Steve


On Thu, Apr 23, 2020 at 3:04 AM <andrewjskatz@...> wrote:
Hi All

I have submitted the three variants of V2 of the CERN-OHL using the licence submission tool, with the proposed SPDX identifiers: 

CERN-OHL-2.0-P
CERN-OHL-2.0-W
CERN-OHL-2.0-S

Please let me know if there is any more information you require. I am happy to attend the legal team meeting which I understand is later today. 

All the best


Andrew

Andrew Katz
Moorcrofts LLP



--
Steve Winslow
Director of Strategic Programs
The Linux Foundation


Meeting today, Apr. 23

Steve Winslow
 

Hello all, the next regularly-scheduled SPDX legal team meeting will be today, Thursday, Apr. 23 at 9AM PDT / noon EDT.

The primary agenda item will be to discuss license requests currently tagged for the 3.9 release, viewable at: https://github.com/spdx/license-list-XML/issues?q=is%3Aopen+is%3Aissue+milestone%3A%223.9+release%22

Best,
Steve

= = = = =

Join Zoom Meeting
https://zoom.us/j/611416785

Meeting ID: 611 416 785

One tap mobile
+16465588656,,611416785# US (New York)
+16699006833,,611416785# US (San Jose)

Dial by your location
        +1 646 558 8656 US (New York)
        +1 669 900 6833 US (San Jose)
        877 369 0926 US Toll-free
        855 880 1246 US Toll-free
        +1 647 558 0588 Canada
        855 703 8985 Canada Toll-free
Meeting ID: 611 416 785
Find your local number: https://zoom.us/u/aceZFvRyln


--
Steve Winslow
Director of Strategic Programs
The Linux Foundation


CERN-OHL

Andrew
 

Hi All

I have submitted the three variants of V2 of the CERN-OHL using the licence submission tool, with the proposed SPDX identifiers: 

CERN-OHL-2.0-P
CERN-OHL-2.0-W
CERN-OHL-2.0-S

Please let me know if there is any more information you require. I am happy to attend the legal team meeting which I understand is later today. 

All the best


Andrew

Andrew Katz
Moorcrofts LLP


Re: documentation/examples of License Ref?

Steve Winslow
 

Hi Luis, hope you (and others) are staying safe and healthy as well.

Echoing Kyle, "LicenseRef-" is part of the spec syntax and is defined in Appendix IV of the spec. [1] In an actual SPDX document, it would be defined in a corresponding "Other License" section. [2]

In the v2.2 release of the spec (for which a release candidate was circulated this morning), the spec now explicitly clarifies that LicenseRefs can be used in short-form identifiers in source code. [3] REUSE has also implemented this in their spec and described a mechanism for including the corresponding license text directly in a repo.

Hope this helps!
Steve

(links below are to sections of the v2.2 release candidate)

[4] https://reuse.software/spec/, search for "LicenseRef"


On Fri, Apr 17, 2020 at 12:39 PM Kyle Mitchell <kyle@...> wrote:
Luis,

`LicenseRef-*` is technically part of the license expression
syntax, too.  But it mostly comes up in the context of
(private, shared) SPDX XML files.  I'm not aware of any
package managers that leverage it as a way for package
authors to express their own license terms.

--
Kyle Mitchell, attorney // Oakland // (510) 712 - 0933





--
Steve Winslow
Director of Strategic Programs
The Linux Foundation


Re: documentation/examples of License Ref?

Kyle Mitchell
 

Luis,

`LicenseRef-*` is technically part of the license expression
syntax, too. But it mostly comes up in the context of
(private, shared) SPDX XML files. I'm not aware of any
package managers that leverage it as a way for package
authors to express their own license terms.

--
Kyle Mitchell, attorney // Oakland // (510) 712 - 0933


documentation/examples of License Ref?

Luis Villa
 

👋🏼 hope everyone is doing as well as they can under the circumstances.

Is there any documentation for, or examples of, correct usage of License Ref? I've been looking this morning and can't find much, but I may just be looking in the wrong places.

Thanks!
Luis


Re: [spdx] Chime instead of Zoom, a modest proposal

Bradley M. Kuhn <bkuhn@...>
 

This would be a good time to note that folks who care about their software
freedom cannot effectively participate in SPDX, and not only because the
conferencing solution is proprietary software (although in the past I was
able to join non-video via a phone number using PSTN line -- this thread
indicates to me that feature might go away now).

In particular, the mailing lists silently one night a year or two ago changed
from GNU Mailman to a proprietary software service with almost no notice. (I
discovered later SPDX was apparently the "test list" that LF used when they
switched all their mailing lists wholesale from a FOSS solution to a
proprietary one, which is why SPDX switched first.) That new service
requires agreement to a proprietary license to interact with its web
interface at all (including to just manage subscription requests), which of
course installs proprietary Javascript on one's computer while using it [0].

I have invited FOSS licensing folks to the SPDX list who refused to join the
mailing list because they didn't want to agree to this proprietary license.
There are thus non-hypothetical examples of SPDX's lack of inclusivity
discouraging participation.

Meanwhile, with the slow move to GitHub for more and more SPDX items, SPDX
has slowly begun to cross the line into using proprietary-access-only GitHub
features. The CLI GitHub clients that use the API can interact with GitHub
issues somewhat. I think (although I haven't checked in about a year) that
GitHub doesn't require you to agree to a proprietary license just to make an
account and use the API. However, the standard web interface to most GitHub
features requires the installation of proprietary software.

So, while James' "must work on Linux" is of course a must, I think this would
be a good moment for SPDX to consider if it wants to dig even deeper into
being a project that has been for some time fundamentally unfriendly to FOSS
enthusiasts. The trend has been in a FOSS-unfriendly direction, and this is
a factor in why I've reduced my volunteer time substantially for SPDX in the
last 6-9 months. I noticed and read through this thread because the subject
line was related to that very issue, and it confirms that I should be
recommending that folks who care about software freedom will probably just
need to avoid the SPDX project.


[0] The only reason I'm still on this mailing list is that the GNU Mailman
subscriptions were auto-imported to the proprietary system, and I since
was a founding member of the inaugural FOSS-Bazaar-Package-Facts list
that became the SPDX lists eventually, I'm still on it. As such, I've
never actually agreed to Linux Foundation's new proprietary license for
its mailing list software, now LF is just sending me (now-unsolicited)
email that I happen to find in my inbox.
--
Bradley M. Kuhn - he/him

Pls. support the charity where I work, Software Freedom Conservancy:
https://sfconservancy.org/supporter/


Re: [spdx] Chime instead of Zoom, a modest proposal

Jonas Smedegaard
 

Quoting Jeremiah C. Foster (2020-04-15 18:57:24)
On Tue, 2020-04-14 at 16:45 -0400, John Sullivan wrote:
"James Bottomley" <James.Bottomley@...> writes:

Well, I'm glad you asked ... so far the most promising fully open
trial
is this one:

https://bigbluebutton.org/
I've used Jitsi meet a bit and it is pretty decent too;
https://github.com/jitsi/jitsi-meet
For the pragmatic angle of "does it work reliably" I agree that Jitsi is
a viable option.

Any conferencing service _can_ become unreliable when stressed.
Stability for all improves when a) fewest possible participants use
their camera, and b) use newest release of a Chromium-based web browser
(i.e. best to avoid¹ Firefox or Safari or GNOME Web).


One caveat with tools that use WebRTC - there is no E2E encryption yet
in the protocol. Matrix however does have this and I've used its'
video and audio and that works quite well.
True, no general-purpose web browser support E2E encryption for WebRTC
calls, so if you want the convenience of "calling from your browser"
then you cannot have the strongest of security.

That said, WebRTC security is still _better_ than that of non-WebRTC
services like Zoom².

For conferences crucially needing it, WebRTC with E2E encryption _is_
possible, using a dedicated tool (i.e. not a web browser) and the
advanced WebRTC+MLS service at https://wire.com/en/


- Jonas


¹ Because Jitsi until next release (expected few days from now) only
reliably supports Chromium-based web browsers -
https://github.com/jitsi/jitsi-meet/issues/4758 - and Firefox is known
to cause trouble not only for themselves but also for other participants
- https://github.com/jitsi/jitsi-meet/issues/5439 and
https://bugzilla.mozilla.org/show_bug.cgi?id=1164187

² Because Zoom is known to jeopardize security and even practice
newspeak by advertising that they support "e2e" (meaning something else
by that term than the rest of the world):
https://onezero.medium.com/zoom-is-a-nightmare-so-why-is-everyone-still-using-it-1b05a4efd5cc

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

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


Re: Chime instead of Zoom, a modest proposal

John Sullivan
 

"James Bottomley" <James.Bottomley@...> writes:

Well, I'm glad you asked ... so far the most promising fully open trial
is this one:

https://bigbluebutton.org/
Yeah, FSF is running an instance that is being used to successfully
teach classes at MIT right now. We'll post more about it soon, but can
confirm that it works for 20+, with video and screen sharing. Also have
quite a bit of info at
https://libreplanet.org/wiki/Remote_Communication.

-john

--
John Sullivan | he/his/him | Executive Director and VP, Free Software Foundation
GPG Key: A462 6CBA FF37 6039 D2D7 5544 97BA 9CE7 61A0 963B
https://status.fsf.org/johns | https://fsf.org/blogs/RSS

Do you use free software? Donate to join the FSF and support freedom at
<https://my.fsf.org/join>.


Re: Chime instead of Zoom, a modest proposal

Alexios Zavras
 

The good folks at FSFE maintain a wiki page with Free Software alternatives:
https://wiki.fsfe.org/Activities/FreeSoftware4RemoteWorking

I should point out that in the SPDX calls we don't actually use video -- it's audio and screen sharing.

-- zvr

-----Original Message-----
From: Spdx-legal@... <Spdx-legal@...> On Behalf Of James Bottomley
Sent: Tuesday, 14 April, 2020 06:35
To: Kyle Mitchell <kyle@...>
Cc: atwoodm@...; Kate Stewart <kstewart@...>; Spdx-legal@...; spdx@...
Subject: Re: Chime instead of Zoom, a modest proposal

On Mon, 2020-04-13 at 20:55 -0700, Kyle Mitchell wrote:
Others have more religious affinity for the Linux desktop.
Wow that's a blast from the early part of this millenium. Since Linux now runs over 80% of the world's computing resources, I thought we'd got over stigmatizing people who actually run it on their desktops.

It's not for want of others trying: my workplace keeps sending me windows laptops, but they aren't really useful for my daily activities and it turns out that if you don't switch them on very often, they simply stop working and eventually the capital expense isn't worth it.

But I haven't seen any libre option that stacks up to Zoom's
reliability. Other closed competitors---Hangouts especially---never
met that bar, either.
Well, I'm glad you asked ... so far the most promising fully open trial is this one:

https://bigbluebutton.org/

But the trials are still ongoing so that's by no means the final answer. It's actually somewhat obvious: bigbluebutton was developed for teaching remotely in under resourced schools, so of course they brought it up on a free (as in beer) OS because everything else was cost prohibitive. No one's heard of it because their advertising budget matches the available resources ...

James






Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Gary Kershaw
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928


Re: Chime instead of Zoom, a modest proposal

Till Jaeger
 

I have not the technical expertise to judge the security level of the
following solution that works with Zoom on Linux:

https://www.linux.com/news/how-to-install-and-use-firejail-on-linux/


----
For some distros like Ubuntu:

$ sudo apt install firejail

$ sudo ln -s /usr/bin/firejail /usr/local/bin/zoom
$ which -a zoom
/usr/local/bin/zoom
/usr/bin/zoom
/bin/zoom

zoom (to start from the shell)

$ firejail --list
3339:username::/usr/bin/firejail /usr/bin/zoom

------


Best,

Till


Re: Chime instead of Zoom, a modest proposal

James Bottomley
 

On Mon, 2020-04-13 at 20:55 -0700, Kyle Mitchell wrote:
Others have more religious affinity for the Linux desktop.
Wow that's a blast from the early part of this millenium. Since Linux
now runs over 80% of the world's computing resources, I thought we'd
got over stigmatizing people who actually run it on their desktops.

It's not for want of others trying: my workplace keeps sending me
windows laptops, but they aren't really useful for my daily activities
and it turns out that if you don't switch them on very often, they simply stop working and eventually the capital expense isn't worth it.

But I haven't seen any libre option that stacks up to Zoom's
reliability. Other closed competitors---Hangouts
especially---never met that bar, either.
Well, I'm glad you asked ... so far the most promising fully open trial
is this one:

https://bigbluebutton.org/

But the trials are still ongoing so that's by no means the final
answer. It's actually somewhat obvious: bigbluebutton was developed
for teaching remotely in under resourced schools, so of course they
brought it up on a free (as in beer) OS because everything else was
cost prohibitive. No one's heard of it because their advertising
budget matches the available resources ...

James

481 - 500 of 3280