Obligations by Open Source License

• 1: AGPL-3.0 Guide
• 2: Apache-2.0 Guide
• 3: BigScience RAIL Guide
• 4: BSD-2-Clause Guide
• 5: BSD-3-Clause Guide
• 6: BSD-4-Clause Guide
• 7: BSL Guide
• 8: CDDL-1.0 Guide
• 9: CreativeML Open RAIL-M Guide
• 10: Elastic License 2.0 Guide
• 11: EPL-2.0 Guide
• 12: GPL-2.0 Guide
• 13: GPL-3.0 Guide
• 14: LGPL-2.1 Guide
• 15: LGPL-3.0 Guide
• 16: Llama 2 Community License Guide
• 17: MIT Guide
• 18: MPL-2.0 Guide
• 19: SSPL Guide

1 - AGPL-3.0 Guide

SPDX Identifier: AGPL-3.0-only or AGPL-3.0-or-later

License Statement in Source Code

Open source under the AGPL-3.0 license generally carries the following statement at the top of the source code.

Copyright (C) <year> <name of author>
 
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU Affero General Public License as
published by the Free Software Foundation, either version 3 of the
License, or (at your option) any later version.
 
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU Affero General Public License for more details.
 
You should have received a copy of the GNU Affero General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.

Obligations by Use Case

Case 1. Redistribution in Source Form

When redistributing open source under the AGPL-3.0 license in source form, observe the following.

1-1 Notice Obligation

• Provide the copyright notice
• Provide the warranty disclaimer
• Provide a copy of the license

In other words, redistribute while keeping the copyright/license information stated in the source code intact.

Case 2. Redistribution in Binary Form

When building open source under the AGPL-3.0 license and redistributing it in binary form only, observe the following.

2-1 Notice Obligation

• Provide the copyright notice
• Provide the warranty disclaimer
• Provide a copy of the license

Generate an open source notice containing the above and enclose it when redistributing the binary.

2-2 Source Code Provision Obligation

Provide the source code corresponding to the binary. In doing so, observe the following.

1. AGPL-3.0 requires that derivative works also be licensed under AGPL-3.0 and have their source code disclosed. Referring to the content below, disclose the source code of the AGPL-3.0 open source and its derivative works.

2. Provide a build environment that allows binary users to build an identical binary from the disclosed source code. This includes the following.
   • Tool chain information
   • Build scripts
   • Build instructions (README)

Instead of the source code, you may provide a Written Offer. It must include the following statements.

1. The Written Offer is valid for three years after the product is sold.
2. It is offered to anyone.
3. No fee is charged. (excluding the cost incurred for delivering the source)

2-3 Installation Information Obligation

If the binary is distributed together with a User Product, provide the Installation Information.

• User Product: An embedded device such as an electronic device
• Installation Information: All information and methods the user needs to build the source code and reinstall it on the product

Case 3. Remote Network Interaction

If you (1) modify open source under the AGPL-3.0 license and (2) the modified version interacts with remote users over a network:

• You must provide a network server from which remote users can download the source code of the modified version.
• The source code here is the same in scope as that required in “2-2. Source Code Provision Obligation” above.

Differences from GPL-3.0

AGPL-3.0 is a license that adds a network use clause to GPL-3.0.

• GPL-3.0: Source code disclosure obligation only when distributing binaries
• AGPL-3.0: Source code disclosure obligation when distributing binaries AND when providing a service over a network

This clause is intended to prevent circumvention of GPL’s source code disclosure obligation by providing software as SaaS or a cloud service.

License Compatibility

Compatibility with Major Licenses

References

• AGPL-3.0 License Full Text
• SPDX License List - AGPL-3.0
• GNU AGPL FAQ
• OSADL License Checklist

2 - Apache-2.0 Guide

SPDX Identifier: Apache-2.0

License Statement in Source Code

Open source under the Apache-2.0 license generally carries the following statement at the top of the source code.

Copyright [yyyy] [name of copyright owner]
 
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
 
http://www.apache.org/licenses/LICENSE-2.0
 
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

Obligations by Use Case

Case 1. Redistribution in Source Form

When redistributing open source under the Apache-2.0 license in source form, observe the following.

1-1 Notice Obligation

• Provide a copy of the license
• Retain information such as copyright, patent, and trademark notices.
• If a NOTICE file is included, retain it.

In other words, redistribute while keeping the copyright/license information stated in the source code intact.

Case 2. Redistribution in Binary Form

When building open source under the Apache-2.0 license and redistributing it in binary form only, observe the following.

2-1 Notice Obligation

• Provide a copy of the license
• Retain information such as copyright, patent, and trademark notices.
• If a NOTICE file is included, retain it.

Generate an open source notice containing the above and enclose it when redistributing the binary.

License Compatibility

The Apache-2.0 license includes an explicit patent grant clause, making it compatible with most licenses.

Compatibility with Major Licenses

References

• Apache License 2.0 Full Text
• SPDX License List - Apache-2.0
• OSADL License Checklist

3 - BigScience RAIL Guide

SPDX Identifier: BigScience-RAIL-1.0

What Is BigScience RAIL?

BigScience RAIL (Responsible AI License) is a license that the BigScience project released in 2022 together with the BLOOM language model.

The BigScience Project

• BLOOM: A 176B-parameter multilingual language model
• More than 1,000 researchers participated
• Set responsible AI development as a core value

Two Versions of RAIL

BigScience uses RAIL-M (applied only to the model)

Major Projects Using It

The BLOOM Family

• BLOOM: BigScience’s 176B model
• BLOOMZ: An instruction-following version
• mT0: A multilingual zero-shot model

Other Models Adopting RAIL

• Some open LLM fine-tuned models
• Research language models

Permitted Items

What You Can Do Freely

1. Model use

   • Text generation
   • Translation, summarization, question answering
   • Building chatbots
   • Providing commercial services

2. Model modification

   • Fine-tuning
   • Additional training
   • Lightweighting such as LoRA, QLoRA

3. Model distribution

   • Releasing modified models
   • Distributing derivative models
   • Commercial API services

4. Use of generated outputs

   • Commercial use of AI-generated text
   • Creating secondary works

Prohibited Items (Restrictions)

BigScience RAIL cannot be used for the following purposes:

1. Illegal Activities

• Supporting the planning or execution of crimes
• Generating illegal content
• Supporting terrorist activities

2. Child Protection

• Generating child sexual exploitation material
• Harmful content targeting children
• Supporting child grooming

3. Discrimination and Hate

• Discrimination based on race, ethnicity, or religion
• Discrimination based on gender or sexual orientation
• Discrimination based on disability or age
• Generating hate speech

4. Disinformation and Manipulation

• Intentionally generating fake news
• Generating deepfake text (for identity theft)
• Content for election manipulation
• Content for fraud

5. Privacy Violations

• Unauthorized collection of personal information
• Supporting stalking and harassment
• Use for surveillance purposes

6. Medical and Legal

• Replacing professional medical diagnosis
• Replacing legal advice
• Replacing financial advice

7. Self-Harm and Violence

• Encouraging suicide or self-harm
• Inciting violence
• Weapons manufacturing information

8. High-Risk Decision-Making

• Automated credit scoring (sole decision-making)
• Automated hiring decisions (sole decision-making)
• Criminal justice decisions (sole decision-making)

Use Scenarios

Permitted Uses

1. Chatbot Service

Scenario: A customer consultation chatbot
Method of use: Fine-tuning BLOOM to build a consultation bot
Judgment: Allowed (commercial use is OK, not a prohibited use)

2. Translation Service

Scenario: Multilingual automatic translation
Method of use: Leveraging BLOOM’s multilingual capability
Judgment: Allowed

3. Content Generation Tool

Scenario: A marketing copy generation tool
Method of use: BLOOM-based text generation
Judgment: Allowed (when not discriminatory/false content)

Prohibited Uses

1. Fake News Generator

Scenario: An automatic fake news generation tool
Method of use: Mass generation of disinformation
Judgment: Prohibited (generating disinformation)

2. Generating Discriminatory Content

Scenario: Generating text that demeans a specific group
Method of use: Generating hate speech
Judgment: Prohibited (discrimination and hate)

3. Automated Credit Scoring

Scenario: Automatically determining credit scores with an LLM
Method of use: Automatic approval/denial of loans
Judgment: Prohibited (high-risk decision-making)

Requires Review

1. Educational Chatbot

Scenario: A student counseling chatbot
Method of use: Career counseling, psychological counseling
Judgment: At the boundary of medical/psychological advice, expert review required

2. Hiring Assistance Tool

Scenario: Resume screening assistance
Method of use: A human makes the final decision, but the AI recommends
Judgment: Depends on the method of use, OSPO review

Model Card Obligation

BigScience RAIL recommends providing a Model Card.

Content to Include in the Model Card

1. Model information

   • Model architecture, number of parameters
   • Source of training data
   • Training method

2. Limitations

   • The model’s limitations
   • Known bias
   • Inappropriate use cases

3. Usage guide

   • Recommended use cases
   • Prohibited items
   • Ethical considerations

Example: BLOOM Model Card

Licensing of Derivative Models

When distributing a derivative model:

Mandatory Items

• Apply the same use restrictions
• State the license information
• Provide a model card (recommended)

License Propagation

If you create a custom model by fine-tuning BLOOM, you must apply BigScience RAIL or equivalent restrictions to the custom model as well.

Responsibility for AI-Generated Outputs

Important: Responsibility for Generated Text

• Model provider: Obligation to state model use restrictions
• Model user: Obligation to verify the legality of generated outputs
• Service provider: Obligation to take measures to prevent users’ misuse

References

• BigScience RAIL-1.0 Full Text
• SPDX License List - BigScience-RAIL-1.0
• BLOOM Model Card
• Responsible AI Licenses Initiative

4 - BSD-2-Clause Guide

SPDX Identifier: BSD-2-Clause

License Statement in Source Code

Open source under the BSD-2-Clause license generally carries the following statement at the top of the source code.

Copyright (c) <YEAR>, <OWNER>
All rights reserved.
 
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
 
1. Redistributions of source code must retain the above copyright notice, this
list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
 
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Obligations by Use Case

Case 1. Redistribution in Source Form

When redistributing open source under the BSD-2-Clause license in source form, observe the following.

1-1 Notice Obligation

• Copyright notice
• Provide a copy of the license
• Warranty disclaimer notice

In other words, keep the copyright, license, and so on within the source code intact.

Case 2. Redistribution in Binary Form

When building open source under the BSD-2-Clause license and redistributing it in binary form only, observe the following.

2-1 Notice Obligation

• Copyright notice
• Provide a copy of the license
• Warranty disclaimer notice

Generate an open source notice containing the above and enclose it when redistributing the binary.

License Compatibility

The BSD-2-Clause license is the most concise among the BSD licenses and is compatible with most licenses.

Compatibility with Major Licenses

References

• BSD-2-Clause License Full Text
• SPDX License List - BSD-2-Clause
• OSADL License Checklist

5 - BSD-3-Clause Guide

SPDX Identifier: BSD-3-Clause

License Statement in Source Code

Open source under the BSD-3-Clause license generally carries the following statement at the top of the source code.

Copyright (c) <year>, <copyright holder>
All rights reserved.
 
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
 
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
* Neither the name of the <organization> nor the
names of its contributors may be used to endorse or promote products
derived from this software without specific prior written permission.
 
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL <COPYRIGHT HOLDER> BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Obligations by Use Case

