License Infrastructure Interest Group: Difference between revisions
No edit summary |
|||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 10: | Line 10: | ||
* http://spdx.org/licenses/ for more info on common-license text and the Identifier field. | * http://spdx.org/licenses/ for more info on common-license text and the Identifier field. | ||
* | * http://spdx.org/ for more info on SPDX | ||
==LICENSE Field Standard== | ==LICENSE Field Standard== | ||
===Packages with known LICENSE issues=== | ===Packages with known LICENSE issues=== | ||
* none | |||
===Naming=== | ===Naming=== | ||
| Line 939: | Line 941: | ||
* Add licenses to the image as a conf option | * Add licenses to the image as a conf option | ||
* Possible (generate spdx license files as part of the manifest). SPDX or not, we need a manifest. | * Possible (generate spdx license files as part of the manifest). SPDX or not, we need a manifest. | ||
* We have some problematic licenses. [[License Audit]] | |||
==License v2 Plan== | ==License v2 Plan== | ||
| Line 946: | Line 950: | ||
* Incorporate a flag to allow the image to contain collected licenses. | * Incorporate a flag to allow the image to contain collected licenses. | ||
* Ensure that we've gotten rid of all license WARNINGS. (Add license text, correct recipes) | * Ensure that we've gotten rid of all license WARNINGS. (Add license text, correct recipes) | ||
* Create a way to add additional licenses. | |||
Stage Two - License decision making: | Stage Two - License decision making: | ||
* Check to see if the package license field contains an incompatible license. If it does, toss a warning. | * Check to see if the package license field contains an incompatible license. If it does, toss a warning. | ||
Latest revision as of 19:21, 30 May 2012
Overview
This group is for discussion of all things having to do with licenses, specifically, license wrangling, field parsing, possible SPDX implementation, etc.
- Contact Eflanagan for more info
SPDX
The Software Package Data Exchange® (SPDX™) specification is a standard format for communicating the components, licenses and copyrights associated with a software package. For the common-licenses used for the Yocto Project, we should, when possible, use the SPDX generic licenses for Yocto's license wrangling. As well, we should also use the SPDX Identifier field to identify the license fields within LICENSE
- http://spdx.org/licenses/ for more info on common-license text and the Identifier field.
- http://spdx.org/ for more info on SPDX
LICENSE Field Standard
Packages with known LICENSE issues
- none
Naming
All names should adhere to the textfile name of the common-license as defined in poky/meta/files/common-licenses. These file names follow the SPDX naming standard when an SPDX license file is available. If no SPDX file exists, we should:
- Attempt to get a generic license from the license provider
- Offer the generic upstream to SPDX (to be defined)
This following is a list of all liceneses currently registered with SPDX.
Licenses
| Full name | Identifier | Text |
|---|---|---|
| Academic Free License v1.1 | AFL-1.1 | |
| AFL-1.2 | ||
| AFL-2.0 | ||
| AFL-2.1 | ||
| APL-1.0 | ||
| Apache-1.0 | ||
| Apache-1.1 | ||
| Apache-2.0 | ||
| APSL-1.0 | ||
| APSL-1.1 | ||
| APSL-1.2 | ||
| APSL-2.0 | ||
| Artistic-1.0 | ||
| Artistic-2.0 | ||
| AAL | ||
| BSL-1.0 | ||
| BSD-2-Clause | ||
| BSD-3-Clause | ||
| BSD-4-Clause | ||
| CECILL-1.0 | ||
| CECILL-2.0 | ||
| CECILL-B | ||
| CECILL-C | ||
| ClArtistic | ||
| CDDL-1.0 | ||
| CPAL-1.0 | ||
| CPL-1.0 | ||
| CATOSL-1.1 | ||
| CC-BY-1.0 | ||
| CC-BY-2.0 | ||
| CC-BY-2.5 | ||
| CC-BY-3.0 | ||
| CC-BY-ND-1.0 | ||
| CC-BY-ND-2.0 | ||
| CC-BY-ND-2.5 | ||
| CC-BY-ND-3.0 | ||
| CC-BY-NC-1.0 | ||
| CC-BY-NC-2.0 | ||
| CC-BY-NC-2.5 | ||
| CC-BY-NC-3.0 | ||
|
Creative Commons Attribution Non Commercial No Derivatives 1.0 |
CC-BY-NC-ND-1.0 | |
|
Creative Commons Attribution Non Commercial No Derivatives 2.0 |
CC-BY-NC-ND-2.0 | |
|
Creative Commons Attribution Non Commercial No Derivatives 2.5 |
CC-BY-NC-ND-2.5 | |
|
Creative Commons Attribution Non Commercial No Derivatives 3.0 |
CC-BY-NC-ND-3.0 | |
| CC-BY-NC-SA-1.0 | ||
| CC-BY-NC-SA-2.0 | ||
| CC-BY-NC-SA-2.5 | ||
| CC-BY-NC-SA-3.0 | ||
| CC-BY-SA-1.0 | ||
| CC-BY-SA-2.0 | ||
| CC-BY-SA-2.5 | ||
| CC-BY-SA-3.0 | ||
| CUA-OPL-1.0 | ||
| EPL-1.0 | ||
| eCos-2.0 | ||
| ECL-1.0 | ||
| ECL-2.0 | ||
| EFL-1.0 | ||
| EFL-2.0 | ||
| Entessa | ||
| ErlPL-1.1 | ||
| EUDatagrid | ||
| EUPL-1.0 | ||
| EUPL-1.1 | ||
| Fair | ||
| Frameworx-1.0 | ||
| AGPL-3.0 | ||
| GFDL-1.2 | ||
| GFDL-1.2 | ||
| GFDL-1.3 | ||
| GPL-1.0 | ||
| GPL-1.0 | ||
| GPL-2.0 | ||
| GPL-2.0 | ||
| GPL-2.0-with-autoconf-exception | ||
| GPL-2-with-bison-exception | ||
| GPL-2.0-with-classpath-exception | ||
|
GNU General Public License v2.0 w/GCC Runtime Library exception |
GPL-2,0-with-GCC-exception | |
| GPL-2,0-with-font-exception | ||
| GPL-3.0 | ||
| GPL-3.0 | ||
| GPL-3.0-with-autoconf-exception | ||
|
GNU General Public License v3.0 w/GCC Runtime Library exception |
GPL-3.0-with-GCC-exception | |
| LGPL-2.1 | ||
| LGPL-2.1 | ||
| LGPL-3.0 | ||
| LGPL-3.0 | ||
| LGPL-2.0 | ||
| LGPL-2.0 | ||
| gSOAP-1.3b | ||
| HPND | ||
| IPL-1.0 | ||
| IPA | ||
| ISC | ||
| LPPL-1.0 | ||
| LPPL-1.1 | ||
| LPPL-1.2 | ||
| LPPL-1.3c | ||
| Libpng | ||
| LPL-1.02 | ||
| MS-PL | ||
| MS-RL | ||
| MirOS | ||
| MIT | ||
| Motosoto | ||
| MPL-1.0 | ||
| MPL-1.1 | ||
| Multics | ||
| NASA-1.3 | ||
| Nauman | ||
| NGPL | ||
| Nokia | ||
| NPOSL-3.0 | ||
| NTP | ||
| OCLC-2.0 | ||
| OGTSL | ||
| OSL-1.0 | ||
| OSL-2.0 | ||
| OSL-3.0 | ||
| OLDAP-2.8 | ||
| OpenSSL | ||
| PHP-3.0 | ||
| PostgreSQL | ||
| Python-2.0 | ||
| QPL-1.0 | ||
| RPSL-1.0 | ||
| RPL-1.5 | ||
| RHeCos-1.1 | ||
| RSCPL | ||
| Ruby | ||
| OFL-1.1 | ||
| Simple-2.0 | ||
| Sleepycat | ||
| SugarCRM-1.1.3 | ||
| SPL | ||
| Watcom-1.0 | ||
| NCSA | ||
| VSL-1.0 | ||
| W3C | ||
| WXwindows | ||
| Xnet | ||
| XFree86-1.1 | ||
| YPL-1.1 | ||
| Zimbra-1.3 | ||
| Zlib | ||
| ZPL-1.1 | ||
| ZPL-2.0 | ||
| ZPL-2.1 |
Parsing operations
The LICENSE field is parsed by converting the field to a Python Abstract Syntax Tree. ASTs are internal to the python compiler and are used by python in the generation of python bytecode. We create, from the LICENSE field after attempting to turn it more "pythonesque", an abstract syntax tree via ast.parse. Using an AST Visitor class, we then dump the ast and visit each node of the tree.
What this means is that, since we are using the python compiler components to parse the LICENSE field, it should be syntactically valid python.
License v2
Current License Issues
- Parallel bitbake causes inconsistent license reporting
- This is because we're doing this in the wrong place. During do_rootfs is where we need to do this as the package populates the rootfs.
- License decision making is non-existent
- Right now, we just grab all licenses listed in the license field. We need to have a decision made based on:
- Tie this in to incompatible license. If something is dual licensed and we *can* restrict this to a different license, do so
- License legal priority (Which license overrides another license?)
- License user priority (All things being equal try to provide something under X license first and Y license second)
- Right now, we just grab all licenses listed in the license field. We need to have a decision made based on:
- Add licenses to the image as a conf option
- Possible (generate spdx license files as part of the manifest). SPDX or not, we need a manifest.
- We have some problematic licenses. License Audit
License v2 Plan
Stage One - Fix current defects:
- Fix where the license collection occurs. This needs to occur during the creation of the rootfs.
- Ensure that we can use this during a parallel bitbake
- Incorporate a flag to allow the image to contain collected licenses.
- Ensure that we've gotten rid of all license WARNINGS. (Add license text, correct recipes)
- Create a way to add additional licenses.
Stage Two - License decision making:
- Check to see if the package license field contains an incompatible license. If it does, toss a warning.
- Check user/legal license priority.
- When given FOOv2 | BARv1, where the user has weighted BARv1 as higher than FOOv2, we would choose BAR.
- When given FOOv2 & BARv1, where FOOv2 overrides BARv1, use FOOv2 even if the user has weighted BARv1 as higher.
Stage Three - Manifest:
- As we do_rootfs we should:
- Check to see if the package has an SPDX meta-data file.
- If it does, use it.
- If it doesn't, generate one but mark it as automatically generated and not an official spdx file.
- Gather up spdx files into a work dir
- Check to see if the package has an SPDX meta-data file.
- Once the image is finished gather up all the spdx licenses and create an spdx manifest for the image
- Once the image is finished gather up all the spdx licenses and create a raw text manifest for the image
