Consider new License Categories

[DennisClark]

Short Description

Expand the AboutCode License Category definitions to include significant new variants of license trends.

How This Feature will help you/others

Identify and understand emerging license trends.

Possible Solution/Implementation Details

This enhancement would directly impact dejacode, scancode-toolkit, scancode.io, and LicenseDB.
Define and describe new categories. Assign them to new and existing licenses. Some possibilities include:

• AI (or LLM or Model)
• Ethical
• others to be determined

For reference, here are the current License Category definitions:

License Category	Description	License Type
CLA	A Contributor License Agreement (CLA) describes and defines the contribution acceptance rules for the ongoing development and enhancement of a software project. The CLA may specify how the resulting software contribution itself will be licensed.	Open Source
Commercial	Third-party proprietary software offered under a direct commercial license between supplier and customer. Further fact-finding by Product Teams will be necessary to determine the code's license status and function, if any.	Closed Source
Copyleft	Open source software with a "copyleft" license that offers irrevocable permission to the public to copy and redistribute the work in the same or modified form, but with the conditions that all such redistributions make the work available in a form that facilitates further modification and use the same license terms. A copyleft license can require code interacting with copyleft-licensed code to be licensed the same way.	Open Source
Copyleft Limited	A license that requires you to redistribute source code, including your changes, and also to provide attribution for the software authors. Your obligation to redistribute source code, including proprietary code linked with code under this license, is limited according to license-specific rules.	Open Source
Free Restricted	A Permissive-style license, that contains restrictions regarding the usage of the software (for example, where the software is not intended for use in nuclear power plants) or the redistribution of the software (for example, where commercial redistribution of the software is not allowed without express permission). The Free Software Foundation (FSF) says that a license with this kind of restriction is not really open source, although the OSI point of view is not that strict.	Closed Source
Patent License	A license that applies to patents rather than specific software. May be used in conjunction with other software license(s) that apply to a software component.	Open Source
Permissive	Open Source software that is made available under "non-copyleft" licenses. These generally require attribution of the included open source and may include other obligations.	Open Source
Proprietary Free	Proprietary Free software that may not require a commercial license but may have specific terms and conditions which Product Teams are obligated to follow. Some of these terms and conditions are provided with or in the code or in clickable downloaded licenses. Examples are the Sun Binary Code License Agreement or a freely offered BSP.	Closed Source
Public Domain	Open source software that is made available without explicit obligations, but which has a license notice that must be kept with the code per organization policy. The match may be to software, code examples on a website, published public domain specifications or another type of publication.	Open Source
Source-available	Source-available software is software released through a source code distribution model that includes arrangements where the source can be viewed, and in some cases modified, but without necessarily meeting the criteria to be called open-source.	Closed Source
Unstated License	Third-party software that has a copyright notice, but no stated license. Common examples include code snippets from publications and websites (such as those from O'Reilly Media). The absence of a license poses a risk that the copyright owner may assert license obligations at some future time. Product Teams may need to contact the copyright owner to determine the license obligations, if any.	N/A

[DennisClark]

The main distinction of an "AI" License is that the terms usually apply to an AI service (LLM, Models, etc) accessed via API, sometimes accompanied by specific software tools for that purpose. Since the actual terms of AI licenses vary significantly, it may be useful to define two AI license categories:

• AI-Proprietary A license to access AI services, often accompanied by volume limitations or usage restrictions. This is the most common type of AI license. The restrictions are often defined in an additional reference document, publicly posted and subject to revisions.
• AI-Open A license to access AI services without volume limitations or usage restrictions. There may be special attribution obligations, but these do not make the license closed.

[DennisClark]

Ethical license terms of use may be embedded in or appended to a more standard license and, since they impose usage restrictions on the software, are not open source but rather proprietary. Some ethical licenses are defined in a reference document separate from associated license(s), and are often publicly posted and subject to revisions independently of the associated license(s). The ethical restrictions are most often concerned with human rights and "fair use"; references to environmental impact are very rare.

[DennisClark]

Some further thoughts:

• Ethical is probably not a good candidate for a License Category, mainly because there is so much overlap with other Categories. In DejaCode, we could introduce it as a "License Tag".
• ML (for Machine Learning) might be a better term than AI for new Categories ML-Proprietary and ML-Open.
• Question: Do we need, or is there a significant value, to creating Service-Proprietary and Service-Open License Categories to distinguish them from software licenses? Should we do something similar for Data licenses?