Follow-up Comment #10, task #16658 (group administration): For consistency and clarity, I have now decided to use AGPL for the Cargo.lock and rust_fmt_version.txt files, regardless of whether or not they can be restricted by copyright. To work around the fact that these files are automatically overwritten, I put the notices in the Cargo.lock.license and rust_fmt_version.txt.license files. They are the same notices that other files have, except I made the phrase "This file" more specific.
[comment #9 comment #9:]
>> rust_fmt_version.txt is generated by `cargo +nightly fmt --version >
>> rust_fmt_version.txt` in the lint.sh script. Currently the file just
>> contains
>> `rustfmt 1.8.0-nightly (c68340350c 2025-06-18)`. It's not derived from my
>> work
>> at all. The included work of Rust developers (e.g. a version number) don't
>> seem copyrightable.
>
> Why doesn't it seem copyrightable?
It's way too simple.
These are all the things that the string "rustfmt 1.8.0-nightly (c68340350c
2025-06-18)" comes from (not that I think this matters):
- Format strings "rustfmt {version_number}-{commit_info}" and "{} ({} {})" in
rustfmt source code.
- The version number "1.8.0".
- The string literal "nightly".
- The outputs of the commands `git rev-parse HEAD` and `git log -1
--date=short --pretty=format:%cd` when run in the rustfmt repository.
>> - libgit2's GPLv2 license, with a linking exception (granting "unlimited
>> permission to link the compiled version of this library into combinations
>> with
>> other programs, and to distribute those combinations without any
>> restriction
>> coming from the use of this file")
>
> Is this compatible with GPLv3? What do you think?
Yes, assuming you are using the definition of "compatible" that the GNU
licenses FAQ gives. Libgit2 can be a dependency of GPLv3 software via either
static or dynamic linking. GPLv2 restricts things such as "modification of the
file, and distribution when not linked into a combined executable" according
to the linking exception.
> We have just seen that e.g. 'MIT OR Apache-2.0' in fact may mean a much
> richer set of licenses, haven't we? (And sincerely speaking, I can't get the
> point of licensing anything like (in Rust 'materials') Apache-2.0 OR
> Apache-2.0 WITH LLVM-exception OR CC0-1.0.)
"Apache-2.0 OR Apache-2.0 WITH LLVM-exception OR CC0-1.0" can be treated the
same as "CC0-1.0" (public domain) and does not prevent Rust from being
released under "MIT or Apache-2.0".
The purpose of combining Apache-2.0 with a more permissive license using `OR`
is to protect against patent aggression (probably from contributors) using
Apache-2.0's patent grant, without removing compatibility with GPLv2.
<https://prev.rust-lang.org/en-US/faq.html#why-a-dual-mit-asl2-license>
My best guess for the purpose of using "Apache-2.0 OR Apache-2.0 WITH
LLVM-exception" instead of just "Apache-2.0" is to make it clearly optional to
read the LLVM exception, which is convenient for someone who doesn't know what
"WITH LLVM-exception" means.
My best guess for the purpose of using "Apache-2.0 OR Apache-2.0 WITH
LLVM-exception OR CC0-1.0" instead of "Apache-2.0 OR CC0-1.0" (basically
CC0-1.0 plus patent grant) is to use "Apache-2.0 OR Apache-2.0 WITH
LLVM-exception" (equivalent to "Apache-2.0 WITH LLVM-exception") as a backup
for when CC0-1.0 doesn't work in some jurisdictions (may or may not be a
rational fear).
>>>> - rust, <https://github.com/rust-lang/rust>, MIT OR Apache-2.0
> ...
>> The items listed in that same file under "We track licenses for third-party
>> materials in two ways" are sufficient for the "otherwise noted" cases. The
>> REUSE.toml file precisely lists licenses for files in both the Rust
>> repository
>> and the included git submodules. Here's the external dependencies'
>> licenses,
>> summarized by the `cargo-license` tool:
>>
>> ```
>> (MIT OR Apache-2.0) AND Unicode-3.0 (1): unicode-ident
> ...
>> MPL-2.0 (2): colored, option-ext
>> N/A (106): build-manifest, build_helper, bump-stage0, cargotest2,
> ...
>> Zlib (1): foldhash
>> ```
>
> What conclusion can you make based on this?
- All libraries listed under "N/A" in the output of cargo-license are
non-external libraries in the Rust repository. Their licenses are only
specified in REUSE.toml, not in the per-library Cargo.toml files.
- The Rust repository includes fonts licensed under OFL-1.1. I don't know if
that's a problem.
- Some entries in REUSE.toml are for things in the `src/gcc` directory, which
is a Git submodule that is typically not initialized or used. It's for Rust's
fork of GCC. Official Rust builds don't use it. Some non-default Rust builds
may have to be GPL 3 or later because of opting into the feature that uses the
GCC fork. GCC has a GPL-2.0-only test suite that is not touched by Rust's
fork, so that license is listed in Rust's REUSE.toml, but it can be ignored
because GCC's test suite has nothing to do with Rust. For details, see
<https://github.com/rust-lang/compiler-team/issues/442>.
- All libraries listed in the output of cargo-license, along with files in the
Rust repository that I did not mention, have no restrictions beyond those of
Apache-2.0 and restrictions on using some copyright holders' names.
(file #57379)
_______________________________________________________
Additional Item Attachment:
File name: serde-catholicmatch-2025-07-08.tar.gz Size: 21KiB
<https://file.savannah.nongnu.org/file/serde-catholicmatch-2025-07-08.tar.gz?file_id=57379>
AGPL NOTICE
These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://savannah.nongnu.org/source/savane-e6e5367e43c4f3277d32091b77b783b4fe8d5c20.tar.gz
_______________________________________________________
Reply to this item at:
<https://savannah.nongnu.org/task/?16658>
_______________________________________________
Message sent via Savannah
https://savannah.nongnu.org/
signature.asc
Description: PGP signature
