Karsten invited me to join “The Open Source Way” podcast over at SAP to explain what we do and how it impacts the supply chain and large market.

Check out the recording here:
https://podcast.opensap.info/open-source-way/2022/10/26/linux-foundation-building-trust-in-software-supply-chains/
Links: You receive all messages sent to this group.
View/Reply Online (#4910): https://lists.openchainproject.org/g/main/message/4910
Mute This Topic: https://lists.openchainproject.org/mt/94603658/5997145
Group Owner: main+owner@...
Unsubscribe: https://lists.openchainproject.org/g/main/leave/10330563/5997145/102626985/xyzzy [seabass-labrax@...]

Hi all,

 

I have recently joined the SPDX legal mailing list and wanted to give a short introduction. My name is Anna Haipola and I am a Legal Counsel supporting the Open Source Program Office at Nokia. I am based in Espoo, Finland. I attended my first external event related to open source software last week at the OSPOlogy.live workshop in Stockholm, and it was truly inspiring to meet professionals working with the same topics in other organizations. I look forward to more collaboration.

 

The reason why I wanted to get in touch with the SPDX legal team was that I had a question related to the section 2.2.2 of the SPDX Specification (version 2.2). SPDX-Metadata is subject to the terms of the Creative Commons CC0 1.0 Universal license. Section 2.2.2 further states: “This approach

avoids intellectual property and related restrictions over the SPDX file, however individuals can still contract with each other to restrict release of specific collections of SPDX files (which map to software bill of materials) and the identification of the supplier of SPDX files.”

 

I was unsure whether this meant that even though the data related to the SPDX fields can be distributed freely under CC0, collections of SPDX files could be protected under confidentiality clauses agreed upon between the SPDX document creator and the recipient. I would be happy to discuss this matter in one of the upcoming Legal Team meetings. I will be joining tomorrow’s meeting, so happy to provide some more details on this proposed agenda item there if there is time.

 

Looking forward to meeting you tomorrow.

 

Kind regards,
Anna Haipola

 

____________________________________________

 

Anna Haipola
Legal Counsel, TECH Legal
Nokia Technologies Oy

At Nokia, we create technology that helps the world act together

CONFIDENTIALITY NOTICE

 

This e-mail and any attachments hereto may contain information that is privileged or confidential,
and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution
of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us
promptly by responding to this e-mail. Thank you.

 

Please consider the environment before printing this e-mail.

 

On Sep 15, 2022, at 10:08 PM, Richard Fontana <rfontana@...> wrote:

On Wed, Sep 7, 2022 at 2:17 PM Steve Winslow <swinslow@...> wrote:

Jilayne -- yes, I'd be open to a lighter-weight or streamlined approach to approving licenses submitted from use in distros such as Debian and Fedora.

In these cases we have greater confidence that those communities have done the work to vet certain of the license inclusion principles. In particular the first and most important "Other Factor" re: "substantially complies with open source definitions"; and its inclusion in the distro likely demonstrates the "substantial use" factor for SPDX purposes.

I expect we'd want to be a bit specific about what we mean by "is included in the distro". For instance, for Debian I'd think `main` would be covered, `non-free` would not, and I don't know for `contrib`. I don't know how Fedora divides things up...

In contrast to Debian, Fedora does not have separate
official/project-administered package repositories with different
license inclusion criteria.

Fedora has an explanation here that may be helpful:
https://docs.fedoraproject.org/en-US/legal/license-approval/

To summarize, there are different categories of material to which
different license standards are applied:

- The general "allowed" category -- licenses here are determined by
Fedora to be FOSS through a sort of common law-like approach (Fedora
has no DFSG/FSD/OSD counterpart of its own)
- "Allowed-documentation" -- licenses approved only for documentation.
The intent here is that the licenses are libre, i.e., equivalent in
permissiveness/restrictiveness to software-oriented FOSS licenses,
except that a few licenses (already recognized by SPDX) are treated as
allowed-documentation for historical reasons even though they can't
seriously be considered to meet all the standards of the licenses in
the allowed category
- "Allowed-content" -- licenses approved only for "content" which
basically means something that can't be considered software,
documentation, or fonts. These have to be FOSS except they can
prohibit modification and have a "no patent licenses" provision.
- "Allowed-firmware" -- licenses approved only for binary firmware
files that meet certain technical operating system-related criteria;
these licenses need not be FOSS but only certain kinds of non-FOSS
terms are permitted.
- "Allowed-fonts" -- licenses approved only for fonts. These licenses
must meet the standards for FOSS except that they can have a "Sun RPC"
clause (i.e. a prohibition on resale/distribution in isolation, which
is for some reason commonly found in pseudo-FOSS font licenses). The
main community authorities on FOSS definitional norms (FSF, OSI,
Debian) have all implicitly taken the position that these kinds of
clauses do not preclude a classification of a font license as FOSS,
but to varying degrees and with a large dose of historical
inconsistency have taken the view that they are generally not
acceptable in a FOSS software license. Fedora is simply being more
transparent that there are relaxed community standards for font
licenses in this one respect.

So I think Fedora has made an effort to ensure that the licenses in
the "allowed", "allowed-documentation" and "allowed-fonts" categories
substantially comply with widely-held community open source
definitions. That can't be said of all licenses in the
allowed-content (probably) and allowed-firmware (definitely)
categories. However, I wonder if the fact that these generally
non-FOSS licenses are determined to meet the license criteria of a
distro that is basically conceptualized as a free software community
distro ought to justify the lighter-weight review Jilayne speaks of.

Richard

Hi Jilayne,


once in a while I come back with my yet informal proposal to treat new licenses in two stages:

Stage 1 - Registration
Register a license text providing a unique name and short id. (New) Registration guidelines only make sure no other SPDX license is duplicated / affected.
This stage is basically about identification of a license and provides fast acceptance without sacrificing inclusion principles.

Stage 2 - Inclusion
The remainder of the current process to include licenses and do the matching part.
This stage is basically about qualification of a license (in the SPDX License List style)

A license may remain in stage 1 in case the inclusion principles are not met.
A license may be leveled-up from stage 1 to stage 2 in case the inclusion principles are met and once the license is approved and further metadata was collected.
A license in either stage 1 or stage 2 may go through a dedicated change process (deprecation) in case past decisions or provisions need to be reiterated.

This reply also covers your email "for discussion: when can people start using short ids?", since people can start using the name and short id once registered.

I volunteer to write a formal change proposal in case there is sufficient interest in the outline of such an approach.

Regards,
Karsten



On 05.09.22, 22:12, "J Lovejoy" <Spdx-legal@... on behalf of opensource@...> wrote:

    Hi all,

    I just made a new issue to capture this, but wanted to raise it here for broader discussion. 

    If we say that all OSI-approved are included on the SPDX License List, would we want to extend this to licenses that have been deemed to meet the Debian Free Software Guidelines, Fedora guidelines, or Linux kernel guidance?

    Even if not a definitive factor, would we want to allow for a lighter-weight review of such licenses to make it faster/easier to get to acceptance?

    Thinking being that if large distros really want to be able to use SPDX ids across the board, then we need to be able to move quickly in the license review phase. While we have tended toward this in practice, we do not have it recorded in policy. 

    (not sure if this would be worthy of use of the new Change Proposal format - feels borderline for that, but happy to raise in that way, if people think that would help!)

    Jilayne