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

[Jon <jon...@gm...>]

Corrina,

My user-based perspectives embedded below for your consideration...

> On Jun  8 01:56, Алексей Павлов wrote:
> > 2013/6/7 Corinna Vinschen wrote:
> > > 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?
> >
> > ...SNIP...
> 
> The problem is this.  So far I'm wondering what MSYS2 is about.  It
> doesn't add any useful functionality over Cygwin.  And if so, why not
> integrate it into Cygwin instead and only have one project for
> everybody?  JonY already maintains the mingw-w64 32 and 64 bit cross
> toolchains as part of the Cygwin distro, so there's nothing missing for
> those who want to create native applications.

You assume too much when you say "..there's nothing missing..." from the current Cygwin situation.
For example, while scanning the artifacts from JonY's substantial efforts at

  http://cygwin.mirrors.pair.com/release/gcc4/

having older 4.7.2 support is uninteresting for how I use mingw-w64 based toolchains. Furthermore,
JonY's perspective on cross vs native toolchains is very different than mine. Until the mingwbuilds
and ruben's mingw-w64 toolchains became available, the auto-built mingw-w64 toolchains were almost
unusable for me for a variety of reasons.

But is this a problem? No. I simply use mingwbuilds or ruben mingw-64 toolchains and my own tweaks
to take advantage of all of JonY's amazing work without having to share JonY's workflow perspectives.
It doesn't appear that I have this flexibility if I chose Cygwin.


> <emotional mode>
> 
> Other than that I'm rather puzzled as to what MSYS2 is about, other than
> to duplicate developer efforts and to split communities.  Apart from
> your perfect right to fork, you might nevertheless understand that I'm a
> bit annoyed.  Especially given the code base.  Me and Kai were working
> hard for months to create a 64 bit version of Cygwin, and while our
> Cygwin 64 bit distro is still in test mode, you simply rip off the code
> and just release your own MSYS2 distro from there.
> 
> I can't help to feel exploited.
> 
> </emotional mode>


While I'm glad you summarized your emotional views (sadly, too often our emotions are dismissed as somehow
irrelevant (!?) and only technical or analytical views are "acceptable" or "correct" in a discussion), I
truly hope you don't feel exploited.

I view things very differently and think you and Kai should feel honored that someone with a different
perspective than yours respected your and Kai's work enough to use it as the foundation for MSYS2, and
open up the discussion on this list early in the MSYS2 development. I view Alexey's efforts as sharing
rather than "ripping off" and think his work is very much a complement to the work that you and Kai have
done. 


> Back to the technical stuff.  Again, I don't understand the reason for
> the fork, please explain.  What is it, codewise, you really miss in
> Cygwin?  What non-code problems is MSYS2 trying to fix?

It's been a very long time since I used Cygwin, but this discussion will cause me to go back and look at
Cygwin again. That said, the following are user-perspective reasons why I currently don't use Cygwin:

1) I build native applications rather than apps dependent upon the Cygwin DLL.

2) I dislike Cygwin's `setup.exe` gui installation helper. I automate the stitching together of MSYS
functionality with multiple mingw-w64 and mingw.org (non cross) toolchains to create custom toolchains.
Cygwin's integrated `gcc4` support from JonY does not work for me, but I'm very thankful I can take
advantage of JonY's tremendous efforts in other ways. In fact, I'm working on a tool that will use
window's recent symlink behavior to easily switch toolchains via a dir symlink to locations like
`C:\DevTools\mingw` in which the MSYS/MSYS2 goodies live in `C:\DevTools\bin` and the toolchains get
symlinked and switched under `C:\DevTools\mingw` by a tool that works similar to MKLINK.


The bottom line is that while my workflow does not appear to be a good match for Cygwin's primary use cases, I
greatly benefit from MSYS (and likely MSYS2) creative and targeted use of underlying Cygwin capabilities. Even
though I don't directly use Cygwin, I thank you for all your hard work and hope to always have the option of
using a maintained MSYS or MSYS2 bag-o-goodies.

Jon

---
Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat.
http://jonforums.github.io/ | http://thecodeshop.github.io/
twitter: @jonforums