1. Spdx-Legal
  2. Messages

Expanded

Topics Messages Polls
   Date   
Meeting today, April 15

Steve Winslow
 

Hello SPDX legal team,

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

For today's call, we will be reviewing the issues currently tagged for 3.13, available at https://github.com/spdx/license-list-XML/issues?q=is%3Aopen+is%3Aissue+milestone%3A3.13

In particular we will focus on the items at the link above that are tagged as "new license/exception request". Note that the end of April will be the 3.13 release (and I don't expect we will push the release date out).

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
Re: FreeBSD Use Case for Short Identifiers

Max Mehl
 

Hi Warner,

~ Warner Losh [2021-04-02 19:03 +0200]:
The policy seems really similar to the REUSE standard [1] for licensing
notices, which combines the SPDX license list with a convention for
where and how to put these notices in the source tree. Given that your
draft policy has many of the same objectives as REUSE, you might want to
consider adopting the REUSE standard fully, as it would allow you to use
existing tools to check and add these notices. It also allows you to
generate SPDX documents automatically, if that is something you are
interested in.
Thanks @Sebastian for bringing up REUSE! Indeed, I concur that it's a
worthy goal for FreeBSD. It reminds me a bit of KDE's story. The project
also adopted REUSE in their policies, and made larger parts of the
codebase REUSE compliant already. They also wrote a tool to convert
traditional copyright notices to SPDX license identifiers
(licensedigger). The interview with Andreas may provide a good overview:

https://fsfe.org/news/2020/news-20201215-01.html

https://community.kde.org/Policies/Licensing_Policy#License_Statements

I did have one question about REUSE.

At one point it says:

"To implement this method, each plain text file that can contain comments
MUST contain comments at the top of the file (comment header) that declare
that file’s Copyright and Licensing Information."

and a little later:

"The SPDX-License-Identifier tag MUST be followed by a valid SPDX License
Expression describing the licensing of the file (example:
SPDX-License-Identifier: GPL-3.0-or-later OR Apache-2.0). If separate
sections of the file are licensed differently, a different
SPDX-License-Identifier tag MUST be included for each section."

These seem to contradict a little since you need to associate the copyright
with the license, I'd think. Not sure how big a deal it is, but it was
confusing to me.
Do you refer to the different sections? Indeed, we're are currently
working on improving and standardising the declaration of differently
licensed/copyrighted parts (snippets). For this, I've started a PR for
the SPDX spec to define the tags and syntax that REUSE can pick up:

https://github.com/spdx/spdx-spec/pull/464

At the moment, we have ~25k of the ~95k files in our tree with SPDX tags.
It will be quite some time before we get everything marked. In the
meantime, we'd hoped to use the short form to nip in the bud the number of
variants that pop up as people cut and paste and then tweak things.
Copyright notices, however, are much better represented. We have ~6k
Makefiles w/o marking, and maybe a few thousand more that are mostly (but
not entirely) tests or other files that don't go into the build or whose
format cannot tolerate comments. Part of this effort, long term, is to
clean all that up, but it can't have it gating the other stuff.
Totally understandable. You may be interested in tools that help you
with the conversion, e.g. the aforementioned licensedigger. IIRC the
Linux project also came up with some conversion scripts to distinguish
their different notice headers (GPL version, only/or-later,
exceptions...).

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: FreeBSD Use Case for Short Identifiers

Warner Losh
 



On Fri, Apr 2, 2021 at 9:27 AM Sebastian <seabass-labrax@...> wrote:
Dear Warner,

I've read the policy draft you've written; clearly you have given this
lots of thought already. I'd like to offer my take on it:

Thanks for the feedback. I'll take a look at this.
 
The policy seems really similar to the REUSE standard [1] for licensing
notices, which combines the SPDX license list with a convention for
where and how to put these notices in the source tree. Given that your
draft policy has many of the same objectives as REUSE, you might want to
consider adopting the REUSE standard fully, as it would allow you to use
existing tools to check and add these notices. It also allows you to
generate SPDX documents automatically, if that is something you are
interested in.

I did have one question about REUSE.

At one point it says:

"To implement this method, each plain text file that can contain comments MUST contain comments at the top of the file (comment header) that declare that file’s Copyright and Licensing Information."

and a little later:

"The SPDX-License-Identifier tag MUST be followed by a valid SPDX License Expression describing the licensing of the file (example: SPDX-License-Identifier: GPL-3.0-or-later OR Apache-2.0). If separate sections of the file are licensed differently, a different SPDX-License-Identifier tag MUST be included for each section."

These seem to contradict a little since you need to associate the copyright with the license, I'd think. Not sure how big a deal it is, but it was confusing to me.
 
In particular, section 2.4 would become unnecessary with REUSE. One of
the principles of the specification is to provide copyright and license
notices for *all* files, even if that license may be unenforceable. As
the BSD license has very few requirements, it shouldn't be hard for
distributors to comply with it anyway. Again, if all files (even the
trivial ones!) are supposed to have SPDX notices, it would be very easy
to spot the files missing them.

True. It's a substantial burden to get to that point before adopting the rest of the system. That said, it is a good long-term goal and one that we can enforce in the pre-commit checks.

At the moment, we have ~25k of the ~95k files in our tree with SPDX tags. It will be quite some time before we get everything marked. In the meantime, we'd hoped to use the short form to nip in the bud the number of variants that pop up as people cut and paste and then tweak things. Copyright notices, however, are much better represented. We have ~6k Makefiles w/o marking, and maybe a few thousand more that are mostly (but not entirely) tests or other files that don't go into the build or whose format cannot tolerate comments. Part of this effort, long term, is to clean all that up, but it can't have it gating the other stuff.

Our 'Beer-ware' licensed files may fall into the unenforceable category...
 
Finally, I also have a few minor suggestions. Copyright licenses aren't
necessarily contracts as stated in section 2; I think that part one of
the short essay 'Free Software Matters: Enforcing the GPL' by Eben
Moglen [2] is particularly good at describing the essence of software
licenses.

As a non-legal person, avoiding 'contract' and using 'document' is likely better since this policy is designed for clarity and anything that gets in the way of that clarity isn't so good. I've chatted with several corporate lawyers over the years who have a different analysis than Dr. Moglen. It's likely better to avoid the issue since I'm not a legal professional and should stay out of any such fights.

Personally, I would remove sections 3 and 4 entirely and link to a
separate document describing those policies. I sometimes find it
confusing when projects have multiple documents explaining the same
thing, and it also increases the risk of contradictions when one is
updated but not others.

Sections 3 & 4 are supposed to be 'what to do' while 1&2 are 'how to do it'. They are currently in 3 different docs, all of which are slightly different in ways that are more annoying than practically bad... I worry that having these things relegated to another document would exacerbate the issue with things being out of sync.
 
Finally, it occurs to me that full adoption of SPDX license identifiers,
if you decided to choose that path, would be the perfect topic for a
joint press release - maybe something to discuss in the future :)

