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

License compliance for content added by tapioca {annotations,gem} #2068

Open
mattmccutchen opened this issue Nov 7, 2024 · 0 comments
Open

Comments

@mattmccutchen
Copy link

tapioca annotations and tapioca gem add potentially copyrighted material to my repository without the corresponding license notices. IANAL, and other people may have reasons why they don't care, but I'm not comfortable with this for the project where I'm planning to adopt Tapioca. So I'm filing an issue to at least call attention to the problem. Apologies if it has been discussed elsewhere; I looked pretty hard and didn't find anything.

Specifically:

  • tapioca gem copies the API structure, documentation comments, and exported RBIs (as applicable) from the specified gem. These are subject to the license of that gem. (The API structure by itself may not be copyrightable.)
  • tapioca annotations copies RBIs from rbi-central. These are subject to the license of rbi-central.

At a minimum, Tapioca should prominently document that as things stand, users are responsible for license compliance. Ideally, Tapioca would automate it as much as practical given ecosystem limitations. For example, it would be pretty easy for tapioca annotations to add a copy of the rbi-central license, but I don't know if there's a standard way that tapioca gem could identify the license file for a given gem. The gemspec reference says that "The full text of the license should be inside of the gem (at the top level) when you build it" but doesn't provide a way to get the actual filename. Even if Tapioca had heuristics that were right most of the time and the user was only responsible for checking the results, that would still be much better than the status quo.

I'd be happy to contribute at least the statement about the problem in the readme. Maintainers, please let me know if you have guidance about that (e.g., where it should go); if I don't hear from you in a while, I may go ahead and make a PR. My willingness to work on an actual solution would be a function of whether we can come up with a reasonable design, how much work it is, and how many users seem to care.

For now, the workaround I'm planning for my project is to manually add the necessary license files and reduce the work to do so by running tapioca gem only on the gems for which our code actually needs type information, rather than letting it run on all of our transitive dependencies by default.

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

1 participant