> In particular, e.g. RedHat's policy of publishing only the "final" source code for their patched kernels, and not the git repo with history (which is what the

> In particular, e.g. RedHat's policy of publishing only the "final" source code for their patched kernels, and not the git repo with history (which is what they use when developing it internally) is a straight-up GPL violation as far as I'm concerned. I've worked in the past on an open source project that is forked from an upstream codebase where the git history and all new tests in recent years are proprietary so I'm definitely very sympathetic to that argument. Its very hard to get people who have no experience in that kind of environment to understand just how much work goes into merging such changes and reverse engineering the bugs from the code changes in order to test for them. In that kind of situation, I think you're better off just hard forking but still keeping an eye on upstream's release notes in case they make a specific change that would be useful to your fork. Trying to maintain full compatibility with upstream releases that don't share their git history is a Sisyphean task and that's probably the intent of many of the corporations that do open source that way.