Revise how we capture and track project licenses
We currently capture project licenses as a list. For most of our projects, it is a list with a single entry. This list is maintained in two different places: the foundation database and in the PMI. The project license can only be modified by the EMO.
The licenses that we support are represented as records (rows in the SYS_License
table in the foundation database and instances of the license
content type in the PMI) and are associated with projects via foreign key references. This means that the set of licenses that we support is limited to those that are included in those records; or, put another way, to support an additional license, we have to add records and then associate those records with the corresponding project.
When we created the EPL-2.0, in order to support the notion of secondary licenses, we added "Secondary" license records (the database schema was extended to include a notion of whether a license is considered a "primary" license or not).
The list of licenses looks like this in the project proposal form in the PMI:
The intention is that these "secondary" licenses only apply when the EPL-2.0 is selected, but we never implemented any logic to enforce or encourage this (we tend to just deal with the relatively rare cases that this comes up as they come up).
A problem with maintaining a list of licenses is that it does not make explicit how the licenses are combined. Tools like the documentation generator and the IP Log generator include some heuristics that, basically guess as how things are combined. Any selected secondary license is assumed to be a secondary license of the EPL-2.0; all license combinations are assumed to be dual licensing. This heuristic has served us surprisingly well.
The following copyright and license statement, for example, is generated for the Jakarta Enterprise Beans project using the information that we track in the database:
/********************************************************************************
* Copyright (c) {date} {owner}[ and others]
*
* This program and the accompanying materials are made available under the
* terms of the Eclipse Public License v. 2.0 which is available at
* https://www.eclipse.org/legal/epl-2.0.
*
* This Source Code may also be made available under the following Secondary
* Licenses when the conditions for such availability set forth in the Eclipse
* Public License v. 2.0 are satisfied: (secondary) GPL-2.0 with
* Classpath-exception-2.0 which is available at
* https://openjdk.java.net/legal/gplv2+ce.html.
*
* SPDX-License-Identifier: EPL-2.0 OR GPL-2.0-only with Classpath-exception-2.0
********************************************************************************/
Note that SPDX expressions should be read from the consumer's perspective. From the consumer's point of view, secondary licenses is the same as dual licensing.
As we move forward with the IP Policy updates (#1194 (closed)), we're adding more flexibility in the license selection and so it may no longer make sense (at least in the general case) to limit ourselves to a list and it is increasingly likely that the simple heuristics that we employ are not going to be sufficient in many cases.
As part of this, we need to decide how much information we need to capture about the nature of licensing of specific scenarios. The Oniro Core project, for example, has some rather complex licensing: project code is generally under the Apache-2.0
, but that project code is used to assemble third-party content that is under other licenses, including the GPL-2.0-only
. It's incorrect to state that this project's license is Apache-2.0 or GPL-2.0-only
. Rather, it is more accurate to say that the project code is under one license, but the products/output of the project is under another license. That is, there are at least two different license statements for the Oniro Core project.