Date   

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


Meeting today, Feb. 18

Steve Winslow
 

Hello SPDX legal team,

The next regularly-scheduled SPDX legal team meeting will be today, Thursday, Feb. 18, at our usual time of 9AM PST / noon EST.

The primary agenda will be finalizing on issues and PRs for 3.12.

The 3.12 release is currently targeted to be this weekend. However, we are sorting through some issues with the CI setup for validating and publishing the license templates, so it is possible that this date will be pushed back as a result. We will keep you informed on further updates.

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


Meeting tomorrow, Feb. 4

Steve Winslow
 

Hello SPDX legal team,

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

The primary agenda for the legal team call with focus on reviewing current status of issues for 3.12.

For the 3.12 release, we made the decision to push the target release date out from end of January to current target of February 19. There are some problems we are sorting through with the existing CI setup for validating and publishing the license templates, so it is possible that this date will be pushed back further as a result. We will keep this list informed on further updates.

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
Director of Strategic Programs
The Linux Foundation


Invitation: SPDX legal team meeting @ Every 2 weeks from 12pm to 1pm on Thursday from Thu Jan 7 to Fri Dec 31 (EST) (spdx-legal@lists.spdx.org)

Steve Winslow
 

You have been invited to the following event.

SPDX legal team meeting

When
Every 2 weeks from 12pm to 1pm on Thursday from Thu Jan 7 to Fri Dec 31 Eastern Time - New York
Where
https://zoom.us/j/93441586616?pwd=R3hINWNvZ3ZWOUw5Q21peHF2Y3o5QT09 (map)
Calendar
spdx-legal@...
Who
swinslow@... - organizer
spdx-legal@...
Steve Winslow is inviting you to a scheduled Zoom meeting.

Join Zoom Meeting
https://zoom.us/j/93441586616?pwd=R3hINWNvZ3ZWOUw5Q21peHF2Y3o5QT09

Meeting ID: 934 4158 6616

Passcode: 681480
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

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

Invitation from Google Calendar

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

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

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


No meeting today

Steve Winslow
 

Hello all, just a reminder that we will _not_ be having an SPDX legal team meeting today due to the holiday.

Happy new year!
Steve

--
Steve Winslow
Director of Strategic Programs
The Linux Foundation


Re: [spdx-tech] About Generate Java SPDX Model Classes from XML XSD file

J Lovejoy
 

Hi Gary, Bhavya,

I too do all my SPDX-related work on my laptop/desktop setup. I’d be curious to hear if there are others who use their mobile.

Thanks,
Jilayne
SPDX legal team co-lead

On Dec 29, 2020, at 10:26 AM, Gary O'Neall <gary@...> wrote:

Hi Bhavya,
 
I’ll open this question up to the broader community.  Adding the SPDX legal workgroup to the thread.
 
Is there any interest in a more mobile friendly set of SPDX tools?  
 
I typically use the SPDX online tools from a desktop, so I don’t know if there is a need or any issues accessing it from a phone.  SPDX tech and legal – feel free to reply if you see the possibility of a project idea in this area.

Thanks,
Gary
 
From: Spdx-tech@... <Spdx-tech@...> On Behalf Of Bhavya Jain
Sent: Tuesday, December 29, 2020 3:38 AM
To: Gary O'Neall <gary@...>
Cc: Spdx-tech@...
Subject: Re: [spdx-tech] About Generate Java SPDX Model Classes from XML XSD file
 
Thank you for the information. So sir can i just contribute in a different way to the community as an android developer(Maybe to change some layouts as front end developer or to work on the code of particular android project)
Please let me know about this 
Thank you in advance
 
On Mon, 28 Dec 2020 at 22:53, Gary O'Neall <gary@...> wrote:
Hi Bhavya,
 
Thanks for your interest in the SPDX GSoC projects.
 
The Generate Java SPDX Model Classes project was actually from last year’s GSoC.  We haven’t updated this year’s GSoC project ideas page yet.  We will update the project ideas over the next month prior to the organization submissions for the Google Summer of Code 2021.
 
