-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/15/2014 09:23 AM, drago01 wrote:
On Fri, Aug 15, 2014 at 4:11 AM, Richard Shaw hobbes1069@gmail.com 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 don't know how forking is defined legally or if it is at all but technical yes it is a fork ... but so what?
In terms of the resulting code being a derivative of the original code, you *are* into copyright territory, so it depends on the terms of the license that is in use.
As a general rule, I'd say that as long as a patch is under consideration upstream (or is TRULY platform-specific), it's fine to carry it in your packaging until the upstream gets around to incorporating it.