Ah, that's above my pay grade :) I'll keep that in mind and chat with our PR folks about it, though.

Warner
 
Best wishes,

Sebastian

[1]: https://reuse.software/
[2]: http://emoglen.law.columbia.edu/publications/lu-12.pdf
Re: FreeBSD Use Case for Short Identifiers

Sebastian Crane
 

Dear Warner,

I've read the policy draft you've written; clearly you have given this
lots of thought already. I'd like to offer my take on it:

The policy seems really similar to the REUSE standard [1] for licensing
notices, which combines the SPDX license list with a convention for
where and how to put these notices in the source tree. Given that your
draft policy has many of the same objectives as REUSE, you might want to
consider adopting the REUSE standard fully, as it would allow you to use
existing tools to check and add these notices. It also allows you to
generate SPDX documents automatically, if that is something you are
interested in.

In particular, section 2.4 would become unnecessary with REUSE. One of
the principles of the specification is to provide copyright and license
notices for *all* files, even if that license may be unenforceable. As
the BSD license has very few requirements, it shouldn't be hard for
distributors to comply with it anyway. Again, if all files (even the
trivial ones!) are supposed to have SPDX notices, it would be very easy
to spot the files missing them.

Finally, I also have a few minor suggestions. Copyright licenses aren't
necessarily contracts as stated in section 2; I think that part one of
the short essay 'Free Software Matters: Enforcing the GPL' by Eben
Moglen [2] is particularly good at describing the essence of software
licenses.

Personally, I would remove sections 3 and 4 entirely and link to a
separate document describing those policies. I sometimes find it
confusing when projects have multiple documents explaining the same
thing, and it also increases the risk of contradictions when one is
updated but not others.

Finally, it occurs to me that full adoption of SPDX license identifiers,
if you decided to choose that path, would be the perfect topic for a
joint press release - maybe something to discuss in the future :)

Best wishes,

Sebastian

[1]: https://reuse.software/
[2]: http://emoglen.law.columbia.edu/publications/lu-12.pdf
Re: FreeBSD Use Case for Short Identifiers

Steve Winslow
 

Hi Warner,

Thanks for sharing this. It looks like a good, detailed way to document how the SPDX license identifiers will work for FreeBSD. I've seen several projects implement SPDX identifiers without this level of detail, but I understand the desire to do so here and I think this will be helpful to the community.

I took a quick look at the sections relating to SPDX identifiers. I had a couple of clarifications that might be helpful to consider:

* In section 2, there's a link to https://spdx.org/. There's a page on the SPDX website that is dedicated to explaining how SPDX identifiers work, at https://spdx.dev/ids/ -- this might be more useful as a direct link.

* In section 2.5, I note that it states that for the GNU family of licenses, the "-only" and "-or-later" IDs are deprecated and e.g. "GPL-2.0" or "GPL-2.0+" should be used instead. This is incorrect -- it's actually the other way around, the plain identifier or "+" is deprecated and "-only" / "-or-later" should typically be used instead.

To be clear, the "GPL-2.0" / "GPL-2.0+" identifiers remain valid and usable. They are listed as "deprecated" in the section at the bottom of https://spdx.org/licenses/, but they are still valid (and I expect will remain valid). Some projects, such as the Linux kernel, have opted to primarily use this form rather than switching to "-only" / "-or-later".

This is only for the GNU family of licenses (GPL, LGPL, AGPL) -- all others continue to use "+" as the primary way to express "or later version".

I hope this is helpful! Best,
Steve


On Thu, Apr 1, 2021 at 6:53 PM Warner Losh <imp@...> wrote:
Greetings,

The FreeBSD project is planning on expanding our use of the SPDX-License-Identifier. Currently, all files have the full license text. We have a mix of files with SPDX ID and those without.

What we'd like to do is expand this so we can accept software that only has a copyright notice plus an SPDX-License-Identifier to indicate the license. To that end, we're trying to craft a policy / document that describes how contributors, users and redistributors of the software can know the license for any given file in the tree.

For the files that have only an explicit license text, it's that license.
For files with both, the explicit license text is the license.
For files with only the SPDX-License-Identifier, the license text can be found in our source tree as src/share/license/<SPDX-License-Identifier>.txt with any copyright notices in the file pre-pended.

To accomplish this, I've started to put together an over-arching FreeBSD policy at https://people.freebsd.org/~imp/DRAFT-Licensing-Policy.html which (a) needs to be copyedited and (b) likely needs to have sections 3 & 4 before 1 & 2.

I thought I'd run this by people here for review and/or to evaluate it as a FAQ answer :).

Warner



--
Steve Winslow
VP, Compliance and Legal
The Linux Foundation
FreeBSD Use Case for Short Identifiers

Warner Losh
 

Greetings,

The FreeBSD project is planning on expanding our use of the SPDX-License-Identifier. Currently, all files have the full license text. We have a mix of files with SPDX ID and those without.

What we'd like to do is expand this so we can accept software that only has a copyright notice plus an SPDX-License-Identifier to indicate the license. To that end, we're trying to craft a policy / document that describes how contributors, users and redistributors of the software can know the license for any given file in the tree.

For the files that have only an explicit license text, it's that license.
For files with both, the explicit license text is the license.
For files with only the SPDX-License-Identifier, the license text can be found in our source tree as src/share/license/<SPDX-License-Identifier>.txt with any copyright notices in the file pre-pended.