Case 1. Redistribution in Source Form

When redistributing open source under the BSD-3-Clause license in source form, observe the following.

1-1 Notice Obligation

• Copyright notice
• Provide a copy of the license
• Warranty disclaimer notice

In other words, keep the copyright, license, and so on within the source code intact.

Case 2. Redistribution in Binary Form

When building open source under the BSD-3-Clause license and redistributing it in binary form only, observe the following.

2-1 Notice Obligation

• Copyright notice
• Provide a copy of the license
• Warranty disclaimer notice

Generate an open source notice containing the above and enclose it when redistributing the binary.

License Compatibility

The BSD-3-Clause license includes a clause prohibiting unauthorized use of the organization’s name and is compatible with most licenses.

Compatibility with Major Licenses

References

• BSD-3-Clause License Full Text
• SPDX License List - BSD-3-Clause
• OSADL License Checklist

6 - BSD-4-Clause Guide

SPDX Identifier: BSD-4-Clause

License Statement in Source Code

Open source under the BSD-4-Clause license generally carries the following statement at the top of the source code.

Copyright (c) <year>, <copyright holder>
All rights reserved.
 
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
 
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software
must display the following acknowledgement:
This product includes software developed by the <organization>.
4. Neither the name of the <organization> nor the
names of its contributors may be used to endorse or promote products
derived from this software without specific prior written permission.
 
THIS SOFTWARE IS PROVIDED BY <COPYRIGHT HOLDER> ''AS IS'' AND ANY
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL <COPYRIGHT HOLDER> BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Obligations by Use Case

Case 1. Redistribution in Source Form

When redistributing open source under the BSD-4-Clause license in source form, observe the following.

1-1 Notice Obligation

• Copyright notice
• Provide a copy of the license
• Warranty disclaimer notice
• Include the following statement in all advertising that mentions features or use of the BSD-4-Clause open source
  “This product includes software developed by the <organization>."

In other words, keep the copyright, license, and so on within the source code intact.

Case 2. Redistribution in Binary Form

When building open source under the BSD-4-Clause license and redistributing it in binary form only, observe the following.

2-1 Notice Obligation

• Copyright notice
• Provide a copy of the license
• Warranty disclaimer notice
• Include the following statement in all advertising that mentions features or use of the BSD-4-Clause open source
  “This product includes software developed by the <organization>."

Generate an open source notice containing the above and enclose it when redistributing the binary.

License Compatibility

Due to the advertising clause, BSD-4-Clause has compatibility issues with other licenses.

Compatibility with Major Licenses

References

• BSD-4-Clause License Full Text
• SPDX License List - BSD-4-Clause
• OSADL License Checklist

7 - BSL Guide

SPDX Identifier: BUSL-1.1 (also referred to as BSL-1.1)

What Is BSL?

BSL (Business Source License) is a license created by MariaDB Corporation in 2013. Its core characteristic is that it is a time-limited license.

How It Works

1. Initial period (before the Change Date)

   • Certain commercial uses are restricted
   • The source code is publicly available
   • Non-commercial/internal use is generally permitted

2. Conversion period (after the Change Date)

   • Automatically converts to a true open source license
   • Usually converts to Apache-2.0, GPL-2.0, MIT, etc.
   • All restrictions are lifted

The Three Main Parameters of BSL

1. Additional Use Grant

Specifies the particular uses that are permitted.

Examples:

• “Services with 1,000 or fewer annual users are permitted”
• “Free use is allowed in non-production environments”
• “Use for the purpose of providing a competing service is prohibited”

2. Change Date

The date on which it converts to open source. Typically set to 3-4 years after release.

Example: If released on January 1, 2024, the Change Date is January 1, 2028.

3. Change License

The open source license it will convert to.

Typically:

• Apache-2.0 (most common)
• GPL-2.0
• MIT

Major Projects Adopting BSL

Databases

• MariaDB (some features): Change License GPL-2.0, Change Date 4 years after release
• CockroachDB: Change License Apache-2.0 or MIT, Change Date 3 years after release

Others

• Ceph (some features)
• MinIO (some editions)
• Sentry (some features)
• Akka (since 2.7)

Determining Whether Use Is Permitted

Cases Generally Permitted

1. Internal development/testing

   • In-house development environments
   • Test servers
   • Prototype development

2. Non-production uses

   • Learning/research
   • Benchmarking
   • Proof of Concept (PoC)

3. Cases specified in the Additional Use Grant

Cases That Are Restricted

1. Commercial production use

   • Services provided to customers
   • Inclusion in and sale of a product
   • Provision as SaaS

2. Providing a competing service

   • Providing a service that competes with the BSL software

Cases Requiring Verification

Because the Additional Use Grant differs for each project, checking the LICENSE file of each project is essential.

Use After the Change Date

Once the Change Date passes, it automatically converts to the Change License.

Example: CockroachDB v20.1 (released May 2020)

• Change Date: May 19, 2023
• Change License: Apache-2.0
• From May 19, 2023, it can be used freely under Apache-2.0

References

• BSL 1.1 Full Text
• SPDX License List - BUSL-1.1
• MariaDB BSL FAQ
• CockroachDB Licensing FAQs

8 - CDDL-1.0 Guide

SPDX Identifier: CDDL-1.0

Obligations by Use Case

Case 1. Redistribution in Source Form

When redistributing open source under the CDDL-1.0 license in source form, observe the following.

1-1 Notice Obligation

• A copy of the license
• Retain legal notices such as copyright, patent, and trademark notices

In other words, redistribute while keeping the copyright/license information stated in the source code intact.

Case 2. Redistribution in Binary Form

When building open source under the CDDL-1.0 license and redistributing it in binary form only, observe the following.

