taskSavannah Administration - Tasks: task #16658, Submission of serde-catholicmatch

 
 

task #16658: Submission of serde-catholicmatch

Submitter:  dullbananas
Submitted:  Thu 26 Jun 2025 03:41:35 AM UTC
   
 
Should Start On:  Thu 26 Jun 2025 12:00:00 AM UTC Should be Finished on:  Sun 06 Jul 2025 12:00:00 AM UTC
Category:  Group Approval Priority:  * 5 - Normal
Status:  In Progress Privacy:  Public
Assigned to:  ineiev Open/Closed:  Open
* Mandatory Fields

Post a Comment

Add a New Comment Rich Markup
   

Discussion

Jump to the original submission

Mon 08 Dec 2025 05:54:46 AM UTC, comment #21: 

Thank you!

Documentation should be released under terms compatible with FDL version 1.3 and any later version.  Currently, your README.md is released under GPLv3+.  Could you fix that?  You could release it also under FDLv1.3+ (or only under FDLv1.3+) or just use a permissive license.

Ineiev <ineiev>
Site Administrator
Sun 07 Dec 2025 10:01:37 PM UTC, comment #20: 

Here's a new tarball. Every file that's not a license file now has a license notice on the top.

To make this possible, dependencies on the following commands were added. No particular implementation is needed, but on my computer they're all either in GNU Coreutils or built into sh.
- tr
- cut
- echo
- cat
- rm
- mv

(file #57928)

dullbananas
Thu 13 Nov 2025 06:54:29 PM UTC, comment #19: 

I will probably resolve the issues some time within the next month

dullbananas
Thu 13 Nov 2025 04:26:03 PM UTC, comment #18: 

If there is no further interest, I'll cancel this submission.

Ineiev <ineiev>
Site Administrator
Sat 06 Sep 2025 10:55:27 AM UTC, comment #17: 

Then you can make your script manage it---for example, they could add a file with the notices like Cargo.lock.out and synchronize it with Cargo.lock.

Ineiev <ineiev>
Site Administrator
Mon 01 Sep 2025 08:58:03 PM UTC, comment #16: 


comment #15:

> ...
> > > > > Copyrightable text files should include copyright and license notices themselves.
> ...
> > > Then you can generate them so that they be preserved.
> >
> > There is no such option.
>
> Can you elaborate?  Initially, your package had no options at all; now, it has the options you've implemented.


It would need to be an option in Cargo. The generation of Cargo.lock is not managed by any scripts I wrote. Usually, Cargo writes to the Cargo.lock file immediately when opening the project folder for editing.

dullbananas
Mon 11 Aug 2025 04:15:17 AM UTC, comment #15: 

...

> > > > Copyrightable text files should include copyright and license notices themselves.

...

> > Then you can generate them so that they be preserved.
>
> There is no such option.


Can you elaborate?  Initially, your package had no options at all; now, it has the options you've implemented.

Ineiev <ineiev>
Site Administrator
Thu 07 Aug 2025 10:19:22 PM UTC, comment #14: 


comment #13:

> comment #12:
> > > Copyrightable text files should include copyright and license notices themselves.
> >
> > Custom additions to the top of these files are not preserved.
> >
> > To be clear, the generation of these files is not a one-time initialization thing.
>
> Then you can generate them so that they be preserved.


There is no such option.

> > No, their licenses may not be ignored. They are specified in REUSE.toml. Those libraries are not external dependencies, but rather inside of the Rust repository. "N/A" is how the cargo-license tool indicates that the "license" field is not listed in a library's Cargo.toml file.
>
> Then they need checking in order to understand the licensing terms of the package in quiestion, needn't they?


These are the licenses used for packages inside of the Rust repository: Apache-2.0, "MIT" (terms of Expat, not X11), Unicode-3.0, BSD-2-Clause, OFL-1.1

Regarding the OFL confusion, I have now read the text of that license and concluded that it's not a problem.

dullbananas
Mon 28 Jul 2025 06:18:17 AM UTC, comment #13: 

comment #12:

> > Copyrightable text files should include copyright and license notices themselves.
>
> Custom additions to the top of these files are not preserved.
>
> To be clear, the generation of these files is not a one-time initialization thing.


Then you can generate them so that they be preserved.

> Does that just mean that any GPLv3 code that links to libgit2 needs to include an exception to allow that linking?


Quite right.

> If that is the correct understanding, then it's nothing to worry about, since my library does not link to Cargo or anything that's only used by Cargo.


You are right, nothing to worry about; however, it's something to understand.

> > Is there a reason why the licenses of those libraries may be ignored?
>
> No, their licenses may not be ignored. They are specified in REUSE.toml. Those libraries are not external dependencies, but rather inside of the Rust repository. "N/A" is how the cargo-license tool indicates that the "license" field is not listed in a library's Cargo.toml file.


Then they need checking in order to understand the licensing terms of the package in quiestion, needn't they?

> The only thing that gave me uncertainty is that gnu.org lists this license under "Free licenses, incompatible with the GNU GPL and FDL". I'm still confused about that.
>
> I at least should know whether or not an HTML file may both use the OFL fonts and include portions of my GPLed files, because the fonts are for Rust's documentation generator.


Typically, using a font to render a text doesn't make a combined work with that font.  Even for the programs that render the text, the font is used as input data rather than as part of program.

Ineiev <ineiev>
Site Administrator
Wed 23 Jul 2025 09:19:03 PM UTC, comment #12: 

comment #11:

> 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.


Custom additions to the top of these files are not preserved.

To be clear, the generation of these files is not a one-time initialization thing.

> 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/licen ... LIncompatibleLibs.


Does that just mean that any GPLv3 code that links to libgit2 needs to include an exception to allow that linking?

If that is the correct understanding, then it's nothing to worry about, since my library does not link to Cargo or anything that's only used by Cargo. The only connection between libgit2 and my library is that Cargo would use libgit2 to download my library, if a dependency on my library is added in a special way.

> > - 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?


No, their licenses may not be ignored. They are specified in REUSE.toml. Those libraries are not external dependencies, but rather inside of the Rust repository. "N/A" is how the cargo-license tool indicates that the "license" field is not listed in a library's Cargo.toml file.

> > - 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.


The only thing that gave me uncertainty is that gnu.org lists this license under "Free licenses, incompatible with the GNU GPL and FDL". I'm still confused about that.

I at least should know whether or not an HTML file may both use the OFL fonts and include portions of my GPLed files, because the fonts are for Rust's documentation generator.

> To be on the same page: all cargo-license lists are libraries, aren't they?


Mostly. It also includes packages that are inside of the current repository, which aren't always libraries.

dullbananas
Sat 12 Jul 2025 08:40:33 PM UTC, comment #11: 

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:
> > > 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 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/licen ... LIncompatibleLibs.

> > 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 ... -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.co ... r-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?

Ineiev <ineiev>
Site Administrator
Wed 09 Jul 2025 06:20:48 AM UTC, 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.

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 ... -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. ... /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.co ... r-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)

