@kittaakos , @svenefftinge , @anton-kosyakov
Found during analysis of our recent “node/npm production dependencies” CQ. See: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=18717#c12
Quick analysis: It looks like there are ~3 GPL-licensed files that are downloaded by the dugite postinstall script (/scripts/download-git.js).
e.g. on Linux this downloads: https://github.com/desktop/dugite-native/releases/download/v2.20.1/dugite-native-v2.20.1-f9ba893-ubuntu.tar.gz
This is the git that dugite bundles. included GPL-licensed files:
If I understand the situation correctly, dugite is a production dependency for the project, that’s needed for our git extension. Whatever it automatically downloads is considered to be “distributed” by the project, since our users have no choice in the matter. We can’t distribute GPL content, even if we do not “link” to it (i.e. does not matter if these files are not called/executed from our code).
I think we need to either:
[original thread by Marc Dumais]
I found this issue that, if implemented, could allow to not download the bundled git: https://github.com/desktop/dugite/issues/182
There is work going on to support the vs code git extension. Would that be considered a way out of this? What are the current consequences of this issue? How much time do we have to fix this?
yes, using the vs code extension instead is potentially a way forward, assuming that it has no such bundled GPL code or other IP issues.
There is no details yet about timeline, but I think this need to be addressed ASAP.
consequences: until we fix this, we are arguably not respecting the license for these GPL files, with all potential consequences of doing that.
seems @ivinokur is working on this and may be able to give an ETA.
Looking in the issue above, I found a link to the vs code extension source git repo, but not of the built extension. Would anyone happen to have that link?
Potential “quick” fix, until we use the vs code extension: fork dugite and remove the built-in git download. This means that we would instead rely on it being already installed on the Theia backend.
Thanks for the link, Akos. Could you boil-down the reason(s) why we cannot? I can see that it would not be ideal, but would it break our git extension?
Let’s put it this way: the short-term choice might be between removing this download somehow or removing the git extension.
BTW, until resolved, this issue blocks our production NPM CQ, which means a freeze on committing anything that adds or changes any production NPM dependency
This feature is not supported in
dugite. You cannot skip the download phase.
But do you think it would be a viable option to fork dugite and have our version skip the download?
(at the cost of requiring a suitable user-installed git on the machine)
I’d provide a patch for the
dugite guys instead. But if we do not want to download the Git executable with
dugite, we should consider dropping it. One has to reimplement it.
Out of curiosity; let assume we have dropped
dugite. What happens if any of our direct or transitive dependencies will (re-)introduce it as a dependency in the future?
Re: direct vs transitive dependency: In that case, I think we would need to get rid of that dependency: for production dependencies, the CQ analysis is on the whole recursive dependency tree, so it does not matter if the “bad” dependency is a direct or transitive one.