2-1 Notice Obligation

• Provide a copy of the license
• Retain legal notices such as copyright, patent, and trademark notices

Generate an open source notice containing the above and enclose it when redistributing the binary.

2-2 Source Code Provision Obligation

Provide the source code files that fall under CDDL-1.0 within the binary. In doing so, observe the following.

• CDDL-1.0 requires that content added within a file also be licensed under CDDL-1.0 and have its source code disclosed. Therefore, disclose the modified files as well as the original files under CDDL-1.0.

You can fulfill the source code provision obligation by informing users in the open source notice of how they can obtain the source code.

MPL-Based License

CDDL-1.0 is a license created by Sun Microsystems (now Oracle) based on the Mozilla Public License (MPL).

• MPL similarity: Per-file Copyleft applies
• Main usage: Sun/Oracle projects (OpenSolaris, GlassFish, etc.)
• Current status: The use of CDDL is currently in decline

License Compatibility

Compatibility with Major Licenses

References

• CDDL-1.0 License Full Text
• SPDX License List - CDDL-1.0
• OSADL License Checklist

9 - CreativeML Open RAIL-M Guide

SPDX Identifier: CreativeML-OpenRAIL-M

What Is CreativeML Open RAIL-M?

CreativeML Open RAIL-M (Responsible AI License - Model) is an AI model license released in 2022 together with Stable Diffusion.

Characteristics of RAIL (Responsible AI License)

1. Open: Anyone can use it freely
2. Responsible: Restrictions for responsible use
3. Permissive: Allows commercial use, like Apache-2.0
4. Use-Based Restrictions: Restrictions based on use

Differences from General Open Source Licenses

Major Projects Using It

Stable Diffusion

• Stable Diffusion v1.x: CreativeML Open RAIL-M
• Stable Diffusion v2.x: CreativeML Open RAIL++-M (improved version)
• Stable Diffusion XL: CreativeML Open RAIL++-M

Other Image Generation Models

• Waifu Diffusion
• DreamBooth fine-tuned models

What Is Permitted

What You Can Do Freely

1. Using the model

   • Generating images
   • Generating images for commercial purposes
   • Providing API services

2. Modifying the model

   • Fine-tuning
   • Additional training
   • Model optimization

3. Distributing the model

   • Redistributing the modified model
   • Releasing derivative models
   • Integrating into commercial services

4. Using the output

   • Commercial use of generated images
   • Selling generated images
   • Creating derivative works from generated images

Prohibitions (Use-Based Restrictions)

CreativeML Open RAIL-M may not be used for the following purposes:

1. Violence and Crime

• Generating content that promotes or glorifies violence
• Assisting in planning or carrying out crimes
• Supporting terrorist activities

2. Child Exploitation

• Generating child sexual abuse material (CSAM)
• Content that sexualizes minors

3. Invasion of Personal Privacy

• Generating deepfakes without the consent of the individual
• Generating images for the purpose of identity theft
• For the purpose of spreading disinformation

4. Discrimination and Hate

• Discriminatory content regarding race, gender, religion, etc.
• Images that promote hate speech

5. Medical and Legal Advice

• For the purpose of professional medical diagnosis
• For the purpose of replacing legal advice

6. Other Harmful Uses

• Promoting suicide or self-harm
• Promoting illegal drugs
• Promoting gambling addiction

Use Scenarios

Permitted Uses

1. Generating Marketing Images

Scenario: An image generation service for advertising
Method of use: Generating product images with Stable Diffusion
Determination: Permitted (commercial use OK, not a prohibited use)

2. Generating Game Art

Scenario: Creating background images for an indie game
Method of use: Fine-tuning to generate a consistent style
Determination: Permitted

3. Educational Content

Scenario: Generating thumbnails for online lectures
Method of use: Providing an AI image generation API
Determination: Permitted

Prohibited Uses

1. Deepfake Service

Scenario: A service that generates images using another person’s face
Method of use: Compositing celebrities’ faces
Determination: Prohibited (invasion of privacy)

2. Generating Fake News

Scenario: Generating fake photos of politicians
Method of use: For the purpose of spreading disinformation
Determination: Prohibited (invasion of personal privacy, disinformation)

Requiring Review

1. Generating Social Media Profiles

Scenario: Profiles of virtual characters generated by AI
Method of use: Profile photos of non-existent people
Determination: Depends on the purpose; review the potential for misuse

Licensing of Derivative Models

An important characteristic of CreativeML Open RAIL-M is the propagation of the RAIL clauses.

When distributing a derivative model:

• The same use restrictions must be retained
• The license may be changed, but the Use-Based Restrictions are retained
• In other words, the “responsible use” clauses continue to apply

Example: When fine-tuning Stable Diffusion and distributing a custom model, the same prohibited uses apply to the custom model as well.

Copyright of AI Output

Important: Generated images are separate from the model license

• Model license: CreativeML Open RAIL-M (the model itself)
• Output: Separate copyright (owned by the user)

Generated images:

• The user owns the copyright (not the model provider)
• Can be used freely for commercial purposes
• However, the generation process must not violate the prohibited uses

References

• CreativeML Open RAIL-M Full Text
• SPDX License List - CreativeML-OpenRAIL-M
• RAIL Initiative
• Stable Diffusion License Explanation

10 - Elastic License 2.0 Guide

SPDX Identifier: Elastic-2.0

What Is Elastic License 2.0?

Elastic License 2.0 (ELv2) is the license that Elastic introduced in 2021 when it changed the license of Elasticsearch and Kibana from Apache-2.0.

Background of the License Change

Before January 2021: Apache-2.0

• AWS provided Elasticsearch as a managed service (Amazon Elasticsearch Service)
• This infringed on Elastic’s revenue model