dullbananas
Fri 04 Jul 2025 07:48:53 PM UTC, comment #9: 

On Thu, Jul 03, 2025 at 04:56:53AM -0400, -email is unavailable- wrote:

> Follow-up Comment #8, task #16658 (group administration):
>
> Here's a corrected explanation of the files that have no notice.
>
> 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?

> The purpose of rust_fmt_version.txt is to make the current
> code formatting style reproducible, just in case there's problems caused by
> all the formatting suddenly changing when updating rustfmt.


Basically, the purpose doesn't matter from the legal point of view.  The developers include it, therefore it should be legal to include it.

> Cargo.lock is a package manager state. It lists each direct or indirect
> dependency's name, version, source location, checksum, and dependency names.
> Before compiling a package (not including dependencies), Cargo always rewrites
> its Cargo.lock file. A change to the next contents of Cargo.lock can be
> triggered by editing the list of direct dependencies in Cargo.toml (not to be
> confused with Cargo.lock) or by running `cargo update`. The purpose of
> including Cargo.lock in version control (which is controversial) is to allow
> investigation when a new version of a dependency causes my library to break.


From this passage, I still can't see the reason why Cargo.lock isn't copyrightable.

> Not sure it it matters, but there's "rust_fmt_version.txt.license" and
> "Cargo.lock.license" files with the following contents so that the `reuse
> lint` command doesn't complain about the lack of embedded license data:


Neither am I sure; Savannah hosting requirements are written in terms of having valid legal notices rather than expecting certain output of `reuse lint`.

