Date   

Re: New on this mailing list, here's my introduction

Sebastian Crane
 

Dear Jonas,

timeszones are sooo tricky to get right - it's thistime, right?:
https://time.is/compare/1200_13_May_2021_in_ET
Yup, that's the one :)

Best wishes,

Sebastian


Re: New on this mailing list, here's my introduction

Jonas Smedegaard
 

Quoting Sebastian (2021-05-08 19:01:45)
You may like to know that our next meeting is next week; it is at
12:00 (US Eastern Time) on the 13th of May.
timeszones are sooo tricky to get right - it's thistime, right?:
https://time.is/compare/1200_13_May_2021_in_ET

- Jonas

P.S. I really like time.is to avoid confusion across timezomes.

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

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


Re: New on this mailing list, here's my introduction

Sebastian Crane
 

Dear Anthony,

My interest area as it pertains to SPDX-legal: these game communities
need lots of help with license compliance. One of my goals for this
year is to create a “game license compliance” knowledge base ...

I've also been working on an SPDX proposal that requires the steward's
approval. I'm very excited to be able to share that one in a couple
months!

I look forward to being part of the conversation at SPDX!
Welcome to the list! I too look forward to hearing more about your
project; it sounds like a great idea, and you have some impressive
numbers in the 'contributors' department!

You may like to know that our next meeting is next week; it is at 12:00
(US Eastern Time) on the 13th of May.

Best wishes,

Sebastian


Re: New on this mailing list, here's my introduction

Jonas Smedegaard
 

Hi Anthony,

Quoting Anthony Ronda (2021-05-07 21:57:52)
Hi, my name is Anthony! I’m a software engineer and small game
publisher in New Jersey. I'm one of several ringleaders at an open
source community for the creation of "virtual tabletop" game tools.
Our membership exploded in the pandemic, and we’re lucky to have an
amazing group of a couple hundred developers as well as artists and
game publishers from all around the world!
Wauw, sounds exciting!

My interest area as it pertains to SPDX-legal: these game communities
need lots of help with license compliance. One of my goals for this
year is to create a “game license compliance” knowledge base that my
community can quickly reference for well-researched facts from
existing credible sources. As a community, we're also creating build
tools that simplify the developer compliance experience so they can
focus on making great software/content/games. Naturally SPDX factors
into that in a big way.

I've also been working on an SPDX proposal that requires the steward's
approval. I'm very excited to be able to share that one in a couple
months!

I look forward to being part of the conversation at SPDX!
You might try get in touch with the Debian Games team - they do not
develop games but have experience with packaging games and as I have
heard games are particularly challenging to ensure only free licenses
are used: https://wiki.debian.org/Games/Team


- Jonas

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

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


New on this mailing list, here's my introduction

Anthony Ronda
 

Hi, my name is Anthony! I’m a software engineer and small game publisher in New Jersey. I'm one of several ringleaders at an open source community for the creation of "virtual tabletop" game tools. Our membership exploded in the pandemic, and we’re lucky to have an amazing group of a couple hundred developers as well as artists and game publishers from all around the world!


My interest area as it pertains to SPDX-legal: these game communities need lots of help with license compliance. One of my goals for this year is to create a “game license compliance” knowledge base that my community can quickly reference for well-researched facts from existing credible sources. As a community, we're also creating build tools that simplify the developer compliance experience so they can focus on making great software/content/games. Naturally SPDX factors into that in a big way.

I've also been working on an SPDX proposal that requires the steward's approval. I'm very excited to be able to share that one in a couple months!


I look forward to being part of the conversation at SPDX!


Github contributors

J Lovejoy
 

Hi legal folks,

Steve and I are doing a bit of clean-up on the SPDX License List Github repo to make sure everyone has the right access to easily be able to contribute there. A bunch of you will have gotten some kind of invite to have “read” access today.

If you have been or would like to contribute to the Github issues and don’t think you have the right access, please email Steve and I with your Github username.

Thanks!
Jilayne


Re: Any change requests for the license list publisher?

J Lovejoy
 

Hi Gary,

We had some updated text for the description of deprecated licenses which goes on the license list landing page. Should I simply make a pull request in the license-list-publisher repo?

Thanks!
Jilayne

On 4/29/21 10:21 AM, Gary O'Neall wrote:

I am working on a minor update to the license list publisher (the tool used to publish the license list to license-list-data and the website).

 

If there are any changes to the website text, wording or request for fixes to the license list data generation please let me know by the end of the week and I’ll try to get the changes in before the next release of the license list.


Thanks,
Gary

 

-------------------------------------------------

Gary O'Neall

Principal Consultant

Source Auditor Inc.

Mobile: 408.805.0586

Email: gary@...

CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.

 



Any change requests for the license list publisher?

Gary O'Neall
 

I am working on a minor update to the license list publisher (the tool used to publish the license list to license-list-data and the website).

 

If there are any changes to the website text, wording or request for fixes to the license list data generation please let me know by the end of the week and I’ll try to get the changes in before the next release of the license list.


Thanks,
Gary

 

-------------------------------------------------

Gary O'Neall

Principal Consultant

Source Auditor Inc.

Mobile: 408.805.0586

Email: gary@...

CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.

 


meeting today!

J Lovejoy
 

Hi all,

Just a reminder that we have our regular call today at 10am MDT. We will focus on wrapping up as much as we can for the next release.  Please have a look at the issues labeled for 3.13 if you have a few minutes prior to the call.

Thanks,
Jilayne

Conference call info:


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


documentation updates

J Lovejoy
 

Hi all,

I just made a couple PRs to improve some of our documentation in the Github repo as per prior discussions. It'd be great to get some eyeballs on that and comments as to any other improvements, especially from some of our newer participants!

see:
https://github.com/spdx/license-list-XML/pull/1238

https://github.com/spdx/license-list-XML/pull/1241

https://github.com/spdx/license-list-XML/pull/1240 


Thanks!
Jilayne


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

341 - 360 of 3278