3 ms·

> more easily support compression across operating systems I cannot help but wonder if this change was forced upon github by Microsoft because gzip is GPL 3, m

by jmclnx 4y ago

> more easily support compression across operating systems I cannot help but wonder if this change was forced upon github by Microsoft because gzip is GPL 3, maybe this other version is a clean room clone. We all know corporations hate GPLv3, including the large corporation I work for. https://www.gnu.org/software/gzip/ https://www.gnu.org/software/gzip/

int_19h 4y ago
Why would that matter for an internal tool? Esp. there's plenty of much more visible GPLv3 bits in WSL images that ship via the Windows app store.
vore 4y ago
If this were true, this would have been a problem a long time ago. Why would Microsoft wait such a long time to change this when under your assumption it would have been a continuous legal liability?
eklitzke 4y ago
First of all the change was made upstream in git, which is not controlled by GitHub (even though GitHub does have some developers who work on git). And the stated reason (not relying on third party tools/libraries) is compatible with many other changes made to git over its history, e.g. the conversion of many git commands from Perl to C. Furthermore, gzip isn't even necessarily the best tool to produce gzip data. If you want multi-core parallelism there's pigz, and if you're willing to trade higher CPU usage to get a better compression ratio you can use zopfli. I don't know the details of the implementation in git and whether it tries to leverage multi-threading or zopfli-like techniques, but the point stands that gzip isn't the final word on producing gzip data.
fukawi2 4y ago
It was git that implemented the change, then github upgraded to the affected version. AFAIK, MS has no influence over upstream git. As much as I distrust Microsoft, I don't think there were any ulterior motives here.
- MikusR 4y ago
  IIRC the change was made by git-for-windows developer. And some of top contributors for git are from Github/Microsoft.

by jmclnx 4y ago

int_19h 4y ago

Why would that matter for an internal tool? Esp. there's plenty of much more visible GPLv3 bits in WSL images that ship via the Windows app store.

vore 4y ago

If this were true, this would have been a problem a long time ago. Why would Microsoft wait such a long time to change this when under your assumption it would have been a continuous legal liability?

eklitzke 4y ago

First of all the change was made upstream in git, which is not controlled by GitHub (even though GitHub does have some developers who work on git). And the stated reason (not relying on third party tools/libraries) is compatible with many other changes made to git over its history, e.g. the conversion of many git commands from Perl to C. Furthermore, gzip isn't even necessarily the best tool to produce gzip data. If you want multi-core parallelism there's pigz, and if you're willing to trade higher CPU usage to get a better compression ratio you can use zopfli. I don't know the details of the implementation in git and whether it tries to leverage multi-threading or zopfli-like techniques, but the point stands that gzip isn't the final word on producing gzip data.

fukawi2 4y ago

It was git that implemented the change, then github upgraded to the affected version. AFAIK, MS has no influence over upstream git. As much as I distrust Microsoft, I don't think there were any ulterior motives here.

MikusR 4y ago
IIRC the change was made by git-for-windows developer. And some of top contributors for git are from Github/Microsoft.