> >> - cargo, <https://github.co ... m/rust-lang/cargo>, MIT OR Apache-2.0
> >
> > Its README.md says it contains some software under more licenses
> > (LICENSE-THIRD-PARTY).  Could you analyze it?
>
> LICENSE-THIRD-PARTY contains copies of these licenses used by dependencies:
> - old license that OpenSSL used to use, outdated because Cargo uses version
> 300.5.0+3.5.0 of openssl-src, and OpenSSL switched to Apache-2.0 license in
> version 3 (see <https://github.co ... master/Cargo.lock> and
> <https://crates.io ... rates/openssl-src>)


Ok.

> - 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?

> - zlib license
> - expat licenses
> - LGPL v2.1 license
> - BSD 3-clause license
> - a variant of the X11 license, with "the X Consortium" replaced with generic
> references to authors and copyright holders
> - the unlicense
>
> > While at it, there is no single
> > "MIT" license: people use it
> > to refer to a number of various licenses.
>
> Should I look in the repository of each "MIT"-licensed dependency to check
> what the authors meant by "MIT"?


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.)

> >> - rust, <https://github. ... /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?

Ineiev <ineiev>
Site Administrator
Thu 03 Jul 2025 08:56:50 AM UTC, comment #8: 

Here's a corrected explanation of the files that have no notice.

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. The purpose of rust_fmt_version.txt is to make the current code formatting style reproducible, just in case there's problems caused by all the formatting suddenly changing when updating rustfmt.

Cargo.lock is a package manager state. It lists each direct or indirect dependency's name, version, source location, checksum, and dependency names. Before compiling a package (not including dependencies), Cargo always rewrites its Cargo.lock file. A change to the next contents of Cargo.lock can be triggered by editing the list of direct dependencies in Cargo.toml (not to be confused with Cargo.lock) or by running `cargo update`. The purpose of including Cargo.lock in version control (which is controversial) is to allow investigation when a new version of a dependency causes my library to break.

Not sure it it matters, but there's "rust_fmt_version.txt.license" and "Cargo.lock.license" files with the following contents so that the `reuse lint` command doesn't complain about the lack of embedded license data:

```
SPDX-FileCopyrightText: NONE

SPDX-License-Identifier: CC0-1.0
```

> > - cargo, <https://github.co ... m/rust-lang/cargo>, MIT OR Apache-2.0
>
> Its README.md says it contains some software under more licenses
> (LICENSE-THIRD-PARTY).  Could you analyze it?


LICENSE-THIRD-PARTY contains copies of these licenses used by dependencies:
- old license that OpenSSL used to use, outdated because Cargo uses version 300.5.0+3.5.0 of openssl-src, and OpenSSL switched to Apache-2.0 license in version 3 (see <https://github.co ... master/Cargo.lock> and <https://crates.io ... rates/openssl-src>)
- 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")
- zlib license
- expat licenses
- LGPL v2.1 license
- BSD 3-clause license
- a variant of the X11 license, with "the X Consortium" replaced with generic references to authors and copyright holders
- the unlicense

> While at it, there is no single "MIT" license: people use it to refer to a number of various licenses.


Should I look in the repository of each "MIT"-licensed dependency to check what the authors meant by "MIT"?

> > - rust, <https://github. ... /rust-lang/rust>, MIT OR Apache-2.0
>
> The COPYRIGHT file says (the emphasis is mine),
>
> > Except as otherwise noted, Rust is licensed...
>
> What do you think about it?


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
0BSD OR Apache-2.0 OR MIT (1): adler2
Apache-2.0 (4): dissimilar, fluent-langneg, self_cell, similar
Apache-2.0 OR Apache-2.0 WITH LLVM-exception OR CC0-1.0 (1): blake3
Apache-2.0 OR Apache-2.0 WITH LLVM-exception OR MIT (17): linux-raw-sys, rustix, wasi, wasi, wasm-component-ld, wasm-encoder, wasm-encoder, wasm-encoder, wasm-metadata, wasmparser, wasmparser, wasmparser, wast, wat, wit-bindgen-rt, wit-component, wit-parser
Apache-2.0 OR BSD-2-Clause OR MIT (2): zerocopy, zerocopy-derive
Apache-2.0 OR BSL-1.0 (1): ryu
Apache-2.0 OR CC0-1.0 OR MIT-0 (1): constant_time_eq
Apache-2.0 OR LGPL-2.1-or-later OR MIT (1): r-efi
Apache-2.0 OR MIT (362): addr2line, aes, allocator-api2, android-tzdata, android_system_properties, annotate-snippets, annotate-snippets, anstream, anstyle, anstyle-lossy, anstyle-parse, anstyle-query, anstyle-svg, anstyle-wincon, anyhow, arrayvec, askama, askama_derive, askama_parser, autocfg, backtrace, base64, basic-toml, bitflags, block-buffer, bstr, bumpalo, bytecount, camino, cargo-miri, cargo-platform, cc, cfg-if, chrono, chrono-tz, chrono-tz-build, cipher, clap, clap-cargo, clap_builder, clap_derive, clap_lex, clippy, clippy_lints, clippy_utils, collect-license-metadata, color-eyre, color-print, color-print-proc-macro, color-spantrace, colorchoice, core-foundation-sys, cpufeatures, crc32fast, crossbeam-channel, crossbeam-deque, crossbeam-epoch, crossbeam-utils, crypto-common, ctrlc, datafrog, dbus, declare_clippy_lint, derive-where, derive_builder, derive_builder_core, derive_builder_macro, derive_setters, diff, digest, directories, dirs, dirs-next, dirs-sys, dirs-sys, dirs-sys-next, displaydoc, either, elsa, ena, encode_unicode, env_filter, env_logger, equivalent, errno, expect-test, eyre, fallible-iterator, fastrand, features-status-dump, filetime, flate2, fluent-bundle, fluent-syntax, fnv, form_urlencoded, fs-err, futf, futures, futures-channel, futures-core, futures-executor, futures-io, futures-macro, futures-sink, futures-task, futures-util, getopts, getrandom, getrandom, gimli, gimli, glob, gsgdt, hashbrown, heck, heck, hermit-abi, hex, home, html5ever, humansize, humantime, iana-time-zone, iana-time-zone-haiku, id-arena, ident_case, idna, idna_adapter, if_chain, indenter, indexmap, indoc, inout, intl-memoizer, intl_pluralrules, ipc-channel, is_terminal_polyfill, itertools, itoa, jobserver, js-sys, lazy_static, leb128, leb128fmt, libc, libdbus-sys, libffi, libffi-sys, libz-sys, lld-wrapper, llvm-bitcode-linker, lock_api, log, lzma-sys, mac, markup5ever, match_token, md-5, measureme, memmap2, minimal-lexical, miow, miri, normpath, num, num-bigint, num-complex, num-integer, num-iter, num-rational, num-traits, num_cpus, object, object, odht, once_cell, once_cell_polyfill, opener, openssl-probe, parking_lot, parking_lot_core, pathdiff, percent-encoding, perf-event-open-sys, pest, pest_derive, pest_generator, pest_meta, pin-project-lite, pin-utils, pkg-config, polonius-engine, portable-atomic, portable-atomic-util, ppv-lite86, proc-macro-hack, proc-macro2, psm, quote, rand, rand, rand_chacha, rand_chacha, rand_core, rand_core, rand_xorshift, rand_xoshiro, rayon, rayon-core, regex, regex-automata, regex-lite, regex-syntax, regex-syntax, rustc-build-sysroot, rustc-demangle, rustc-hash, rustc-hash, rustc-literal-escaper, rustc-semver, rustc-stable-hash, rustc-std-workspace-alloc, rustc-std-workspace-core, rustc-std-workspace-std, rustc_lexer, rustc_thread_pool, rustc_tools_util, rustc_tools_util, rustc_version, rustfix, rustfmt-config_proc_macro, rustfmt-nightly, rustversion, scoped-tls, scopeguard, semver, serde, serde_derive, serde_json, serde_spanned, sha1, sha2, shlex, siphasher, smallvec, socket2, spanned, stable_deref_trait, stacker, static_assertions, string_cache, string_cache_codegen, syn, syn, tar, tempfile, tendril, term, termize, thin-vec, thiserror, thiserror, thiserror-impl, thiserror-impl, thorin-dwp, thread_local, threadpool, tier-check, tikv-jemalloc-sys, toml, toml, toml_datetime, toml_edit, tracing-tree, type-map, typenum, ucd-parse, ucd-trie, ui_test, unic-langid, unic-langid-impl, unic-langid-macros, unic-langid-macros-impl, unicase, unicode-normalization, unicode-properties, unicode-script, unicode-security, unicode-segmentation, unicode-width, unicode-width, unicode-xid, unified-diff, unstable-book-gen, url, utf-8, utf8_iter, utf8parse, uuid, vcpkg, version_check, wasm-bindgen, wasm-bindgen-backend, wasm-bindgen-macro, wasm-bindgen-macro-support, wasm-bindgen-shared, web-time, winapi, winapi-i686-pc-windows-gnu, winapi-x86_64-pc-windows-gnu, windows, windows, windows-bindgen, windows-collections, windows-core, windows-core, windows-future, windows-implement, windows-implement, windows-interface, windows-interface, windows-link, windows-numerics, windows-result, windows-result, windows-strings, windows-strings, windows-sys, windows-sys, windows-sys, windows-sys, windows-targets, windows-targets, windows-targets, windows-threading, windows_aarch64_gnullvm, windows_aarch64_gnullvm, windows_aarch64_gnullvm, windows_aarch64_msvc, windows_aarch64_msvc, windows_aarch64_msvc, windows_i686_gnu, windows_i686_gnu, windows_i686_gnu, windows_i686_gnullvm, windows_i686_gnullvm, windows_i686_msvc, windows_i686_msvc, windows_i686_msvc, windows_x86_64_gnu, windows_x86_64_gnu, windows_x86_64_gnu, windows_x86_64_gnullvm, windows_x86_64_gnullvm, windows_x86_64_gnullvm, windows_x86_64_msvc, windows_x86_64_msvc, windows_x86_64_msvc, winsplit, xattr, xz2
Apache-2.0 OR MIT OR Zlib (5): miniz_oxide, objc2-core-foundation, objc2-io-kit, tinyvec, tinyvec_macros
Apache-2.0 WITH LLVM-exception (3): ar_archive_writer, rustc_apfloat, wasi-preview1-component-adapter-provider
BSD-2-Clause (1): arrayref
ISC (1): libloading
MIT (79): bincode, bytes, capstone, capstone-sys, cargo_metadata, cargo_metadata, cfg_aliases, comma, console, curl, curl-sys, darling, darling_core, darling_macro, fs_extra, generic-array, html-escape, indicatif, jsonpath-rust, levenshtein, lexopt, libm, libredox, matchers, minifier, mio, new_debug_unreachable, nix, nom, nu-ansi-term, nu-ansi-term, number_prefix, openssl-sys, overload, owo-colors, owo-colors, pad, papergrid, parse-zoneinfo, phf, phf_codegen, phf_generator, phf_shared, precomputed-hash, prettydiff, pulldown-cmark, pulldown-cmark-escape, punycode, quine-mc_cluskey, redox_syscall, redox_users, redox_users, ruzstd, ruzstd, schannel, sharded-slab, slab, spdx-expression, spdx-rs, strsim, strum, strum_macros, synstructure, sysinfo, tabled, tokio, tracing, tracing-attributes, tracing-core, tracing-error, tracing-log, tracing-subscriber, twox-hash, twox-hash, utf8-width, valuable, winnow, winnow, yansi-term
MIT OR Unlicense (12): aho-corasick, globset, ignore, jiff, jiff-static, memchr, regex-automata, regex-automata, same-file, termcolor, walkdir, winapi-util
MPL-2.0 (2): colored, option-ext
N/A (106): build-manifest, build_helper, bump-stage0, cargotest2, clippy_config, clippy_dev, clippy_lints_internal, compiletest, coverage-dump, generate-copyright, generate-windows-sys, html-checker, installer, jsondocck, jsondoclint, linkchecker, lint-docs, miropt-test-tools, opt-dist, remote-test-client, remote-test-server, replace-version-placeholder, run_make_support, rustc-main, rustc_abi, rustc_arena, rustc_ast, rustc_ast_ir, rustc_ast_lowering, rustc_ast_passes, rustc_ast_pretty, rustc_attr_data_structures, rustc_attr_parsing, rustc_baked_icu_data, rustc_borrowck, rustc_builtin_macros, rustc_codegen_llvm, rustc_codegen_ssa, rustc_const_eval, rustc_data_structures, rustc_driver, rustc_driver_impl, rustc_error_codes, rustc_error_messages, rustc_errors, rustc_expand, rustc_feature, rustc_fluent_macro, rustc_fs_util, rustc_graphviz, rustc_hashes, rustc_hir, rustc_hir_analysis, rustc_hir_pretty, rustc_hir_typeck, rustc_incremental, rustc_index, rustc_index_macros, rustc_infer, rustc_interface, rustc_lint, rustc_lint_defs, rustc_llvm, rustc_log, rustc_macros, rustc_metadata, rustc_middle, rustc_mir_build, rustc_mir_dataflow, rustc_mir_transform, rustc_monomorphize, rustc_next_trait_solver, rustc_parse, rustc_parse_format, rustc_passes, rustc_pattern_analysis, rustc_privacy, rustc_proc_macro, rustc_query_impl, rustc_query_system, rustc_resolve, rustc_sanitizers, rustc_serialize, rustc_session, rustc_smir, rustc_span, rustc_symbol_mangling, rustc_target, rustc_trait_selection, rustc_traits, rustc_transmute, rustc_ty_utils, rustc_type_ir, rustc_type_ir_macros, rustdoc, rustdoc-gui-test, rustdoc-json-types, rustdoc-themes, rustdoc-tool, stable_mir, suggest-tests, test-float-parse, tidy, unicode-table-generator, wasm-component-ld-wrapper, x
Unicode-3.0 (33): icu_collections, icu_list, icu_list_data, icu_locale_core, icu_locid, icu_locid_transform, icu_locid_transform_data, icu_normalizer, icu_normalizer_data, icu_properties, icu_properties_data, icu_provider, icu_provider, icu_provider_adapters, icu_provider_macros, litemap, litemap, potential_utf, tinystr, tinystr, writeable, writeable, yoke, yoke, yoke-derive, yoke-derive, zerofrom, zerofrom-derive, zerotrie, zerovec, zerovec, zerovec-derive, zerovec-derive
Zlib (1): foldhash
```

dullbananas
Wed 02 Jul 2025 03:27:05 PM UTC, comment #7: 

comment #6:

> comment #5:
> > If a file is generated automatically, it doesn't mean it isn't copyrightable, does it?
>
> Correct, it isn't copyrightable.


In other words, if I unpack your tarball and then automatically generate an archive containing all files from it, then that generated archive will be uncopyrightable.  Is that what you are saying?

> The "AND" operator means that compliance with multiple licenses is needed. I got this license expression with `dnf info` which seems to show overly verbose license expressions, possibly generated from per-file license data. I'm more awake now, so I now know that "Apache-2.0" (permissive) and "CC0-1.0" (public domain) are redundant because they are compatible with GPL.
>
> Also I now noticed that there's a non-GPL-compatible license "CC-BY-SA-4.0".


To be precise, it's only compatible with GPLv3.

> I looked at the project's README, and it says that this license is for the documentation. My project does not require installing the documentation.
>
> In conclusion, this dependency is GPL-3.0-or-later.


I see; thank you!

comment #4:

> - cargo, <https://github.co ... m/rust-lang/cargo>, MIT OR Apache-2.0


Its README.md says it contains some software under more licenses
(LICENSE-THIRD-PARTY).  Could you analyze it?

While at it, there is no single "MIT" license: people use it to refer to a number of various licenses.

> - rust, <https://github. ... /rust-lang/rust>, MIT OR Apache-2.0


The COPYRIGHT file says (the emphasis is mine),

> Except as otherwise noted, Rust is licensed...


What do you think about it?

Ineiev <ineiev>
Site Administrator
Tue 01 Jul 2025 08:36:59 PM UTC, comment #6: 

comment #5:

> If a file is generated automatically, it doesn't mean it isn't copyrightable, does it?


Correct, it isn't copyrightable.

> > - reuse, <https://github.co ... m/fsfe/reuse-tool>, Apache-2.0 AND CC0-1.0 AND CC-BY-SA-4.0 AND GPL-3.0-or-later
>
> Could you explain what this means?


The "AND" operator means that compliance with multiple licenses is needed. I got this license expression with `dnf info` which seems to show overly verbose license expressions, possibly generated from per-file license data. I'm more awake now, so I now know that "Apache-2.0" (permissive) and "CC0-1.0" (public domain) are redundant because they are compatible with GPL.

Also I now noticed that there's a non-GPL-compatible license "CC-BY-SA-4.0". I looked at the project's README, and it says that this license is for the documentation. My project does not require installing the documentation.

In conclusion, this dependency is GPL-3.0-or-later.

dullbananas
Tue 01 Jul 2025 04:44:52 PM UTC, comment #5: 


comment #4:

> Cargo.lock and rust_fmt_version.txt intentionally don't contain notices because they are automatically generated.


If a file is generated automatically, it doesn't mean it isn't copyrightable, does it?

> - reuse, <https://github.co ... m/fsfe/reuse-tool>, Apache-2.0 AND CC0-1.0 AND CC-BY-SA-4.0 AND GPL-3.0-or-later


Could you explain what this means?

Ineiev <ineiev>
Site Administrator
Tue 01 Jul 2025 07:10:58 AM UTC, comment #4: 

New tarball is attached.

Cargo.lock and rust_fmt_version.txt intentionally don't contain notices because they are automatically generated.

Additional dependencies needed for use:
- cargo, <https://github.co ... m/rust-lang/cargo>, MIT OR Apache-2.0
- rust, <https://github. ... /rust-lang/rust>, MIT OR Apache-2.0

Additional dependencies for development:
- rustup, <https://github.co ... /rust-lang/rustup>, MIT OR Apache-2.0
- clippy, <https://github.co ... -lang/rust-clippy>, MIT OR Apache-2.0
- rustfmt, <https://github.co ... rust-lang/rustfmt>, Apache-2.0 OR MIT
- reuse, <https://github.co ... m/fsfe/reuse-tool>, Apache-2.0 AND CC0-1.0 AND CC-BY-SA-4.0 AND GPL-3.0-or-later
- any implementations of the POSIX commands `env` and `sh`

(file #57347)

dullbananas
Sat 28 Jun 2025 12:53:47 PM UTC, comment #3: 

Please make sure that all copyrightable files in your tarball have valid copyright and license notices.  While at it, please use an exact text copy of the AGPL from https://www.gnu.o ... nses/agpl-3.0.txt.

Also, I wonder if you miss any dependencies---for example, I would expect that your users need an implementation of Rust in order to use your software.  Am I wrong?

Ineiev <ineiev>
Site Administrator
Fri 27 Jun 2025 09:49:55 AM UTC, comment #2: 

I guess I submitted it prematurely. Attached here is a newer version that's a lot more finished.

Also, this project is more tricky/demanding than it seems at first glance. Especially since it parses an undocumented unstable format, and there will be heavy demand for reliability and clarity when other libre software uses it for an import feature. It doesn't make sense to host this project without bug tracking, mailing list, patch submissions, etc.

(file #57336)

dullbananas
Thu 26 Jun 2025 01:44:17 PM UTC, comment #1: 

Your package is basically a short single file.  We discourage simplistic packages on Savannah.  They can be hosted on a single web page and needn't a full-fledged Savannah group.

Ineiev <ineiev>
Site Administrator
Thu 26 Jun 2025 03:41:35 AM UTC, original submission:  

A new group has been registered at Savannah.
This group will remain inactive until a site admin approves
or discards the registration.


Registration Administration


Approving or discarding the registration must be done using the specific
Group administration page, accessible only to site
administrators logged in as superusers.

Registration Details


  • Name: serde-catholicmatch
  • System Name:  serdecm
  • Type: non-GNU software and documentation
  • License: GNU Affero General Public License v3 or later





Description:

(Rust library) Parser for user data exports that are provided by CatholicMatch


Other Software Required:

[
  {
    "name": "itoa",
    "version": "1.0.15",
    "authors": "David Tolnay <dtolnay@gmail.com>",
    "repository": "https://github ... m/dtolnay/itoa",
    "license": "Apache-2.0 OR MIT",
    "license_file": null,
    "description": "Fast integer primitive to string conversion"
  },
  {
    "name": "memchr",
    "version": "2.7.5",
    "authors": "Andrew Gallant <jamslam@gmail.com>|bluss",
    "repository": "https://github.co ... BurntSushi/memchr",
    "license": "MIT OR Unlicense",
    "license_file": null,
    "description": "Provides extremely fast (uses SIMD on x86_64, aarch64 and wasm32) routines for 1, 2 or 3 byte search and single substring search."
  },
  {
    "name": "proc-macro2",
    "version": "1.0.95",
    "authors": "David Tolnay <dtolnay@gmail.com>|Alex Crichton <alex@alexcrichton.com>",
    "repository": "https://github.co ... olnay/proc-macro2",
    "license": "Apache-2.0 OR MIT",
    "license_file": null,
    "description": "A substitute implementation of the compiler's `proc_macro` API to decouple token-based libraries from the procedural macro use case."
  },
  {
    "name": "quote",
    "version": "1.0.40",
    "authors": "David Tolnay <dtolnay@gmail.com>",
    "repository": "https://github. ... m/dtolnay/quote",
    "license": "Apache-2.0 OR MIT",
    "license_file": null,
    "description": "Quasi-quoting macro quote!(...)"
  },
  {
    "name": "ryu",
    "version": "1.0.20",
    "authors": "David Tolnay <dtolnay@gmail.com>",
    "repository": "https://github ... om/dtolnay/ryu",
    "license": "Apache-2.0 OR BSL-1.0",
    "license_file": null,
    "description": "Fast floating point to string conversion"
  },
  {
    "name": "serde",
    "version": "1.0.219",
    "authors": "Erick Tryzelaar <erick.tryzelaar@gmail.com>|David Tolnay <dtolnay@gmail.com>",
    "repository": "https://github. ... /serde-rs/serde",
    "license": "Apache-2.0 OR MIT",
    "license_file": null,
    "description": "A generic serialization/deserialization framework"
  },
  {
    "name": "serde-catholicmatch",
    "version": "0.1.0",
    "authors": null,
    "repository": null,
    "license": "AGPL-3.0-or-later",
    "license_file": null,
    "description": "Unofficial deserializer for user data exports that are provided by CatholicMatch"
  },
  {
    "name": "serde_derive",
    "version": "1.0.219",
    "authors": "Erick Tryzelaar <erick.tryzelaar@gmail.com>|David Tolnay <dtolnay@gmail.com>",
    "repository": "https://github. ... /serde-rs/serde",
    "license": "Apache-2.0 OR MIT",
    "license_file": null,
    "description": "Macros 1.1 implementation of #[derive(Serialize, Deserialize)]"
  },
  {
    "name": "serde_json",
    "version": "1.0.140",
    "authors": "Erick Tryzelaar <erick.tryzelaar@gmail.com>|David Tolnay <dtolnay@gmail.com>",
    "repository": "https://github. ... m/serde-rs/json",
    "license": "Apache-2.0 OR MIT",
    "license_file": null,
    "description": "A JSON serialization file format"
  },
  {
    "name": "syn",
    "version": "2.0.104",
    "authors": "David Tolnay <dtolnay@gmail.com>",
    "repository": "https://github ... om/dtolnay/syn",
    "license": "Apache-2.0 OR MIT",
    "license_file": null,
    "description": "Parser for Rust source code"
  },
  {
    "name": "unicode-ident",
    "version": "1.0.18",
    "authors": "David Tolnay <dtolnay@gmail.com>",
    "repository": "https://github.co ... nay/unicode-ident",
    "license": "(MIT OR Apache-2.0) AND Unicode-3.0",
    "license_file": null,
    "description": "Determine whether characters have the XID_Start or XID_Continue properties according to Unicode Standard Annex #31"
  }
]


Tarball URL:

https://savannah. ... holicmatch.tar.gz


dullbananas

 

Attached Files

Attached Files

(Note: upload size limit is set to 4.0MiB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

 

Dependencies

This item does not depend on any other items.

No items depend on this one.

 

Mail Notification Carbon-Copy List

Carbon-Copy List
  • -email is unavailable- added by ineiev (Posted a comment)
  • -email is unavailable- added by dullbananas (Submitted the item)
  •  

    Votes

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

    History

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2025-12-07 dullbananas Attached File- Added serde-catholicmatch-2025-12-06.tar.gz, #57928
    2025-07-09 dullbananas Attached File- Added serde-catholicmatch-2025-07-08.tar.gz, #57379
    2025-07-01 dullbananas Attached File- Added serde-catholicmatch-2025-06-30.tar.gz, #57347
    2025-06-27 dullbananas Attached File- Added serde-catholicmatch-2025-06-27.tar.gz, #57336
    2025-06-26 ineiev StatusNone In Progress
        Assigned toNone ineiev

    Back to the top

    Powered by Savane 3.16-a7ba.
    Corresponding source code