Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)

2013/6/7 Corinna Vinschen <vin...@re...>

> On Jun  7 00:17, Алексей Павлов wrote:
> > Hi, everybody!
> >
> > I have work on creating MSYS2 based on latest Cygwin sources and now
> create
> > archives with alpha version.
> > Links:
> > 32-bit:  x32-msys2-alpha-20130607.7z<
> http://sourceforge.net/projects/msys2/files/Alpha-versions/32-bit/x32-msys2-alpha-20130607.7z/download
> >
> > 64-bit:  x64-msys2-alpha-20130607.7z<
> http://sourceforge.net/projects/msys2/files/Alpha-versions/64-bit/x64-msys2-alpha-20130607.7z/download
> >
> >
> > MSYS2 is still using Cygwin like posix paths with /cygdrive prefix.
> >
> > I would be happy if it can be tested by users who uses MSYS environment.
> > Information about issues you can send to al...@gm... or in this
> > thread.
>
> This binary archive has a serious licensing problem.
>
> I checked the git source repository on sourceware and found that there
> is absolutely *no* change compared to the Cygwin source repository, none
> at all.  If you build from the git repo, the resulting DLL will be
> basically identical to the 2013-06-06 snapshot from
> http://cygwin.com/snapshots/
>
> Also, right now, the accompanying tools and DLLs are named as their
> Cygwin counterparts.  They still use the original names cygcheck.exe,
> cygpath.exe, cyglsa{64}.dll, cygwin-console-helper.exe, cygserver.exe.
> Isn't that, to say the least, strange?
>
> But more importantly, in the aforementioned binary archives, the DLL is
> called msys-2.0.dll.  Additionally, calling `uname -sro' returns
>
>   MSYS_NT-6.2-WOW64 2.0.0(0.266/5/3) Msys
>
> rather than
>
>   CYGWIN_NT-6.2-WOW64 1.7.20(0.266/5/3) Cygwin
>
> and inspecting the object file shows more tiny changes.
>
> None of them are available in the git source repository.
>
> I have msys2-1.0-dev branch in git repo as you see. Branch master is
Cygwin code that I sync with source ware and then merge into MSYS branch. I
create git repository on MSYS2.sf.net only today and do not have time yet
to set it properly.

Therefore the binary package infringes the Cygwin license, or, more
> specificially, the underlying GPLv3+.
>
> As representative of the copyright holders, I ask you to fix this ASAP
> by providing the exact sources required to build the msys-2.0.dll and
> it's accompanying tools in the git repo.  I also ask you to adhere to
> the GPLv3, section 5a, by adding prominent notices stating that you
> modified it, and giving a relevant date, in the sources.
>
> Apart from the Cygwin package, the aforementioned binary archives come
> with a lot of binaries from other projects, many of them GPLed.  Where's
> the source code for them?
>
> I still doesn't have packages with source code but I try to upload all
source code archives with patches in a week.


> For GPLv2 packages you could get away with complying to section 3b, but
> that requires to give any of your downloaders the written promise to
> provide the source code within the next three years, which is kind of
> unrealistic, so you *must* provide equivalent source codes according to
> GPLv2, section 3a.
>
> For GPLv3 packages you *must* provide either source codes for all binary
> packages as well, or you must maintain clear directions next to the
> object code saying where to find the corresponding sources, according to
> section 6d.  If you made changes to the upstream sources to build the
> packages, you also have to adhere to section 5.  If the changes are not
> upstream, you have to provide the source changes.
>
> For non-GPL packages I suggest to check their licensing requirements as
> well, especially in terms of the requirement to provide source code.
>
> Please fix this license infringements as soon as possible and keep us
> informed about the progress.
>
> A final note:  I'm not opposing the fork.  Under the GPL it's your
> perfect right to do so, as long as you adhere to the license
> requirements.  But that doesn't mean I have to understand it.  If the
> DLL and the tools are exactly the same and only differ by name, then,
> what's the point?  Wouldn't it make more sense to work with us on the
> Cygwin project instead?
>
> Some times ago we discuss about adding MSYS code to Cygwin on mingw-w64
IRC. It would be more right way I think but I think you don't interesting
in it. I'm right? That is why I create fork of Cygwin. But if it possible
to support MSYS mode in Cygwin sources I think all be happy to not create
many forks an so on.

Regards,
Alexey.