After January 2021: Elastic License 2.0 + SSPL dual license

• Restricted AWS from providing the managed service
• Result: AWS forked it as OpenSearch

The Three Limitations

1. Prohibition on Providing a Managed Service

Prohibited: Providing the substantial functionality of the software as a service to third parties

Specific examples:

Prohibited cases:

• Providing “Elasticsearch as a Service”
• Providing “Managed Kibana”
• Providing Elasticsearch clusters to customers as a managed offering

Permitted cases:

• Using Elasticsearch as the backend of your own service
• Implementing internal search functionality
• Building a log analysis system

2. Prohibition on Use as a Core Feature of a Competing Product

Prohibited: Circumventing the software’s functionality or creating a competing product

Specific examples:

Prohibited cases:

• Circumventing the restrictions on Elasticsearch’s paid features
• Removing the license check of X-Pack features
• Developing a product that provides Elastic’s commercial features for free

Permitted cases:

• A general application that uses Elasticsearch as a search engine
• Developing log collection and analysis tools

3. Trademark Use Restriction

Prohibited: Using the Elastic trademark in a misleading way

Specific examples:

Prohibited cases:

• “Powered by Elasticsearch” (without official approval)
• “Elasticsearch Compatible” (potentially misleading)

Permitted cases:

• “Works with Elasticsearch” (a factual statement)
• “Built on Elasticsearch technology” (a clear factual statement)

References

• Elastic License 2.0 Full Text
• SPDX License List - Elastic-2.0
• Elastic License 2.0 FAQ
• Elastic vs AWS: Background of the License Change

11 - EPL-2.0 Guide

SPDX Identifier: EPL-2.0

License Statement in Source Code

Open source under the EPL-2.0 license generally carries the following statement at the top of the source code.

This program and the accompanying materials are made available under the
terms of the Eclipse Public License v. 2.0 which is available at
http://www.eclipse.org/legal/epl-2.0, or the Eclipse Distribution License
v. 1.0 which is available at
http://www.eclipse.org/org/documents/edl-v10.php.

Obligations by Use Case

Case 1. Redistribution in Source Form

When redistributing open source under the EPL-2.0 license in source form, observe the following.

1-1 Notice Obligation

• Provide a copy of the license
• Do not modify legal notices such as copyright, patent, trademark, warranty disclaimer, and indemnification notices

In other words, redistribute while keeping the license information stated in the source code intact.

Case 2. Redistribution in Binary Form

When building open source under the EPL-2.0 license and redistributing it in binary form only, observe the following.

2-1 Notice Obligation

• Provide a copy of the license
• Do not modify legal notices such as copyright, patent, trademark, warranty disclaimer, and indemnification notices

Generate an open source notice containing the above and enclose it when redistributing the binary.

2-2 Source Code Provision Obligation

Provide the source code files of the modules that fall under EPL-2.0 within the binary. In doing so, observe the following.

• EPL-2.0 requires that content added within a module also be licensed under EPL-2.0 and have its source code disclosed. Therefore, disclose the original module as well as the content added/modified within the module under EPL-2.0.

You can fulfill the source code provision obligation by informing users in the open source notice of how they can obtain the source code.

Per-Module Copyleft

The key characteristic of EPL-2.0 is that Copyleft applies on a per-module basis.

• When modifying an EPL-2.0 module: Disclose only that module under EPL-2.0
• When adding a separate module: The added module does not need to be disclosed
• When combining with another license: Combination is possible if the modules are separated

Because of these characteristics, Eclipse Foundation projects and commercial software can be developed together.

License Compatibility

Compatibility with Major Licenses

References

• EPL-2.0 License Full Text
• SPDX License List - EPL-2.0
• Eclipse Foundation FAQ
• OSADL License Checklist

12 - GPL-2.0 Guide

SPDX Identifier: GPL-2.0-only or GPL-2.0-or-later

License Text in the Source Code

Open source under the GPL-2.0 license generally includes the following text at the top of the source code.

Copyright (C) yyyy name of author
 
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
 
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
 
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.

Obligations by Use Case

Case 1. Redistribution in Source Form

When redistributing open source under the GPL-2.0 license in source form, observe the following.

1-1 Notice Obligation

• Provide a copyright notice
• Provide a warranty disclaimer
• Provide a copy of the license

That is, redistribute while keeping the copyright/license information stated in the source code intact.

Case 2. Redistribution in Binary Form

When building open source under the GPL-2.0 license and redistributing it only in binary form, observe the following.

2-1 Notice Obligation

• Provide a copyright notice
• Provide a warranty disclaimer
• Provide a copy of the license

Generate an open source notice that includes the above and include it when redistributing the binary.

2-2 Obligation to Provide Source Code

Provide the source code corresponding to the binary. In doing so, observe the following.

1. GPL-2.0 requires that derivative works also apply GPL-2.0 and disclose their source code. Referring to the content below, disclose the source code of both the GPL-2.0 open source and the derivative work.

2. Provide a build environment that allows binary users to build an identical binary from the disclosed source code. This includes the following.
   • Tool chain information
   • Build scripts
   • Build instructions (README)

Instead of the source code, you may provide a Written Offer. It must include the following statements.

1. The written offer is valid for 3 years after the product is sold.
2. It is provided to anyone.
3. No charge is made. (excluding costs incurred for delivering the source)

License Compatibility

Compatibility with Major Licenses

References

• GPL-2.0 License Full Text
• SPDX License List - GPL-2.0
• GNU GPL FAQ
• OSADL License Checklist

13 - GPL-3.0 Guide

SPDX Identifier: GPL-3.0-only or GPL-3.0-or-later

License Text in the Source Code

Open source under the GPL-3.0 license generally includes the following text at the top of the source code.

Copyright (C) <year> <name of author>
 
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
 
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
 
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>

