ziglang
package management: add opt-in source code license compatibility checking
This proposal is to add two license-related fields to build.zig.zon. Example:
.licenses = .{ "MIT" },
This field communicates that the current package has only files covered by the MIT license. It is out of scope to be more specific about which files are covered under which license. The purpose of this field is only so that a downstream package can identify when a forbidden license is found in the dependency tree.
License identifiers can be any string. Packages can then opt-in to only allowing a limited set of licenses with a dependency_licenses field:
.dependency_licenses = .{ "MIT", "BSD-3", "Public Domain" },
This governs the full dependency tree. When adding a dependency, one might see an error like this:
$ zig pkg add https://gitdab.com/cadence/Carbon
build.zig.zon:3:13: error: package 'quux' has license 'AGPL' which is absent from 'dependency_licenses':
MIT
BSD-3
Public Domain
to solve this problem, add 'AGPL' to 'dependency_licenses', or eliminate 'quux' from the dependency tree:
Carbon.bar.baz.quux
When the dependency_licenses field is present, any dependencies in the tree which are missing the licenses field will be errors:
$ zig pkg add https://gitdab.com/cadence/Carbon
build.zig.zon:3:13: error: package 'quux' missing license declaration
build.zig.zon:20:5: note: field 'dependency_licenses' requires every dependency to declare a license
to solve this problem, kindly ask the package maintainer to add a `licenses` field, or eliminate 'quux' from the dependency tree:
Carbon.bar.baz.quux
The purpose of this field is only so that a downstream package can identify when a forbidden license is found in the dependency tree.
The package manager can only check the declarations of packages, but it does not specify behavior of conflicting information and where this is intended to be checked: Full + automatic reasonable reliable license identification requires for each used file: 1. automatic checking LICENSE file of each directory, 2. checking SPDX identifiers, 3. handling missing info, 4. resolution for conflicting licensing. At least a plan how to handle this problem would be nice to communicate shortcomings/necessary additional checks early.
As far as I understand, a build.zig license also can only be applied for in-tree code or must uniquely identify the code it applies to. This is not mentioned in this proposal, but relevant for package aggregation.
Added a PR #15248 for the fields in package.zig.zon and Manifest.zig, but did create any validation logic yet since the command "zig pkg" do not seem to exist yet.
Perhaps we could currently add some validation/warning using this in "main.zig" after the callto fetchAndAddDependencies?
Comparing SPDX-ID fields is ad-hoc and inflexible. Also prone to forgery, misrepresentation, and compliance depreciation. Competent and reliable license management is infeasible. There's better pluralistic schemes to index legal particulars.
Comparing SPDX fields is ad-hoc and inflexible. It's prone to forgery, misrepresentation, and depreciation of compliance.
I am aware of the technical drawbacks, in particular missing annotation of multiple licenses, derivative works and non-standard license texts/identifiers.
There's more standardised and pluralistic schemes to index licensing and legal particulars. I think a competent and reliable license management is infeasible.
Not having package licensing would make usage in buildroot completely nonviable and this holds for any user-extensivble build system (reviewing licenses for espressif ide manually is also painful).
Can you be more specific on the necessary complexity plus which cases are covered by this and which not?
From my understanding the law any country (with license laws) mandates a reasonable vetting of authorship (ie account validation to hold jurisitcally viable) or the sources themself depending on the license and/or platform and/or practice and full ownership tracking is impossible and Zig can of course not handle law stuff and support all possible ways of annotating + interpreting licenses.
There's better pluralistic schemes to index legal particulars.
Do you have particular ideas?
I abridged. This proposal would encourage using SPDX identifiers in a context which, again:
is prone to forgery, misrepresentation, and depreciation of compliance.
- The only appropriate use for a program to do anything about license IDs alone is search.
- Artificial scoping miscalculates best practices and individual needs, subceding volition for jeopardizing veracity.
Someone who takes licenses seriously wouldn't use this. Who is this for? Here's the full SPDX specification. Avoid this altogether. Mechanizing the concept of intellectual property is not within Zig's reach.
It would be great if the package manager could also point to the LICENSE file, so they can be processed. Some licenses require that you include attribution somewhere, and this would make the process easier.
Having a license field in build.zig.zon doesn't handle the case where a project may have different licenses for different exposed modules and/or files nor does it handle optional dependencies such as the case with ffmpeg which is either LGPLv2.1 or GPLv2 depending on it's configuration.
build.zig would have to validate licenses against the current build configuration while taking into account the license of every file within the project in addition to dependencies.
Tangental anecdote: The manifest rigmarole for Rust and Julia is an insert of the instant-sharing style of their respective centralized package managers. It's never fully thought out, but particularly unnecessary for chimeric approaches. Extraneous information belongs somewhere, but why must it be fauxily indexed?
Autodoc might create a demand for it - and I think here too it would be impeding to stipulate prescribed fields to get a certain output, so hopefully communicating project information is made of configurable custom fields, if anything.
Comparing SPDX fields is ad-hoc and inflexible. It's prone to forgery, misrepresentation, and depreciation of compliance.
I am aware of the technical drawbacks, in particular missing annotation of multiple licenses, derivative works and non-standard license texts/identifiers.
AFAIK, multiple annotations are supported, unless I misunderstood your definition.
Here is an example from reuse:
# SPDX-FileCopyrightText: 2014 Ahmed H. Ismail
# SPDX-FileCopyrightText: 2019 Free Software Foundation Europe e.V. <https://fsfe.org>
#
# SPDX-License-Identifier: Apache-2.0
# SPDX-License-Identifier: GPL-3.0-or-later
