On 15 August 2014 03:11, Richard Shaw <hobbes1069@xxxxxxxxx> wrote: > I'm part curious and part venting.... > > I am trying to get a cross-platform project I'm working on building natively > on win32 as I've already got it working nicely on Fedora and Fedora mingw. > > I've ended up with the MSYS2 project, which while a big young (try to find > documentation!) I think it's a vast improvement on the old msys/mingw > project. > > I was having trouble with the wxWidgets cmake module messing up the parsing > up the output from wx-config and I found the problem and provided a > *TRIVIAL* patch. > > Next this guy tells me that we should upstream it (sure, always a good idea) > and wait until they incorporate it to fix it on msys2, which of course would > leave me without a working build (except for the fact i already fixed it for > myself) and anyone else who needed it to work. > > I thought I was done but next I was told: > """ > OTOH when you apply a patch you are forking the project. This has severe > consequences for the community (and creates extra work for the > maintainers.) Right now MSYS2 CMake has a single, simple patch which is > related to MSYS2 itself, while your patch addresses a CMake bug which is > not MSYS2-specific. The moment Alexey applies it, he is taking the role > of CMake maintainer. Multiply this by the hundreds of packages MSYS2 > has... > """ > > Does patching software legally make it a fork? > I'm not aware of any legal definition of a fork (IANAL etc.). There are derivatives of copyrighted material, which open source licenses allow (if they don't they're not usually regarded as open source). Your correspondent is right, you have a fork in that the source they are using is no longer the upstream, it may be a trivial patch (and a trivial fork), but they're making a point about the difficulty of maintaining this in what is effectively a distro (many packages and sources) and that upstream is the best place for patches. Exactly where people draw the line in patches that haven't made it into upstream will vary between projects (you'll find many Fedora srpms that contain patches), if it's not a critical one for many people (e.g. heartbleed) then I wouldn't be surprised if they wait for the patch to come in from upstream rather than patch it in the build, especially if one person is looking after hundreds of packages. In the meantime there is absolutely nothing stopping you from applying a patch locally. (I'm very sympathetic to your plight as I've been waiting months to try and get a known patch from the actual author of the original code into the kernel.) -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