Obligations by Use Case

Case 1. Redistribution in Source Form

When redistributing open source under the GPL-3.0 license in source form, observe the following.

1-1 Notice Obligation

• Provide a copyright notice
• Provide a warranty disclaimer
• Provide a copy of the license

That is, redistribute while keeping the copyright/license information stated in the source code intact.

Case 2. Redistribution in Binary Form

When building open source under the GPL-3.0 license and redistributing it only in binary form, observe the following.

2-1 Notice Obligation

• Provide a copyright notice
• Provide a warranty disclaimer
• Provide a copy of the license

Generate an open source notice that includes the above and include it when redistributing the binary.

2-2 Obligation to Provide Source Code

Provide the source code corresponding to the binary. In doing so, observe the following.

1. GPL-3.0 requires that derivative works also apply GPL-3.0 and disclose their source code. Referring to the content below, disclose the source code of both the GPL-3.0 open source and the derivative work.

2. Provide a build environment that allows binary users to build an identical binary from the disclosed source code. This includes the following.
   • Tool chain information
   • Build scripts
   • Build instructions (README)

Instead of the source code, you may provide a Written Offer. It must include the following statements.

1. The written offer is valid for 3 years after the product is sold.
2. It is provided to anyone.
3. No charge is made. (excluding costs incurred for delivering the source)

2-3 Obligation to Provide Installation Information

If you distribute the binary with a User Product, provide Installation Information.

• User Product: An embedded device such as an electronic appliance
• Installation Information: All the information and methods that a user needs to build the source code and reinstall it on the product

Major Improvements over GPL-2.0

GPL-3.0 retains the core principles of GPL-2.0 while improving the following.

• Explicit patent grant: Explicitly stipulates the grant of contributors’ patent licenses
• Anti-Tivoization: Adds the obligation to provide Installation Information for User Products
• Internationalization: Improves legal terminology so it can be applied worldwide

License Compatibility

Compatibility with Major Licenses

References

• GPL-3.0 License Full Text
• SPDX License List - GPL-3.0
• GNU GPL FAQ
• OSADL License Checklist

14 - LGPL-2.1 Guide

SPDX Identifier: LGPL-2.1-only or LGPL-2.1-or-later

License Text in the Source Code

Open source under the LGPL-2.1 license generally includes the following text at the top of the source code.

Copyright (C) year name of author
 
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
 
This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
 
You should have received a copy of the GNU Lesser General Public
License along with this library; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA

Obligations by Use Case

Case 1. Redistribution in Source Form

When redistributing open source under the LGPL-2.1 license in source form, observe the following.

1-1 Notice Obligation

• Provide a copyright notice
• Provide a warranty disclaimer
• Provide a copy of the license

That is, redistribute while keeping the copyright/license information stated in the source code intact.

Case 2. Redistribution in Binary (Library) Form

When building open source under the LGPL-2.1 license and redistributing it only in binary form, observe the following.

2-1 Notice Obligation

• Provide a copyright notice
• Provide a warranty disclaimer
• Provide a copy of the license

Generate an open source notice that includes the above and include it when redistributing the library.

2-2 Obligation to Provide Source Code

Provide the source code corresponding to the binary (library). In doing so, observe the following.

1. LGPL-2.1 requires that derivative works also apply LGPL-2.1 and disclose their source code. Referring to the content below, disclose the source code of both the LGPL-2.1 open source and the derivative work.

2. Provide a build environment that allows users to build an identical library from the disclosed source code of the LGPL library. This includes the following.

   • Tool chain information
   • Build scripts
   • Build instructions (README)