To accomplish this, I've started to put together an over-arching FreeBSD policy at https://people.freebsd.org/~imp/DRAFT-Licensing-Policy.html which (a) needs to be copyedited and (b) likely needs to have sections 3 & 4 before 1 & 2.

I thought I'd run this by people here for review and/or to evaluate it as a FAQ answer :).

Warner
Meeting today, April 1

Steve Winslow
 

Hello SPDX legal team,

The next regularly-scheduled SPDX legal team meeting will be today, Thursday, April 1. It will be at 9AM PDT / noon EDT, following the SPDX general meeting one hour earlier.

We'll start today's meeting with an update on the SPDX 3.0 Licensing profile conversation with the tech team earlier this week. After that I expect we will turn to reviewing issues for 3.13 and continuing the discussions from the last meeting.

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
Initial WIP draft of 3.0 Licensing profile

Steve Winslow
 

Hello SPDX tech and legal teams,

I've added a PR with an initial, incomplete / WIP draft of the Licensing profile for the SPDX 3.0 spec, at: https://github.com/spdx/spdx-spec/pull/503. I'm hoping we can have an initial discussion of the syntax and subsections of this during part of the tech team call tomorrow. We'll also touch on this during the legal team call on Thursday.

The substance of this draft is based on the earlier discussions from joint legal/tech team calls in 2020. The Markdown formatting is based on the template for profiles that the tech team has been working on. You'll see there are many "TBD" notes left in the current draft, as well as placeholders for sections that are yet to be drafted.

As mentioned in the PR, let's initially focus not on the substance of the profile, e.g. which licensing fields should or should not be included. I think it'll be more useful to start by addressing the syntax and setup of the template, so that we can make sure the teams are aligned on that. I think that'll help unblock other profile section drafters beyond licensing.

After that we can come back to the licensing details and substance, probably with a future joint tech/legal team call.

Thanks,
Steve

--
Steve Winslow
VP, Compliance and Legal
The Linux Foundation
Re: Options for metadata license identifiers

Alexios Zavras
 

As a single data point, we (Intel) use the mentioned:

# SPDX-License-Identifier: MIT
LICENSE = "GPLv2 & bzip2-1.0.4"

under the understanding that the comment "SPDX-License-Identifier" applies only to the file the line is in.

-- zvr

-----Original Message-----
From: Spdx-legal@... <Spdx-legal@...> On Behalf Of Richard Purdie
Sent: Thursday, 18 March, 2021 12:12
To: SPDX-legal <Spdx-legal@...>
Subject: Options for metadata license identifiers

Hi,

I wondered if I might seek advice/opinions on a dilemma Yocto Project is facing with license identifiers.