In the interim, do feel free to browse the SPDX project in github.com/spdx repositories to familiarize yourself with the various projects and technologies used.
 
Best regards,
Gary
 
From: Spdx-tech@... <Spdx-tech@...> On Behalf Of Bhavya Jain
Sent: Monday, December 28, 2020 6:47 AM
To: Spdx-tech@...
Subject: [spdx-tech] About Generate Java SPDX Model Classes from XML XSD file
 
Hello everyone, I am Bhavya Jain 2nd year student at IIT(ISM) Dhanbad. I am an intermediate android developer(good front end developer) and what to contribute in SPDX project. But I make XML files only from android studio so I need to know that am I eligible to contribute to the above project mentioned?.
Please let me know about this.
Thank you in advance.



Re: [spdx-tech] About Generate Java SPDX Model Classes from XML XSD file

Gary O'Neall
 

Hi Bhavya,

 

I’ll open this question up to the broader community.  Adding the SPDX legal workgroup to the thread.

 

Is there any interest in a more mobile friendly set of SPDX tools? 

 

I typically use the SPDX online tools from a desktop, so I don’t know if there is a need or any issues accessing it from a phone.  SPDX tech and legal – feel free to reply if you see the possibility of a project idea in this area.


Thanks,
Gary

 

From: Spdx-tech@... <Spdx-tech@...> On Behalf Of Bhavya Jain
Sent: Tuesday, December 29, 2020 3:38 AM
To: Gary O'Neall <gary@...>
Cc: Spdx-tech@...
Subject: Re: [spdx-tech] About Generate Java SPDX Model Classes from XML XSD file

 

Thank you for the information. So sir can i just contribute in a different way to the community as an android developer(Maybe to change some layouts as front end developer or to work on the code of particular android project)

Please let me know about this

Thank you in advance

 

On Mon, 28 Dec 2020 at 22:53, Gary O'Neall <gary@...> wrote:

Hi Bhavya,

 

Thanks for your interest in the SPDX GSoC projects.

 

The Generate Java SPDX Model Classes project was actually from last year’s GSoC.  We haven’t updated this year’s GSoC project ideas page yet.  We will update the project ideas over the next month prior to the organization submissions for the Google Summer of Code 2021.

 

In the interim, do feel free to browse the SPDX project in github.com/spdx repositories to familiarize yourself with the various projects and technologies used.

 

Best regards,
Gary

 

From: Spdx-tech@... <Spdx-tech@...> On Behalf Of Bhavya Jain
Sent: Monday, December 28, 2020 6:47 AM
To: Spdx-tech@...
Subject: [spdx-tech] About Generate Java SPDX Model Classes from XML XSD file

 

Hello everyone, I am Bhavya Jain 2nd year student at IIT(ISM) Dhanbad. I am an intermediate android developer(good front end developer) and what to contribute in SPDX project. But I make XML files only from android studio so I need to know that am I eligible to contribute to the above project mentioned?.

Please let me know about this.

Thank you in advance.


Meeting today, Dec. 17

Steve Winslow
 

Hello SPDX legal team,

The next regularly-scheduled SPDX legal team meeting will be today, Thursday, Dec. 17, at our usual time of 9AM PST / noon EST.

I expect that today's meeting will be short, as a lot of people are finishing up end-of-year matters. We'll focus on any questions or discussion topics that folks are running into as you're working on issues for 3.12.

Thanks,
Steve

= = = = =

Join Zoom Meeting
https://zoom.us/j/94885520778?pwd=Wm5LVzhjU1ZaQkdQZVpibjBKSUtYUT09

Meeting ID: 948 8552 0778
Passcode: 708594

One tap mobile
+13017158592,,94885520778# US (Germantown)
+13126266799,,94885520778# US (Chicago)

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



--
Steve Winslow
Director of Strategic Programs
The Linux Foundation

361 - 380 of 3281