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?
Thanks and sorry for the rant... Richard
On 15 August 2014 03:11, 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'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.)
On Fri, Aug 15, 2014 at 5:28 AM, Ian Malone ibmalone@gmail.com wrote:
(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.)
Which?
josh
On 15 August 2014 12:30, Josh Boyer jwboyer@fedoraproject.org wrote:
On Fri, Aug 15, 2014 at 5:28 AM, Ian Malone ibmalone@gmail.com wrote:
(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.)
Which?
Oh, it's this one, you've already tried to help with it, https://bugzilla.redhat.com/show_bug.cgi?id=991708 I need to push harder at the lkml to get it taken up (think there was a bit of a derail at the ack stage, not unlike what I've accidentally done to this thread).
On Fri, Aug 15, 2014 at 4:28 AM, Ian Malone ibmalone@gmail.com wrote:
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.
Well I already submitted it upstream but I have no intention of waiting for it. While I really like cmake as a product and much prefer it to autotools, I've seen bugs with trivial fixes sit for years in their bug tracker.
I did patch my local install so I was never worried about waiting for the fix from a practical point of view, I'm more worried about other users that may run into the same problem.
Thanks, Richard
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?
-----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.
-
drago01 -
Ian Malone -
Josh Boyer -
Richard Shaw -
Stephen Gallagher