First, some background. We build software components from source and combine them together to make up an operating system (most often Linux). As such we have metadata we refer to as "recipes" which are basically lists of instructions on where to get a piece of software, how to configure it and so on. Our core layer has around 800 recipes (http://git.yoctoproject.org/cgit.cgi/poky/tree/).

In addition we also store patches alongside the recipes which are applied to the source code as part of the build process.

Where we have normal code for the build process, license identifiers are easy and we've added them to our code/scripts as we're aligned with SPDX and believe in what it is doing. Where we have concern is the recipes.

The recipes already have our own license identifiers in them for the software being built, for example the busybox recipe has:

$ cat meta/recipes-core/busybox/busybox.inc | grep LIC LICENSE = "GPLv2 & bzip2-1.0.4"
LIC_FILES_CHKSUM = "file://LICENSE;md5=de10de48642ab74318e893a61105afbb \
file://archival/libarchive/bz/LICENSE;md5=28e3301eae987e8cfe19988e98383dae"

What this means is that the busybox source/binaries are under the listed licenses and that the two files mentioned contain license information.
We have a checksum there so that when we upgrade to a new version of busybox, if the checksums change, we know we need to re-evaluate the license field. Its not a perfect check but it does catch basic mistakes and we can easily check and reject patches where it hasn't been re-evaluated.

Our license handling predates SPDX, we are trying to align to SPDX identifiers.

My question is what to put in the recipe to identify the license?

We can easily put a "# SPDX-License-Identifier:" into the recipe but there is a lot of concern about how people might interpret this. Our top level license says unless otherwise stated, recipe metadata is MIT licensed so the license is relatively clear. The worry is something like:

# SPDX-License-Identifier: MIT
LICENSE = "GPLv2 & bzip2-1.0.4"

makes for very confusing reading and can be badly interpreted.

I have some ideas about what we might have to do to make this really clear but they have downsides. I wondered if there was any advice here on how best to handle this? Once we know how to do it, marking up the recipes is relatively straightforward, we just need to establish what makes sense.

Also, there is a secondary problem of which license any patches we have are under and what license identifier (if any) we should put in those.
Those would likely need to match the upstream project source they're patching I'd imagine but I don't know if we want to mark up all the patches or not.

Cheers,

Richard







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
FAQ review

Warner Losh
 

Greetings,

As discussed at the March 18th meeting, it's time to review our FAQ. I've created a google doc for people to make suggestions for improved wording, flagging areas that are unclear, etc. I have the permissions wide open. Please go into 'Suggesting' mode before making any changes.


The plan is to collect submissions and discuss them at a future meeting.

Warner
Re: Options for metadata license identifiers

Gary O'Neall
 

Hi Richard,

-----Original Message-----
From: Spdx-legal@... <Spdx-legal@...> On Behalf Of
Richard Purdie
Sent: Thursday, March 18, 2021 4:12 AM
To: SPDX-legal <Spdx-legal@...>
Subject: Options for metadata license identifiers
...
My question is what to put in the recipe to identify the license?

We can easily put a "# SPDX-License-Identifier:" into the recipe but there is a
lot of concern about how people might interpret this. Our top level license
says unless otherwise stated, recipe metadata is MIT licensed so the license is
relatively clear. The worry is something like:

# SPDX-License-Identifier: MIT
LICENSE = "GPLv2 & bzip2-1.0.4"

makes for very confusing reading and can be badly interpreted.

I have some ideas about what we might have to do to make this really clear
but they have downsides. I wondered if there was any advice here on how
best to handle this? Once we know how to do it, marking up the recipes is
relatively straightforward, we just need to establish what makes sense.

Also, there is a secondary problem of which license any patches we have are
under and what license identifier (if any) we should put in those.
Those would likely need to match the upstream project source they're
patching I'd imagine but I don't know if we want to mark up all the patches or
not.
[G.O.] How about using the SPDX tag/value terms defined for SPDX documents?

You would use "PackageLicenseDeclared: " for the package itself (see https://spdx.github.io/spdx-spec/3-package-information/#315-declared-license).
There are a couple of advantages to this approach - there is a specific definition for the term and the consistency in syntax makes the tooling a bit easier.

As far as patches, if these are specific files and you have a way to associate the field with that specific file, you could use the term "LicenseInfoInFile: "
(see https://spdx.github.io/spdx-spec/4-file-information/#46-license-information-in-file).

Gary
Re: How to start using only SDPX-License-Identifier tags

Warner Losh
 



On Thu, Mar 18, 2021 at 4:46 AM Philippe Ombredanne <pombredanne@...> wrote:
Hi Warner:
See some comments below.

Hi Thomas:
This is FYI as you may be able to provide some insights and
recommendations based on the Linux kernel journey towards
SPDX that could help Warner and FreeBSD?

On Wed, Mar 17, 2021 at 11:11 PM Warner Losh <imp@...> wrote:
> I'm looking at doing whatever it would take to create a framework so
> that the FreeBSD project could use SPDX-License-Identifiers as the
> sole designator of license.

> Today, the project has SPDX tags in about 25k of 90k files in our
> source tree. However, in all cases, the SPDX tag today is informative.
> The actual license is contained in the file as well so there's no
> ambiguity as to what the license is (we have an explicit statement
> that says presently these tags are informative).
>
> However, as more and more software is created using only these tags,
> we've seen some pressure to accept this software. In addition, some
> members have expressed the desire to be rid of all this tiresome
> boilerplate at the start of every file.
>
> So, I'm investigating how we can have something like
>
> /*
>  * Copyright 2021 M. Warner Losh
>  * SPDX-License-Identifier: BSD-2-Clause
>  */
>
> become a valid license to use this file under whatever
> BSD-2-Clause.txt says, with the proper values filled in.
> [...]
> I've seen the license matching guidelines. Those make sense for the
> project's prior SPDX activity where we were adding informative tags to
> existing licenses. However, I am having trouble how one could
> unambiguously apply them to take the above copyright notice and
> license and come up with something that I could show to our legal
> department and that I'd have confidence any litigation around copying
> of the file would start at (both as the copyright holder and also as a
> company using this code).
>
> When we added the informative tags to the FreeBSD tree, there was an
> objection to that because of this and other issues. Since we said the
> tags were merely informative and the actual license granted use, we
> were able to dodge the issue at the time. As I prepare to start down
> the path of turning something like the above into something the
> project accepts, I have to return to questions like these and a
> zillion others to get there.


I happened to have helped quite a bit for a similar effort for the Linux
kernel and as a FOSS license buff I can provide a few comments. I assume
that you are considering only the core FreeBSD source tree and not the
ports for now.

1. There were similar concerns brought up during this kernel effort.
Eventually folks came down to agree after heated discussions and
adjustments. The fact there were a few ultimate decision makers or tie
breakers surely helped quite a bit together with supports from lawyers
here. Thomas Gleixner (in CC) led the effort and  may be able to provide
some comments too.

This is informative, and we are mindful of this history.
 
2. The FSFE Reuse [1] is a closely related spec that co-evolved with the
kernel efforts. It provides a good set of documentation and practices
that are not project-specific and could be adapted to the unique FreeBSD
context.

Yea. I saw that. Things are close here.
 
3. Beyond Linux and the pioneers of U-Boot, many projects now use and
accept SPDX license expressions and SPDX- License-Identifier. I made a
fairly extensive survey of related package metadata documentation
practices in my pending proposal to adopt SPDX expressions for Python
[2] which shows how prevalent things started to be.

U-Boot wasn't much help. They seem to have made the change without having some kind of document that lets me know how to construct the license. It is implicit, I'll grant, but not as satisfying as I was hoping for.
 
4. Because of the above I would say that there are now established
community norms and practices that using SPDX-License-Identifier and
SPDX license expressions are acceptable ways to document licensing.
I do not know of any vocal objections from lawyers here and elsewhere.
Therefore, these norms are now the de-facto way things are done in
community at large.

Community norms are nice, but the pushback is going to be that's not legal (rightly or wrongly). It's my understanding that the following chain has to happen for someone to enforce the license.

Copyright is at the base. There is no copying w/o permission allowed. The open source licenses grant this permission under contract law. Use of the software constitutes acceptance of the contract.

With a license that's in the file, it is clear what that contract is. With the indirection, it's not yet clear to me how that contract forms in the details because part of a contract being made includes knowing what the contract is. How do we frame things so that people know what the contract is well enough to cope with an actor advocating for a contract different from what we intended, but might be a literal reading of something, somewhere?

5. The FreeBSD situation is different because there is a greater
number of licenses and origins at play because of all the different
packages. Nevertheless, the way things have been documented in the
kernel [3] may be a good start. You have similar documents for
FreeBSD [4], but not as detailed as Linux's and with one 404 [5]
Is your plan to start by proposing a new/updated "process" document
for FreeBSD? That would be my first step.

The proposal is a fairly narrow one at the moment: The legacy stuff will remain unchanged, with the possible exception of expanding the SPDX informative tags we've added. New files are allowed to adopt either the legacy style, or the new style. Current copyright holders are allowed to switch from old to new, but everybody with a copyright stake in a specific file must sign off on moving to the new style. This handles the problems of diversity of license and the slow, viral change of it as various corporate lawyers tweaked things contributed back and others copied that instead of the original and the process iterated.

The new style would be Copyright notice plus SPDX tag. It's my job to document things so people know what it means. Not only to the causal project member that's contributing code (that's relatively easy: I add a section to our policies section in the project handbook), but also to the wider, more demanding audience who want to know what the license is, exactly, so they know what contract they are entering into.
 
6. The FreeBSD license audit from ~ 2014 by Pedro Giffuni could be
refreshed to help. We could use scancode-toolkit [6] (that I maintain)
to help there. This could allow to classify the codebase based on the
different licenses and license documentation approaches and drive the
actual planning and efforts. And help with the file replacement tooling
suggested below...

Yes. For the legacy stuff that's not a verbatim copy, we'll apply the SPDX matching rules for the tags we put in there, but we won't eliminate the licenses. But I view the classification of the old and allowing the new as two independent problems. Is that view incorrect somehow?
 
7. On the mechanics of replacing license notices by SPDX identifiers
in source code, I have some (old) code that may help with this [7]
and would only need some minor love and care to be functional again.
This could mean automating large volumes of code changes.

We'll likely not do this on a wholesale basis, though allow individual contributors to do so. There are so many copyright holders, some of which are defunct or deceased, that doing this wholesale would be fraught and likely viewed as too much risk, too little reward.
 
8. BSD historical attribution notices are usually more than just a
copyright + a license notice, but often contain extra notices such as:

- This code is derived from software contributed to Berkeley by John
  Doe.
- This code was contributed to The NetBSD Foundation by Jane Doe.
- or [8]: "Created by: Warner Losh <imp@...>"

You should document what you would want to do with these.

I was thinking something similar, but we'll need extra metadata to do that, and the current BSD templates for it in the SPDX repo would need some tweaking I think.
 
9. BSD historical licenses comes with many small variants of BSD and MIT
licenses (even in some case your own making [9] ;))
You should document what to do with these cases and in particular:

- should ALL the original name be kept when the text meets SPDX
  matching-style guidelines? MO no

- define a process to resolve cases that are borderline and fall outside
  the strict guidelines

- when should original authors be contacted, and what to do if they are
  AWOL?

All the above are covered by "Transition to new style only with copyright holder's permission" and we live with the old-style in the tree forever. Though it would be nice if at least some of these could be moved forward.

One big problem in removing things is that some files have multiple licenses currently. And while the "B2 AND B3" is good for a scanning tool, it starts to break down if you are trying to generate the licenses. 
 
- when to submit a new license to SPDX? I suspect you will find a large
  number of licenses that are unknown to SPDX. I would suggest to use
  first a LicenseRef namespace like I do in [10] either scancode's or to
  create your own first then funnel these as needed to SPDX. In my Linux
  Kernel scans, I "discovered" several new and weird license variants
  (several being franken-BSD and franken-MIT hybrids and mods). Many
  were eventually added to the SPDX license list. It would be great to
  have the same outcome for your FreeBSD effort!

I for one am not eager for a 'voiced in Bill Paul's head' license variant here :).

I'll have to investigate the LicenseRef stuff.
 
10. When doing large commits to fix many files, Thomas Gleixner and Kate
Stewart enrolled several volunteers from this list -- several of them
legally trained -- to help review and sign-off on the changes. This was
helpful on so many levels. IMHO you should do the same for FreeBSD.

I think that would be excellent.
 
11. What would be your strategy? A trickle a few files at a time over
time, possibly grouped by package or authors/licenses? Or a few larger
tree-wide changes? The latter approach was used for Linux and we started
with grouping things based on the licensing documentation clarity. It
was large to swallow but once we were over the hump I think it made
things easier afterwards.

1. write a policy that will work (the phase I'm in now)
2. get it approved
3. Allow new files with only SPDX tags soon
4. Allow contributors to switch to SPDX only (I'll likely do this on my work in FreeBSD)
5. Study the tree to see if there's a way the policy from 1&2 can be used to unambiguously switch some files over for "absentee" folks.

12. What's your plan for files with no explicit license and copyright?

That's harder... The biggest source of these in the tree at the moment are Makefiles. And it's the old-time opinion of the project that Makefiles are simple recipes and are just 'facts' and have no material that copyright law would cover. However, since the 4.4BSD days when almost all the makefiles were a dry recitation of the facts, they have become more and more complex and I personally am not sure about this anymore.

There's a few others, but all the code has been marked as far as I know... Though now that I think about it there may be a few 'data' files that might not be able to be marked..

I hope this long list of comments may help ... I did not have the time
to make them shorter!

I love that line :) I've given my first form of reactions, hopefully that will be productive. I have a lot of reading to do now too :)

Thank you so much for taking the time. This has filled in some dots and given me a good way to express some of the concerns that have been brought forward...

Warner
 
[1] https://reuse.software/
[2] https://www.python.org/dev/peps/pep-0639/#appendix-3-surveying-how-other-package-formats-document-licenses
[3] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/process/license-rules.rst
[4] https://docs.freebsd.org/en_US.ISO8859-1/articles/committers-guide/pref-license.html
[5] https://docs.freebsd.org/internal/software-license.html
[6] https://github.com/nexB/scancode-toolkit
[7] https://github.com/nexB/scancode-toolkit/blob/833-espedexify/src/scancode/plugin_espedexify.py
[8] https://github.com/freebsd/freebsd-ports-kde/blob/68a0222b674a77c456b45e3784ad24447e1eba52/devel/p5-Acme-Damn/Makefile#L1
[9] https://github.com/freebsd/freebsd-src/blob/ba7ede0b9b3d0c3a64e6e7d8cbfe26b6f882f39f/UPDATING#L2434
[10] https://scancode-licensedb.aboutcode.org/

--
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombredanne@...
DejaCode - What's in your code?! - http://www.dejacode.com
AboutCode - Open source for open source - https://www.aboutcode.org
nexB Inc. - http://www.nexb.com
Re: Options for metadata license identifiers

Richard Purdie
 

On Thu, 2021-03-18 at 14:05 +0100, Philippe Ombredanne wrote:
On Thu, Mar 18, 2021, Richard Purdie <richard.purdie@...> wrote:
[...]
The worry is something like:

# SPDX-License-Identifier: MIT
LICENSE = "GPLv2 & bzip2-1.0.4"

makes for very confusing reading and can be badly interpreted.
FWIW, I have been involved with quite a few license audits for Yocto-
based products and this is already a source of confusion as it is: in
many cases knowing if a license applies to the recipe or to the package
being built by the recipe is far from obvious.
We don't have anything indicating the license of the metadata other than
the top level license files so I'd have hoped the current situation was
at least clear, LICENSE (and LICENSE_<packagename>) apply to the binary
output, not the metadata. You're confirming the worry about potential
confusion though.

My first reaction and suggestion would be to forego using SPDX-License-
Identifier in recipes and instead to use a new variable in a recipe for
this such as this:

RECIPE_LICENSE = "MIT"
LICENSE = "GPLv2 & bzip2-1.0.4"
Since we specify the license at the top level, the bitbake/OE/YP way
to handle that would be to set RECIPE_LICENSE in the bitbake.conf file
and then just inherit it through our normal variable handling model.

The downside to that is there would be no specific markup in the recipe
about it's license. We also lack copyright information which is another
source of worry/confusion but one step at a time! We probably do need
to fix this and having something in the recipes themselves as I understand
it.

I have wondered about using something like:

# SPDX-Metadata-License-Identifier: MIT

which whilst not quite according to the SPDX spec, would at least
hopefully be clear about the meaning. I suspect there would be mixed
feelings on that approach here! :)

And if you need to have a separate license variable for patches:
PATCHES_LICENSE = "MIT"
There can be multiple patches specified in SRC_URI so that is definitely
not going to work. I suspect the answer may be to add 
SPDX-License-Identifier entries to the patch headers which would
only leave the complication of remote patches (thankfully rare). The
remote case could be handled in the SRC_URI itself.

This would be explicit, clear and nicely integratable in your tooling
IMHO. Ideally of course you'd want the content of these to be valid SPDX
license expressions. Until then I will have to have a mapping and
special detector for [1] to properly collect normalized SPDX licenses
from recipes.
FWIW we do have a mapping for this:

http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/licenses.conf

We do have functions to normalise our license expressions to SPDX 
standard where we can so those can be used if you're generating 
manifests or similar.

We recently reworked this to allow for the "-or-later" licences
to be different where we'd previously mapped "-only" and "-or-later"
as the same thing.

And FYI while I have your attention:

We are adding support to handle Yocto recipes in ScanCode-toolkit [1]
and [2] for license and origin detection. This involves parsing and
"resolving" recipes which is not trivial without running bitbake. This
is done thanks to Konrad Weihmann (in CC:) who kindly extracted his
excellent linting-focused recipe parser in a separate library [3].

[1] https://github.com/nexB/scancode-toolkit/issues/1243
[2] https://github.com/nexB/scancode-toolkit/pull/2443
[3] https://github.com/priv-kweihmann/oelint-parser
Interesting. I have to worry a little about having multiple parsers
for the file format. Did you consider using the tinfoil API in bitbake
to be able to use that to parse the metadata directly? If it wasn't 
possible to use that but the need is there, it would be good to understand
the issue and see if it is possible to improve tinfoil or provide a
suitable API.

I realise part of the challenge is that to have a complete datastore for
a recipe you do need all the inherit/includes. If you don't have that,
you are potentially not going to get accurate results from the output. A 
simple example would be packagegroup recipes where the license is
declared in the class:

meta/classes/packagegroup.bbclass:LICENSE ?= "MIT"

or for images/devicetree:

meta/classes/devicetree.bbclass:LICENSE ?= "GPLv2"
meta/classes/image.bbclass:LICENSE ?= "MIT"

I do want to see YP being able to generate SPDX manifests and better
integrate into other tools for audit purposes too, its just proving
hard to get people interested in working with and contributing to the 
core, most prefer to hack enough together to solve their immediate 
problem which is understandable but frustrating!

Cheers,

Richard
Meeting today, March 18

Steve Winslow
 

Hello SPDX legal team,

The next regularly-scheduled SPDX legal team meeting will be today, Thursday, March 18. It will be at our usual time of 9AM PDT / noon EDT. Note that the US is now on Daylight Savings Time, so please check this against your local time accordingly.

As you may have seen, version 3.12 of the license list was released after the last meeting. For today's meeting, we plan to discuss:
(1) plans for 3.13, including whether to adjust the release date and how to handle old issues that have been lingering for some time; and
(2) thoughts for a few larger "projects" we'd like to start tackling in addition to the ordinary license reviews.

We look forward to speaking with you later today.

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
Re: Options for metadata license identifiers

Philippe Ombredanne
 

Hi Richard:

On Thu, Mar 18, 2021, Richard Purdie <richard.purdie@...> wrote:
[...]
The worry is something like:

# SPDX-License-Identifier: MIT
LICENSE = "GPLv2 & bzip2-1.0.4"

makes for very confusing reading and can be badly interpreted.
FWIW, I have been involved with quite a few license audits for Yocto-
based products and this is already a source of confusion as it is: in
many cases knowing if a license applies to the recipe or to the package
being built by the recipe is far from obvious.

My first reaction and suggestion would be to forego using SPDX-License-
Identifier in recipes and instead to use a new variable in a recipe for
this such as this:

RECIPE_LICENSE = "MIT"
LICENSE = "GPLv2 & bzip2-1.0.4"

And if you need to have a separate license variable for patches:
PATCHES_LICENSE = "MIT"

This would be explicit, clear and nicely integratable in your tooling
IMHO. Ideally of course you'd want the content of these to be valid SPDX
license expressions. Until then I will have to have a mapping and
special detector for [1] to properly collect normalized SPDX licenses
from recipes.

And FYI while I have your attention:

We are adding support to handle Yocto recipes in ScanCode-toolkit [1]
and [2] for license and origin detection. This involves parsing and
"resolving" recipes which is not trivial without running bitbake. This
is done thanks to Konrad Weihmann (in CC:) who kindly extracted his
excellent linting-focused recipe parser in a separate library [3].

[1] https://github.com/nexB/scancode-toolkit/issues/1243
[2] https://github.com/nexB/scancode-toolkit/pull/2443
[3] https://github.com/priv-kweihmann/oelint-parser

--
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombredanne@...
DejaCode - What's in your code?! - http://www.dejacode.com
AboutCode - Open source for open source - https://www.aboutcode.org
nexB Inc. - http://www.nexb.com
Options for metadata license identifiers

Richard Purdie
 

Hi,

I wondered if I might seek advice/opinions on a dilemma Yocto Project
is facing with license identifiers.

First, some background. We build software components from source and 
combine them together to make up an operating system (most often Linux). 
As such we have metadata we refer to as "recipes" which are basically 
lists of instructions on where to get a piece of software, how to 
configure it and so on. Our core layer has around 800 recipes
(http://git.yoctoproject.org/cgit.cgi/poky/tree/).

In addition we also store patches alongside the recipes which are applied
to the source code as part of the build process.

Where we have normal code for the build process, license identifiers
are easy and we've added them to our code/scripts as we're aligned with
SPDX and believe in what it is doing. Where we have concern is the recipes.

The recipes already have our own license identifiers in them for the 
software being built, for example the busybox recipe has:

$ cat meta/recipes-core/busybox/busybox.inc | grep LIC
LICENSE = "GPLv2 & bzip2-1.0.4"
LIC_FILES_CHKSUM = "file://LICENSE;md5=de10de48642ab74318e893a61105afbb \
file://archival/libarchive/bz/LICENSE;md5=28e3301eae987e8cfe19988e98383dae"

What this means is that the busybox source/binaries are under the listed 
licenses and that the two files mentioned contain license information.
We have a checksum there so that when we upgrade to a new version of 
busybox, if the checksums change, we know we need to re-evaluate the 
license field. Its not a perfect check but it does catch basic mistakes
and we can easily check and reject patches where it hasn't been re-evaluated.

Our license handling predates SPDX, we are trying to align to SPDX identifiers.

My question is what to put in the recipe to identify the license?

We can easily put a "# SPDX-License-Identifier:" into the recipe but there
is a lot of concern about how people might interpret this. Our top
level license says unless otherwise stated, recipe metadata is MIT licensed
so the license is relatively clear. The worry is something like:

# SPDX-License-Identifier: MIT
LICENSE = "GPLv2 & bzip2-1.0.4"

makes for very confusing reading and can be badly interpreted.

I have some ideas about what we might have to do to make this really clear
but they have downsides. I wondered if there was any advice here on how
best to handle this? Once we know how to do it, marking up the recipes is 
relatively straightforward, we just need to establish what makes sense.

Also, there is a secondary problem of which license any patches we have
are under and what license identifier (if any) we should put in those.
Those would likely need to match the upstream project source they're patching
I'd imagine but I don't know if we want to mark up all the patches or not.

Cheers,

Richard
Re: How to start using only SDPX-License-Identifier tags

Philippe Ombredanne
 

Hi Warner:
See some comments below.

Hi Thomas:
This is FYI as you may be able to provide some insights and
recommendations based on the Linux kernel journey towards
SPDX that could help Warner and FreeBSD?

On Wed, Mar 17, 2021 at 11:11 PM Warner Losh <imp@...> wrote:
I'm looking at doing whatever it would take to create a framework so
that the FreeBSD project could use SPDX-License-Identifiers as the
sole designator of license.
Today, the project has SPDX tags in about 25k of 90k files in our
source tree. However, in all cases, the SPDX tag today is informative.
The actual license is contained in the file as well so there's no
ambiguity as to what the license is (we have an explicit statement
that says presently these tags are informative).

However, as more and more software is created using only these tags,
we've seen some pressure to accept this software. In addition, some
members have expressed the desire to be rid of all this tiresome
boilerplate at the start of every file.

So, I'm investigating how we can have something like

/*
* Copyright 2021 M. Warner Losh
* SPDX-License-Identifier: BSD-2-Clause
*/

become a valid license to use this file under whatever
BSD-2-Clause.txt says, with the proper values filled in.
[...]
I've seen the license matching guidelines. Those make sense for the
project's prior SPDX activity where we were adding informative tags to
existing licenses. However, I am having trouble how one could
unambiguously apply them to take the above copyright notice and
license and come up with something that I could show to our legal
department and that I'd have confidence any litigation around copying
of the file would start at (both as the copyright holder and also as a
company using this code).

When we added the informative tags to the FreeBSD tree, there was an
objection to that because of this and other issues. Since we said the
tags were merely informative and the actual license granted use, we
were able to dodge the issue at the time. As I prepare to start down
the path of turning something like the above into something the
project accepts, I have to return to questions like these and a
zillion others to get there.

I happened to have helped quite a bit for a similar effort for the Linux
kernel and as a FOSS license buff I can provide a few comments. I assume
that you are considering only the core FreeBSD source tree and not the
ports for now.

1. There were similar concerns brought up during this kernel effort.
Eventually folks came down to agree after heated discussions and
adjustments. The fact there were a few ultimate decision makers or tie
breakers surely helped quite a bit together with supports from lawyers
here. Thomas Gleixner (in CC) led the effort and may be able to provide
some comments too.

2. The FSFE Reuse [1] is a closely related spec that co-evolved with the
kernel efforts. It provides a good set of documentation and practices
that are not project-specific and could be adapted to the unique FreeBSD
context.

3. Beyond Linux and the pioneers of U-Boot, many projects now use and
accept SPDX license expressions and SPDX- License-Identifier. I made a
fairly extensive survey of related package metadata documentation
practices in my pending proposal to adopt SPDX expressions for Python
[2] which shows how prevalent things started to be.

4. Because of the above I would say that there are now established
community norms and practices that using SPDX-License-Identifier and
SPDX license expressions are acceptable ways to document licensing.
I do not know of any vocal objections from lawyers here and elsewhere.
Therefore, these norms are now the de-facto way things are done in
community at large.

5. The FreeBSD situation is different because there is a greater
number of licenses and origins at play because of all the different
packages. Nevertheless, the way things have been documented in the
kernel [3] may be a good start. You have similar documents for
FreeBSD [4], but not as detailed as Linux's and with one 404 [5]
Is your plan to start by proposing a new/updated "process" document
for FreeBSD? That would be my first step.

6. The FreeBSD license audit from ~ 2014 by Pedro Giffuni could be
refreshed to help. We could use scancode-toolkit [6] (that I maintain)
to help there. This could allow to classify the codebase based on the
different licenses and license documentation approaches and drive the
actual planning and efforts. And help with the file replacement tooling
suggested below...

7. On the mechanics of replacing license notices by SPDX identifiers
in source code, I have some (old) code that may help with this [7]
and would only need some minor love and care to be functional again.
This could mean automating large volumes of code changes.

8. BSD historical attribution notices are usually more than just a
copyright + a license notice, but often contain extra notices such as:

- This code is derived from software contributed to Berkeley by John
Doe.
- This code was contributed to The NetBSD Foundation by Jane Doe.
- or [8]: "Created by: Warner Losh <imp@...>"

You should document what you would want to do with these.

9. BSD historical licenses comes with many small variants of BSD and MIT
licenses (even in some case your own making [9] ;))
You should document what to do with these cases and in particular:

- should ALL the original name be kept when the text meets SPDX
matching-style guidelines? MO no

- define a process to resolve cases that are borderline and fall outside
the strict guidelines

- when should original authors be contacted, and what to do if they are
AWOL?

- when to submit a new license to SPDX? I suspect you will find a large
number of licenses that are unknown to SPDX. I would suggest to use
first a LicenseRef namespace like I do in [10] either scancode's or to
create your own first then funnel these as needed to SPDX. In my Linux
Kernel scans, I "discovered" several new and weird license variants
(several being franken-BSD and franken-MIT hybrids and mods). Many
were eventually added to the SPDX license list. It would be great to
have the same outcome for your FreeBSD effort!

10. When doing large commits to fix many files, Thomas Gleixner and Kate
Stewart enrolled several volunteers from this list -- several of them
legally trained -- to help review and sign-off on the changes. This was
helpful on so many levels. IMHO you should do the same for FreeBSD.

11. What would be your strategy? A trickle a few files at a time over
time, possibly grouped by package or authors/licenses? Or a few larger
tree-wide changes? The latter approach was used for Linux and we started
with grouping things based on the licensing documentation clarity. It
was large to swallow but once we were over the hump I think it made
things easier afterwards.

12. What's your plan for files with no explicit license and copyright?

I hope this long list of comments may help ... I did not have the time
to make them shorter!

[1] https://reuse.software/
[2] https://www.python.org/dev/peps/pep-0639/#appendix-3-surveying-how-other-package-formats-document-licenses
[3] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/process/license-rules.rst
[4] https://docs.freebsd.org/en_US.ISO8859-1/articles/committers-guide/pref-license.html
[5] https://docs.freebsd.org/internal/software-license.html
[6] https://github.com/nexB/scancode-toolkit
[7] https://github.com/nexB/scancode-toolkit/blob/833-espedexify/src/scancode/plugin_espedexify.py
[8] https://github.com/freebsd/freebsd-ports-kde/blob/68a0222b674a77c456b45e3784ad24447e1eba52/devel/p5-Acme-Damn/Makefile#L1
[9] https://github.com/freebsd/freebsd-src/blob/ba7ede0b9b3d0c3a64e6e7d8cbfe26b6f882f39f/UPDATING#L2434
[10] https://scancode-licensedb.aboutcode.org/

--
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombredanne@...
DejaCode - What's in your code?! - http://www.dejacode.com
AboutCode - Open source for open source - https://www.aboutcode.org
nexB Inc. - http://www.nexb.com
How to start using only SDPX-License-Identifier tags

Warner Losh
 

Greetings,

I have a ton of questions about how a project can go about doing this.

I'm looking at doing whatever it would take to create a framework so that the FreeBSD project could use SPDX-License-Idnetifiers as the sole designator of license.

Today, the project has SPDX tags in about 25k of 90k files in our source tree. However, in all cases, the SPDX tag today is informative. The actual license is contained in the file as well so there's no ambiguity as to what the license is (we have an explicit statement that says presently these tags are informative).

However, as more and more software is created using only these tags, we've seen some pressure to accept this software. In addition, some members have expressed the desire to be rid of all this tiresome boilerplate at the start of every file.

So, I'm investigating how we can have something like

/*
 * Copyright 2021 M. Warner Losh
 * SPDX-License-Identifier: BSD-2-Clause
 */

become a valid license to use this file under whatever BSD-2-Clause.txt says, with the proper values filled in. At first blush, in a friendly environment, it is easy. Common sense lets me do it. However, in a more hostile environment where people may try to construe ambiguity to their interest and against mine, I worry that any lack of clarity could cause problems. I have some other concerns as well, but this is the basic one. One reason I worry about this is that I've seen a journal article try to construe the archaic 'All Rights Reserved' into meaning something other than enabling language for this Buenos Aires Convention and imparting on it other, maybe nefarious meanings to cite a concrete example.

I've seen the license matching guidelines. Those make sense for the project's prior SPDX activity where we were adding informative tags to existing licenses. However, I am having trouble how one could unambiguously apply them to take the above copyright notice and license and come up with something that I could show to our legal department and that I'd have confidence any litigation around copying of the file would start at (both as the copyright holder and also as a company using this code).

When we added the informative tags to the FreeBSD tree, there was an objection to that because of this and other issues. Since we said the tags were merely informative and the actual license granted use, we were able to dodge the issue at the time. As I prepare to start down the path of turning something like the above into something the project accepts, I have to return to questions like these and a zillion others to get there.

Is there something I've missed that talks about this specifically? I have other questions as well, but these questions seem like a good place to start....

Thanks for your time and attention to this matter...

Warner
3.12 License List release

Steve Winslow
 

Hello all,

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

10 new licenses were added to the list:

In addition to various documentation cleanup and license markup edits, the CI system has been migrated from Travis CI to GitHub Actions.

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

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

Steve


--
Steve Winslow
VP, Compliance and Legal
The Linux Foundation
Meeting today, March 4

Steve Winslow
 

Hello SPDX legal team,

With apologies for the late reminder, the next regularly-scheduled SPDX legal team meeting will be today, Thursday, Feb. 4. It will be at our usual time of 9AM PST / noon EST, following the SPDX general meeting one hour earlier.

A big thank-you to Gary and William for sorting through the details of transitioning the license list CI setup from Travis CI to GitHub Actions. And a thank-you also to Gary for recent updates to the license list publisher tool.

With that now working, we are expecting to release version 3.12 of the license list likely this weekend. So the primary agenda for today's legal team call will be to finalize issues / PRs for inclusion in 3.12.

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
481 - 500 of 3408