3. When distributing an Executable created by Static Linking the LGPL library, provide the object code that makes up the executable so that users can modify the LGPL library and regenerate the executable. (#LGPLStaticVsDynamic)

Instead of the source code, you may provide a Written Offer. It must include the following statements.

1. The written offer is valid for 3 years after the product is sold.
2. It is provided to anyone.
3. No charge is made. (excluding costs incurred for delivering the source)

Dynamic Linking vs Static Linking

The key point of LGPL-2.1 is that the scope of source code disclosure differs depending on the linking method.

• Dynamic Link: Only the LGPL library is disclosed; the application code does not need to be disclosed
• Static Link: The LGPL library + object code must be provided

For commercial software development, the use of dynamic linking is recommended.

License Compatibility

Compatibility with Major Licenses

References

• LGPL-2.1 License Full Text
• SPDX License List - LGPL-2.1
• GNU LGPL FAQ
• OSADL License Checklist

15 - LGPL-3.0 Guide

SPDX Identifier: LGPL-3.0-only or LGPL-3.0-or-later

License Text in the Source Code

Open source under the LGPL-3.0 license generally includes the following text at the top of the source code.

Copyright (C) <year> <name of author>
 
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU Lesser General Public License as
published by the Free Software Foundation, either version 3 of the
License, or (at your option) any later version.
 
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU Lesser General Public License for more details.
 
You should have received a copy of the GNU Lesser General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.

Obligations by Use Case

Case 1. Redistribution in Source Form

When redistributing open source under the LGPL-3.0 license in source form, observe the following.

1-1 Notice Obligation

• Provide a copyright notice
• Provide a warranty disclaimer
• Provide a copy of the license

That is, redistribute while keeping the copyright/license information stated in the source code intact.

Case 2. Redistribution in Binary (Library) Form

When building open source under the LGPL-3.0 license and redistributing it only in binary form, observe the following.

2-1 Notice Obligation

• Provide a copyright notice
• Provide a warranty disclaimer
• Provide a copy of the license

Generate an open source notice that includes the above and include it when redistributing the library.

2-2 Obligation to Provide Source Code

Provide the source code corresponding to the binary (library). In doing so, observe the following.

1. LGPL-3.0 requires that derivative works also apply LGPL-3.0 and disclose their source code. Referring to the content below, disclose the source code of both the LGPL-3.0 open source and the derivative work.

2. Provide a build environment that allows users to build an identical library from the disclosed source code of the LGPL library. This includes the following.

   • Tool chain information
   • Build scripts
   • Build instructions (README)

3. When distributing an Executable created by Static Linking the LGPL library, provide the object code that makes up the executable so that users can modify the LGPL library and regenerate the executable. (#LGPLStaticVsDynamic)

Instead of the source code, you may provide a Written Offer. It must include the following statements.

1. The written offer is valid for 3 years after the product is sold.
2. It is provided to anyone.
3. No charge is made. (excluding costs incurred for delivering the source)

2-3 Obligation to Provide Installation Information

If you distribute the library with a User Product, provide Installation Information.

• User Product: An embedded device such as an electronic appliance
• Installation Information: All the information and methods that a user needs to build the source code and reinstall it on the product

Major Improvements over LGPL-2.1

LGPL-3.0 retains the core principles of LGPL-2.1 while improving the following.

• Explicit patent grant: Explicitly stipulates the grant of contributors’ patent licenses
• Apache-2.0 compatibility: Resolves the compatibility issue with Apache-2.0
• Anti-Tivoization: Adds the obligation to provide Installation Information for User Products

License Compatibility

Compatibility with Major Licenses

References

• LGPL-3.0 License Full Text
• SPDX License List - LGPL-3.0
• GNU LGPL FAQ
• OSADL License Checklist

16 - Llama 2 Community License Guide

SPDX Identifier: Llama-2 (unofficial)

What Is the Llama 2 Community License?

The Llama 2 Community License is a proprietary license that Meta released in 2023 together with the Llama 2 language model.

Llama Model Lineage

Why a “Community License”?

Meta describes this license as follows:

• Encouraging community innovation: Most developers and companies can use it freely
• Checking large corporations: Restricting exclusive use by Big Tech
• Responsible AI: Preventing harmful use

700 Million Scale Restriction

Definition of MAU (Monthly Active Users)

Monthly active users: the number of unique users who used the product/service in the previous calendar month

Examples:

Scenario 1: T phone app (MAU 5 million)
Since the MAU is fewer than 700 million, it can be used freely.

Scenario 2: Facebook (MAU 3 billion)
Since the MAU is 700 million or more, a separate license must be requested from Meta.

Services Exceeding the 700 Million Threshold

Services with 700 million or more MAU worldwide:

• Facebook, Instagram, WhatsApp (Meta)
• YouTube (Google)
• TikTok
• WeChat

Most companies are not affected

When the Scale Restriction Applies

It applies continuously from the time of license agreement and after use begins.

Important: What happens if you start below 700 million but later exceed it? At the point of exceeding it, you must notify Meta and negotiate a separate license.

Permitted Items (MAU Fewer Than 700 Million)

What You Can Do Freely

1. Commercial use

   • Providing paid services
   • Selling APIs
   • Integrating into products

2. Model modification

   • Fine-tuning
   • Quantization (4-bit, 8-bit)
   • Model merging

3. Model distribution

   • Releasing derivative models
   • Uploading to Hugging Face, etc.
   • Including in open source projects

4. Use of generated outputs

   • Commercial use of AI-generated text

Prohibited Items (Acceptable Use Policy)

Llama 2 cannot be used for the following purposes:

1. Illegal Activities

• Supporting criminal acts
• Trading illegal goods
• Terrorist activities

2. Child Protection

• Child abuse content
• Child grooming

3. Discrimination and Hate

• Generating discriminatory content
• Hate speech
• Harassment

4. Violence and Danger

• Inciting violence
• Encouraging self-harm or suicide
• Weapons manufacturing

5. Privacy Violations

• Unauthorized collection of personal information
• Stalking, surveillance

6. Disinformation

• Intentional fake news
• Fraudulent content

7. High-Risk Domains (Sole Decision-Making)

• Medical diagnosis
• Legal advice
• Financial advice
• Emergency services

Prohibition on Training Competing LLMs with Llama 2

As a distinctive clause, you cannot use Llama 2 to train an LLM that competes with Meta.

Prohibited examples:

• Training a new LLM with the outputs of Llama 2
• Distillation using Llama 2 as a teacher model

Permitted examples:

• Fine-tuning Llama 2 itself
• Using the outputs of Llama 2 as a dataset (for a specific task)

Use Scenarios

Permitted Uses

1. Customer Service Chatbot

Scenario: A telecom customer consultation chatbot
MAU: 10 million
Judgment: Allowed (fewer than 700 million)

2. B2B AI Solution

Scenario: An enterprise document summarization solution
MAU: 100 thousand
Judgment: Allowed

3. Mobile App AI Feature

Scenario: A photo caption generation app
MAU: 5 million
Judgment: Allowed

Restricted Uses

1. Large-Scale Social Media

Scenario: Integration into social media with 1 billion MAU
Judgment: A Meta license is required

2. Training a Competing LLM

Scenario: Training a new LLM with Llama 2 outputs
Judgment: Prohibited

Requires Review

1. Global Service Expansion

Scenario: Currently 50 million MAU, with a future target of 1 billion
Judgment: Consultation with Meta is required before reaching 700 million

Licensing of Derivative Models

Mandatory Requirements

1. Attribution

   • Indicate “Based on Llama 2”
   • State it in the model card

2. License propagation

   • Apply the same Acceptable Use Policy
   • Maintain the 700 million scale restriction

3. Restriction on Meta trademark use

   • Unauthorized use of the “Llama” trademark is prohibited
   • The expression “Built with Llama 2” is OK

Derivative Model Examples

Permitted names:

• “MyModel (based on Llama 2)”
• “CustomLLM-Llama2-7B”

Prohibited names:

• “Llama 2 Pro”
• “Meta Llama Custom”

Llama 3 Update

Llama 3, released in April 2024, uses an updated license:

• Similar basic structure
• Some improvements to the use restriction clauses
• The 700 million scale restriction is maintained

The same guide applies when using Llama 3.

References

• Llama 2 Community License Full Text
• Llama 2 Acceptable Use Policy
• Llama 2 Model Card
• Meta AI Official Blog

17 - MIT Guide

SPDX Identifier: MIT

License Text in the Source Code

Open source under the MIT license generally includes the following text at the top of the source code.

Copyright (c) <year> <copyright holders>
 
Permission is hereby granted, free of charge, to any person
obtaining a copy of this software and associated documentation
files (the "Software"), to deal in the Software without
restriction, including without limitation the rights to use,
copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the
Software is furnished to do so, subject to the following
conditions:
 
The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.
 
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
OTHER DEALINGS IN THE SOFTWARE.

Obligations by Use Case

Case 1. Redistribution in Source Form

When redistributing open source under the MIT license in source form, observe the following.

1-1 Notice Obligation

• Copyright notice
• Provide a copy of the license

That is, keep the copyright, license, and so on within the source code intact.

Case 2. Redistribution in Binary Form

When building open source under the MIT license and redistributing it only in binary form, observe the following.

2-1 Notice Obligation

• Copyright notice
• Provide a copy of the license

Generate an open source notice that includes these items and include it when redistributing the binary.

License Compatibility

The MIT license is compatible with most other licenses.

Compatibility with Major Licenses

References

• MIT License Full Text
• SPDX License List - MIT
• OSADL License Checklist

18 - MPL-2.0 Guide

SPDX Identifier: MPL-2.0

License Text in the Source Code

Open source under the MPL-2.0 license generally includes the following text at the top of the source code.

This Source Code Form is subject to the terms of the Mozilla Public
License, v.2.0. If a copy of the MPL was not distributed with this file,
You can obtain one at https://mozilla.org/MPL/2.0/.

Obligations by Use Case

Case 1. Redistribution in Source Form

When redistributing open source under the MPL-2.0 license in source form, observe the following.

1-1 Notice Obligation

• Provide or reference a copy of the license
• Do not modify legal notices

That is, redistribute while keeping the license information stated in the source code intact.

Case 2. Redistribution in Binary Form

When building open source under the MPL-2.0 license and redistributing it only in binary form, observe the following.

2-1 Notice Obligation

• Provide a copy of the license

Generate an open source notice that includes the above and include it when redistributing the binary.

2-2 Obligation to Provide Source Code

Provide the source code files under MPL-2.0 within the binary. In doing so, observe the following.

• MPL-2.0 requires that content added within a file also apply MPL-2.0 and disclose its source code. Therefore, disclose both the original file and the modified file by applying MPL-2.0.

You can fulfill the obligation to provide source code by indicating in the open source notice how users can obtain the source code.

Per-File Copyleft

The key characteristic of MPL-2.0 is that Copyleft is applied on a per-file basis.

• When modifying an MPL-2.0 file: Disclose only that file under MPL-2.0
• When adding a separate file: The added file does not need to be disclosed
• When combining with other licenses: Combination is possible if the files are separated

Because of these characteristics, it can be used flexibly in commercial software development.

License Compatibility

Compatibility with Major Licenses

References

• MPL-2.0 License Full Text
• SPDX License List - MPL-2.0
• Mozilla MPL FAQ
• OSADL License Checklist

19 - SSPL Guide

SPDX Identifier: SSPL-1.0

What Is SSPL?

SSPL (Server Side Public License) is a license that MongoDB created in 2018 to prevent cloud providers such as AWS from offering MongoDB as a commercial service.

Differences from AGPL-3.0

SSPL modifies AGPL-3.0 Section 13 to require, when providing a service, the disclosure of all of the following:

• The SSPL software itself
• All software that interacts with the service
• The management software needed to operate the service
• Infrastructure provisioning, monitoring, backup tools, etc.

Major Use Cases

MongoDB’s License Change

• Before October 2018: AGPL-3.0
• After October 2018: SSPL-1.0

Other Projects Adopting SSPL

• Graylog
• Some NoSQL databases

Why Did the OSI Not Approve It?

In 2019, the OSI decided not to recognize SSPL as open source:

1. Overly broad disclosure requirement: The scope of “everything needed to operate the service” is unclear
2. Violation of non-discrimination: It effectively prohibits a specific business model (SaaS)
3. Restriction on free use: Providing a commercial cloud service is practically impossible

Reasons for the Usage Restriction

If you provide a service using SSPL software, you must disclose all of the following:

1. The source code of the SSPL software
2. The service application code
3. Kubernetes configurations
4. Terraform scripts
5. Monitoring tools (Prometheus, Grafana, etc.)
6. CI/CD pipelines
7. Backup and recovery systems

Since this would require disclosing all of SK Telecom’s core infrastructure information, its use is not possible.

Alternatives

If you need to use SSPL software, please consider the following alternatives.

MongoDB

• MongoDB Community Edition: SSPL
• Alternative 1: MongoDB Atlas (MongoDB’s official cloud service)
• Alternative 2: PostgreSQL + JSON features
• Alternative 3: FerretDB (a MongoDB-compatible AGPL project)

Graylog

• Graylog Open Source: SSPL
• Alternative 1: Elasticsearch + Kibana (Elastic License 2.0, separate review required)
• Alternative 2: Grafana Loki (AGPL-3.0)

References

• SSPL License Full Text
• SPDX License List - SSPL-1.0
• OSI’s Decision to Reject SSPL
• MongoDB License Change Announcement