License Infrastructure Interest Group: Difference between revisions
(→SPDX) |
No edit summary |
||
Line 925: | Line 925: | ||
What this means is that, since we are using the python compiler components to parse the LICENSE field, it should be syntactically valid python. | 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 issues with license that need to be addressed: | |||
* 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) | |||
* 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. |
Revision as of 01:20, 20 October 2011
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.research paper.org/ for more info on SPDX
LICENSE Field Standard
Packages with known LICENSE issues
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 issues with license that need to be addressed:
- 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)
- 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.