You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.)
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.
The text was updated successfully, but these errors were encountered:
tapioca annotations
andtapioca 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 thattapioca 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.The text was updated successfully, but these errors were encountered: