Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Copyright confusion #332

Open
penguin359 opened this issue Feb 11, 2024 · 9 comments
Open

Copyright confusion #332

penguin359 opened this issue Feb 11, 2024 · 9 comments

Comments

@penguin359
Copy link

While working on packaging this crate for Debian, I ran into some confusion on copyright and licensing. I believe the main code base is something along the lines of this:

Copyright (c) 2019-2020 Andrius Aucinas <aaucinas@brave.com>
Copyright (c) 2019-2024 Anton Lazarev <alazarev@brave.com>

And released under the MPL-2.0 license, however, I also ran across a subtree of files that appear to have been imported into this repo, but not mentioned in the top-level LICENSE file. I want to make sure I get the licensing and copyright correct. Specifically, it looks like everything under data/test/fake-uBO-files/ is actually:

Copyright (c) 2014-2022 Raymond Hill

And appears to be licensed under the GPL 3.0 or newer license from a quick glance. Can you please confirm the licensing of these files and let me know if there are any other licenses involved?

@penguin359
Copy link
Author

Actually, I think I found one more file, src/url_parser/parser.rs which is:

Copyright (c) 2013-2016 The rust-url developers.

And licensed under ASL-2.0 or MIT.

@antonok-edm
Copy link
Collaborator

Hi @penguin359, thanks for working on that!

Everything you found so far looks accurate, although I'll add a couple of notes:

  • Brave Software, Inc. licenses under Copyright (c) <year> The Brave Authors by default. Somehow this repo was originally created without that, although I assume it might make things easier for your task if it's possible to use it instead. adblock-rust was developed by both Andrius and I as part of our respective employment contracts with Brave; I just don't know if it's safe to retroactively edit that. I've asked internally.
  • Now that I think about it, I suppose the files under data/ ought to have respective in-tree licenses. That being said, those files aren't intended to be distributed for the purposes of packaging (see Cargo.toml, .npmignore). It's just for regression testing during development. You're welcome to exclude those (if there is a way to do so).
  • If you must include licenses for files under data/, be advised that there are a few other sources, including Easylist (licensing info), NoCoin (license), brave/adblock-lists (license), ABP Japanese filters (licenses?), Disconnect (GPLv3 prior to relicensing), Malware Domain List (no longer active... and I couldn't find a license on the archived version 😬), Spam404 (license), and the uBlock Origin list authors (license).

@penguin359
Copy link
Author

Actually, I now realize that data/ is in the exclude list and I was running my license scanner on the upstream repo instead of the crate source as distributed. If that folder is not included then there's no need for me to worry about including it in the copyright file. Debian prefers upstream tarballs to repositories and, for Rust, that generally means what's downloaded from crates.io. I do want to make sure I have the correct ownership attributed elsewhere as appropriate. If "The Brave Authors" properly describes the owner of the copyright, then that is what I should use.

The one file I do still see with an alternate copyright and license is src/url_parser/parser.rs. I don't see any other mention in other source files for that.

@rillian
Copy link
Contributor

rillian commented Feb 12, 2024

Looks like src/url_parser/parser.rs was forked from rust-url sometime in early 2019, but the repository doesn't preserve the exact original version. The original license and authorship applies to a substantial portion of that file.

@fmarier
Copy link
Member

fmarier commented Feb 12, 2024

Link to the Debian bug for this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063626

@antonok-edm
Copy link
Collaborator

@penguin359 I confirmed there should be no issues using The Brave Authors (along with the The rust-url developers).

I've also opened #333 to track removing the forked rust-url parts, which we probably don't want to keep around for too much longer, but please include that in the meantime.

Anything else needed?

@penguin359
Copy link
Author

OK, for 0.8.6 I'll keep that in the copyright, but I can certainly remove that once a new release is out. Just add a comment to this ticket and I'll update the Debian packaging.

Also, I found one final file in question, src/resources/resource_storage.rs#L23. I've added a mention of it to the Debian copyright file for the moment. I'm not sure how to handle it exactly as it seems to have been modified from the original before it was committed to this repo and it seems to just cover a snippet of code added to an already existing file that was originally clean. I've marked it as best as I can in the Debian DEP-8 syntax. You can check it out here:

https://salsa.debian.org/penguin359/debcargo-conf/-/blob/add-adblock/src/adblock/debian/copyright

Once this is approved, we should be able to get adblock in as an official Debian package.

@antonok-edm
Copy link
Collaborator

antonok-edm commented Feb 13, 2024

Also, I found one final file in question

Good catch, thanks! That looks correct to me.

Just a couple notes on the proposed copyright file you linked:

Upstream-Contact:
 Andrius Aucinas <aaucinas@brave.com>
 Anton Lazarev <alazarev@brave.com>

Andrius no longer works at Brave; I don't think that inbox will get any responses. Probably best to just use my own email there. I originally left his info in the authorship metadata since I didn't want to take all the credit, although I suppose it makes sense to remove at least the email from there too.

Files: *
 Copyright: 2019-2020 The Brave Authors

probably 2019-2024?

@penguin359
Copy link
Author

OK, all fixes have been applied. Package is ready for submission to the Debian project.

antonok-edm added a commit that referenced this issue Feb 20, 2024
To reduce confusion over who to contact about the library. See
#332 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants