Follow-up Comment #11, task #16658 (group administration): [comment #10 comment #10:] > 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.
Copyrightable text files should include copyright and license notices themselves. > [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. Yes. It's [//www.gnu.org/prep/maintain/html_node/Copyright-Notices.html less than 10 lines long]. >>> - 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. Yes, of course we are using that definition. > Libgit2 can be a dependency of GPLv3 software via either static or dynamic > linking. I can imagine other kinds of dependency, e.g. a dependent script may invoke a program that uses libgit2; however, compatibility is defined in terms of making a combined work rather than in terms of dependency. > GPLv2 restricts things such as "modification of the file, and distribution > when not linked into a combined executable" according to the linking > exception. In other words, the exception of libgit2 allows linking with software under GPLv3; however, when a GPLv3-covered program is linked to other software, that other software should be distributable under the terms of GPLv3, and libgit2 doesn't allow that, www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs. >> 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". No; what could prevent is dependencies under MPL-2.0 or dependencies under Apache-2.0-only. > 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> As far as I understand, Apache-2.0 protects against the aggression by the users rather than by the contributors, and the users can just use CC0. > 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. Or for the maintainers to avoid elementary thinking about what the licensing terms of their package are. > 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). Then Apache-2.0 isn't the best selection because it's much more complicated than many simple permissive licenses (including the fallback license in CC0). > - 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. Is there a reason why the licenses of those libraries may be ignored? > - The Rust repository includes fonts licensed under OFL-1.1. I don't know if > that's a problem. At least you should understand how it interacts with other licenses. > - 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>. Ok. > - 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. To be on the same page: all cargo-license lists are libraries, aren't they? _______________________________________________________ Reply to this item at: <https://savannah.nongnu.org/task/?16658> _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/
signature.asc
Description: PGP signature
