I wonder if the new Linux compatibility subsystem for Windows provided any motivation for this change? That work seems likely to make Cygwin obsolete eventually, since it allows running unmodified applications rather than porting them.
One big difference between Cygwin and the Linux subsystem is that Cygwin runs Win32 processes, under the Win32 subsystem, so the entire Windows API is available to you. The Linux subsystem (like the Subsystem for UNIX Applications before it) is a separate set of concepts on top of the raw NT system calls, so you get a GNU/Linuxish API instead of the Windows API. With Cygwin you get a GNU/Linuxish API as well as the Windows API.
See, for instance, this discussion about how copy-on-write fork is available as a system call (and had been around for a while, to support SUA), but doesn't work right with the Win32 subsystem, and that means Cygwin can't use it:
The Linux subsystem also runs unmodified Linux binaries-- with WSL, you can (theoretically) run any piece of software compiled for 64-bit Linux, which gives you access to everything in Ubuntu's package manager (Ubuntu's the only distro they ship right now). With Cygwin, programs have to be recompiled for Cygwin, which means you're restricted to programs that are either already in Cygwin's package manager or that you can compile yourself.
As you mention, WSL also isn't stuck with the restrictions that come from Win32 compatibility. One of the big impacts of this is that fork() can be faster (although I'm not sure if it actually is right now) than the mess that is Cygwin's emulated fork(). There are some more subtle distinctions, too, though: for example, WSL maintains Linux's conventions around locking open files and has full case-sensitivity. Cygwin doesn't even try to simulate Linux's behavior for either of those; it maintains Win32's behavior.
>With Cygwin you get a GNU/Linuxish API as well as the Windows API.
Genuine question, why is that useful? Intuitively, it seems like if you ever used that capability, you'd end up with a horrible chimera program that can't run on linux or windows, which doesn't seem good.
Well, the chimera program can totally run on Windows; it just uses a particular DLL for a good chunk of it's runtime. That's not super different from, say, a C# app with some native Win32 code, right?
A couple of plausible scenarios:
1. You have a legacy UNIX app that is now only being used on Windows, but rewriting it entirely is a giant project. You can compile it against Cygwin, and then new development can run on Windows.
2. You have a cross-platform app that needs a few OS-specific things in certain places. Maybe it's some sort of system status checking/auditing tool, maybe it interacts with hardware drivers, etc. You can use #ifdef WIN32 and call Windows-specific APIs, just like you can use #ifdefs to check for Apple-specific or Linux-specific APIs, and you don't have to port your entire app away from the UNIX model.
No, this change was being contemplated over a year ago and the final internal decision was made before the announcement of that Linux compatibility subsystem. It has more to do with the commercial viability of Cygwin as a product.
I'm guessing it was because of pressure from Mingw. A few years ago, Cygwin was the only option, and Mingw was a real pain to use. Now with Mingw becoming more and more mature, I'll bet people were using that instead of Cygwin.
Cygwin and MinGW [or rather, mingw-w64] are really different things with very different use cases. You should use Cygwin when you have POSIX code that you want to compile unmodified on Windows.
You should use mingw-w64 when you can modify your sources (eg. with lots of #ifdef WIN32) to call Win32 APIs, OR if you are using a framework like glib2 which handles those differences for you.
So what do you do if you want to run Linux code on Windows, but you can't use the GPL? Cygwin (was/is) not an option in that case, so you just use MinGW. It's a pain, but it gets the job done.
Not exactly sure what your point is. Cygwin is now LGPL, and the mingw-w64 libraries are all under their own free licenses which are (almost) all compatible with linking to proprietary programs.
In Fedora we have both Cygwin and the Fedora cross-compiler project which packages mingw-w64 compiler and many many precompiled libraries. https://fedoraproject.org/wiki/MinGW
Not exactly sure what your point is. Cygwin is now LGPL
My point was to hypothesize why Cygwin became openGPL. I stated some of the advantages of mingw, and why those might motivate Cygwin to change their licensing.
MSYS is an ancient branch of a common code base with Cygwin, which only needs just enough POSIX content in order to compile the utilities which are included in the toolchain which MSYS supports: the toolchain known as MinGW. That toolchain itself doesn't link programs against MSYS; it links programs against Microsoft's redistributable C run-time library (MSVCRT.DLL). Essentially, MinGW is a cross-compiler.
MSYS is a kind of "non-user-serviceable area" that you wouldn't deal with unless you were hacking on MinGW itself. Say you wanted to add some missing utility to MinGW, and there was some issue between MSYS and that utility requiring MSYS hacking.
If you think that you have a POSIX program that could benefit from being linked against MSYS, you're almost certainly better off just using Cygwin to port it. And now you can redistribute the Cygwin DLL with that program without tainting the program with the GPL.
MSVCRT.DLL isn't redistributable, it's a system component. There are some changes recently that I haven't kept up with to make it easier to target a single C library, but the redistributables all had the compiler version in the name and were not compatible across versions.
"Visual C++ Redistributable Packages install runtime components of Visual C++ Libraries on a computer that does not have Visual C++ installed. The libraries are required to run applications that are developed by using the corresponding version of Visual C++."
Visual C++ libraries are not a core component of Windows; they are run-time support for Visual C++ programs. Microsoft calls them "redistributable".
If you write a program which depends on this, it behooves you to ship the exact version you're testing with and install it in the same directory as your executables. (See the "corresponding version" remark above from Microsoft themselves!)
(Which is why it is a myth that MinGW makes "native" Windows executables that don't need anything; in fact they rely on some program having been installed before them which rudely put some version of the MSVCRT.DLL into the System folder.)
There's a difference between the unversioned MSVCRT.DLL and the versioned MSVCR100.DLL, MSVCR120.DLL, etc. libraries. MSVCRT.DLL is technically private API, for the Windows OS's own use, and its API changes on OS releases. The versioned MSVCRnnn.DLL are intended to be shipped with applications, and that's what's in the download links you provide.
The trouble is (AIUI) that the GPL has an exception for system libraries, and MSVCRT.DLL is shipped with the system and MSVCRnnn.DLL are not. Microsoft legally allows you to redistribute MSVCRnnn.DLL, but does not provide source. Therefore, distributors of GPL apps linked against MSVCRnnn.DLL have no way to satisfy their legal obligations. So MinGW makes life easier for GPL apps, which are a significant part of the target audience, by linking against MSVCRT.DLL instead. This is worse from a software engineering point of view because you're using private / unstable API, but it is not illegal, and it lets you avoid the GPL issue.
The program that put MSVCRT.DLL in a system folder wasn't being rude; it was the Windows setup program itself, which was perfectly allowed to put it there. MinGW is being rude by looking for it. (However, if an app linked against one of the versioned libraries did not ship with the versioned library, then yes, it would be expecting some rude app to have copied the versioned library into the system folder.)
Ouch! MinGW is really in a limbo, sticking its fork into the proverbial toaster. Microsoft can change behaviors in MSVCRT.DLL, which can break MinGW programs.
MSVCRT.DLL is what programs compiled with Visual Studio 6.0 link to. So I think it's safe to expect MS retaining compatibility for the forseeable future.
I have heard that it's possible to talk MinGW into linking against MSVCRnnn.DLL instead, with some effort. And then you have to figure out how to ship the redistributable, both physically and legally, but if you can do that, more power to you. Here's a plausible-sounding set of instructions:
Huh. That's a really interesting idea. I'd be worried about whether it translates to UNIX calls, but it looks like it mostly translates to Win32 calls (that WINE then emulates).
I don't know enough about MinGW to try it, but seems worth a shot!
> Why not just compile MinGW executables using gcc under Cygwin?
I have no idea. A cross toolchain for making Windows programs compiled with GCC, and linked with MSVCRT.DLL could be made available as a Cygwin package. All of the utilities for controlling the build can just be the Cygwin ones; all that is needed is the cross-gcc.
It used to be just "gcc -mno-cygwin" would suffice. Now the cross gcc is available separately, choose one of i686-pc-mingw32-gcc, i686-w64-mingw32-gcc, or x86_64-w64-mingw32-gcc.
MinGW is not getting more and more mature, because it keeps depending on the same library from Microsoft. That library is the big downer in MinGW. MinGW is now dead as a way of doing quick-and-dirty ports of POSIX programs to Windows. (Specifically, quick and dirty porting of non-GPL-ed programs to Windows, such as they are not tainted by the GPL).
Going forward, MinGW is only useful for writing Windows-only programs using GCC, GNU Make and Bash. Well, sort of. Anyone in their right mind will just download a copy of Visual Studio if they want to write Windows programs in C or C++.
MinGW still has a tiny advantage: its path handling is more Windows-like. Cygwin programs do not understand the concept of each drive letter having its own current directory, so that drive-letter-qualified relative paths are possible. A drive relative path like "C:foo/bar/txt" does not work properly in Cygwin. What it is supposed to do is resolve against the current directory that is associated with the C: drive. I think what happens is that it gets treated as "C:/foo/bar.txt". If you compile a command line utility with Cygwin, and that utility works with path arguments, it will surprise Windows users in some circumstances. Perhaps Cygwin can fix this issue someday (if it hasn't already; I haven't been tracking this).
MinGW is particularly useful as part of a cross compilation chain for Windows targeting the native Windows APIs. That way you don't have to run Windows as part of a CI process.
I wrote:
> keeps depending on the same library from Microsoft.
It's actually worse. What I didn't understand it that it depends on an internal library which Microsoft says applications aren't supposed to use! See informative comment by geofft:
Cygwin handles the drive letter situation using a special directory under it's root called cygdrive. Each drive letter is exposed as a sub directory of it so in your example the path is:
/cygdrive/c/foo/bar.txt
Not saying it's any prettier but that's how they do it. Not sure how they do this but thankfully it doesn't nest recursively. Say you install cygwin on your C: drive. If you do "cd /cygdrive/c/cygwin" and then ls you'll see cygdrive as a directory entry but if you cd into it and ls again there are no drive letters. The only place the drive letter directories are exposed is directly under /cygdrive.
I seem to recall that once upon a time, only the /cygdrive convention worked in Cygwin. But for years now, Cygwin has supported supported drive letter prefixes, as in c:/foo/bar.txt. Thus, effectively, /cygdrive/c can be regarded as a legacy hack. Sort of. If you do "cd c:" you end up with "/cygdrive/c" as your current working directory.
Backslashes work fine, too; try "ls c:\\temp".
I'm going to oversimplify a bit, but unmodified applications cannot have a native GUI or break out of the Linux Subsystem sandbox (other than network connections).
You can cheat using VNC to localhost, of course ;)
I have it installed, and still rely on Cygwin for projects that live on my Windows directory.
One thing that I didn't see mentioned here that I'd like to point out (again) is that the Ubuntu on Windows stuff is CLIENT ONLY aimed at developers.
Microsoft has said that they have no plans to push it to / support it on their Server OSs. If you're planning on SERVING something with Windows + Linuxy stuff on top of it, Ubuntu on Windows is not an option.
> Excellent; always nice to see fewer copyright assignments and CLAs in the world.
I am the origin of the blanket assignments (among other things -- Cygnus founder). The purpose of the blanket assignment was to ensure that the FSF would have standing to sue in the case of a GPL violation. If you only contribute a small amount it might not matter (because any material violation probably would include other, covered code) but if you end up contributing a somewhat self-contained module or function it does.
Now, more than 25 years later, it's less of a problem, and something somewhat unitary like the Linux kernel survives with many many copyright holders, but for something smaller like Cygwin it makes more sense. I guess rhat figured it wouldn't matter any more -- hope they're right!
"If you only contribute a small amount it might not matter"
I wouldn't be so sure.
FWIW, Victoria Hall, who litigated the first GPL case with a real decision in the US (https://en.wikipedia.org/wiki/Jacobsen_v._Katzer) , told me she had to run around and get some ridiculous number of assignments (I want to say 200 but i could be misremembering), even for folks who contributed very small amounts of code.
"Now, more than 25 years later, it's less of a problem"
It depends. GPL enforcement folks will tell you it's an even larger problem now than it was before, but in the end, i don't think it's the assignment parts that cause the most pressing issues.
Outside of copyright the bigger problem for larger projects is maintaining patent peace among larger participants particularly when they compete outside of the open source project, and CLA's solve this problem (and if you do it right, make it clear to all participants they contribute on the same terms, nobody is special)
> "Now, more than 25 years later, it's less of a problem"
> It depends. GPL enforcement folks will tell you it's an even larger problem now than it was before, but in the end, i don't think it's the assignment parts that cause the most pressing issues.
Well, I would have said (well, in fact I did say) that the Linux kernel's lack of assignments would cause problems but in practice it hasn't.
The point of the blanket assignments was to avoid running around to get the scraps, as I mentioned, but again in practice if code includes chunks from Alice and Bob plus a few scraps from Carol and David, Alice and Bob can have standing to sue even if the ownership of Carol and David's one-liners is unclear in the eyes of the court. BUT if ownership is clear and it's all Fred's (i.e. FSF's! :-) then it removes a possibly expensive diversion as the infringer tries to attack standing.
Funny you should say that; there were two related reasons:
1 - the reason we didn't sell support for Linux is we couldn't provide the same level of support that we did for gcc etc. What we didn't comprehend is that most people didn't _want_ any support, or at least only minimal support, but they were used to paying for software and liked the idea of getting it on a physical medium with a paper manual.
2 - when the companies merged they were both about 200 people. RH had 20 engineers while we had over 160. Our revenue was about 15X theirs IIRC. But indeed: which company had a larger market cap? I was told when they went public they only had 6 engineers but I don't know if that was true.
" but again in practice if code includes chunks from Alice and Bob plus a few scraps from Carol and David, Alice and Bob can have standing to sue even "
Maybe.
It's a much harder thing to prove in practice :)
"then it removes a possibly expensive diversion as the infringer tries to attack standing."
Yes, 100% agreed.
It's not obvious to me what patent issues would require CLAs to avoid - if inbound=outbound licensing is insufficient, isn't the problem just that you're using the wrong license?
There is no right license for things like, say, compilers and runtime libraries, that is compatible and usable with the licenses of all the things that want to use them, and also provides the kind of patent protection and wording necessary to have this kind of happiness.
Basically, Apache2 would be the right license if it was GPLv2 compatible and had no attribution clause.
Making it GPLv2 compatible, however, requires removing exactly the set of patent clauses you want to use to protect downstream users.
Ok, GPLv2 is a problem, that's understandable. An alternative could be some sort of mandatory dual-licensing scheme but that would be a bit ugly and confusing and perhaps worse than CLAs in practice.
"to ensure that the FSF would have standing to sue in the case of a GPL violation"
At least by the time of the acquisition of Cygnus, the copyright assignment for Cygwin was a conventional one which gave Cygnus ownership of essentially the entirety of copyright in the Cygwin library. If Cygnus earlier used copyright assignments that were effectively assignments to the FSF rather than to Cygnus, that is ... possible but strange.
There are two different things. Employees of the company of course assigned their work to us and then we made sure the appropriate entity (in practice mostly either us or the FSF) owned the entirety of the corpus. These assignments were third parties who contributed code, so we wouldn't have to chase down piecemeal assignments bit by bit.
Ah, I see. Cygnus employees were mainly contributing to GNU projects requiring copyright assignment where they weren't working on Cygnus-specific stuff, and were very often the maintainers of those projects (thus having responsibility to administer the FSF's copyright assignment policy), so I can see how the situation might have been thought of as 'you either assign copyright to Cygnus or to the FSF, whichever is appropriate'. And indeed there is some language maybe still on cygwin.com as of this date that says something a bit like that.
You're making things more complicated than they were. We had hundreds of developers; they weren't all the individual maintainers (though collectively of course we were, and de jure once I managed to split egcs off (now gcc) and get people comfortable with the idea of forking).
Everyone who worked for us just signed the usual assignment and we automatically assigned ownership (via the first blanket assignment) to the FSF where appropriate. No employee had to think about ownership -- if you worked on FSF code it belonged to the FSF.
And due to the way California law works, if you worked on FSF stuff on your own time but using a work computer (and we didn't care if you did) it'd automatically belong to us..which would automagically assign it straight to the FSF!
Thanks for Cygwin -- it's been really useful to me over the years! I also think it's been underappreciated as a "gateway drug" to free software. Cygwin's big selection of packages opens up a lot of quality free software to people who are otherwise unwilling or unable to run a free OS. I personally used it in a work environment where I was permitted to install software but not a new OS.
Agreed. Cygwin was the only surviving project arising out of Red Hat to use copyright assignment, Red Hat having maintained Cygnus's late-1990s-vintage copyright assignment policy without substantive change until now. (The text of the Cygwin copyright assignment is actually adapted from the form used by the FSF in the 1990s.)
However the project will not be adopting an "inbound=outbound" or DCO contribution policy until 2020. This is because Red Has some continuing license-related obligations to existing "buyout license" customers that the mere license change to LGPL does not address. In 2020 the last of those obligations will have ended.
What the project will be doing going forward, until 2020, is requiring contributions to be made under the 2-clause BSD license. It's a sort of symbolic change during that interim period, although the end of the red tape around contributing to Cygwin will be generally appreciated.
So does this mean that we'll expect to see a commercial version of Cygwin in the future? Or is it so that commercially available programs can leverage Cygwin libraries?
Red Hat has had a commercial Cygwin offering (not a different version from the project) ever since the Cygnus acquisition, but this is now being phased out (no new customers will be taken on, and the last existing non-GPL customer license expires in 2020). It is possible that companies other than Red Hat may wish to offer commercial support for Cygwin or some derivative of Cygwin.
The license change does have the effect of making it easier for programs to leverage the Cygwin library without concern about licensing implications. I wouldn't quite say that is the purpose, but if only because Red Hat will no longer be providing commercial support for Cygwin the license change is the right thing to do. (I think there are additional reasons why the license change is right.)
Kind of disappointed to hear this, although at least they did not switch to a permissive license.
What I'm still not sure is why they are dropping copyright assignment. Don't the same litigation problems exist when using LGPL, or is there something I'm missing?
The main reason, I'd say (at least by the time of the Cygnus acquisition) the only reason, for copyright assignment for Cygwin was to ensure that Cygnus/Red Hat was the sole GPL licensor. Thus Cygnus/Red Hat, and only Cygnus/Red Hat, could offer alternative for-fee license arrangements. This was the basis of the business model. Copyright assignment isn't the only means of achieving that result with a GPL-licensed project, but it was the traditional technique and probably the soundest from a legal perspective.
Red Hat is phasing out this commercial model for Cygwin. Hence single-licensor GPL licensing is no longer necessary or, I'd say, appropriate. It has nothing directly to do with litigation issues in any general sense. By 2020, I expect that all contributions to Cygwin will be made under the LGPL, meaning that there will potentially be a diversity of LGPL licensors in contrast to the situation prior to today where there was one GPL licensor.
I hear you on this. I'm currently working on a writeup about the history of open source and the GPL.
The dream of having totally free and open replacements for major tools like Photoshop never really happened. There is a lot of new OSS, but it's all BSDL, Apache, MIT and other license.
I'm not like a hard core Stallman person. I don't run libre-firmware laptops from pre-2008 and I enjoy my Gapps on my phone, but I'm not a big fan of startups/monetization of everything. I think a lot of good ideas are strangled by making them commercially viable.
Cygwin going LGPL allows it to be more widely used, but overall we're going to see less OSS apps as a result.
> I hear you on this. I'm currently working on a writeup about the history of open source and the GPL.
If you're going to write up a history, please use the term "free software". "Open source" didn't exist for a large part of the history of the free software movement (and I would argue that it was a movement to sabotage discussions about freedom).
> The dream of having totally free and open replacements for major tools like Photoshop never really happened. There is a lot of new OSS, but it's all BSDL, Apache, MIT and other license.
It did though. Okay, Photoshop is still not overtaken by GIMP. But we have professional free software video editors, development tools, web and database servers, document writers, etc. These days you can run a modern system entirely in freedom, though of course we would love to make more free software to do things even better.
> I'm not like a hard core Stallman person. I don't run libre-firmware laptops from pre-2008 and I enjoy my Gapps on my phone, but I'm not a big fan of startups/monetization of everything. I think a lot of good ideas are strangled by making them commercially viable.
I'm slowly becoming one, and the main reason why is because I want to work towards the world I want to live in. Sure, lax licensed software is fine to use as a free software advocate. But when I develop free software under a lax license, I'm acting against the free software world I want to live in. By allowing proprietary versions of my software to exist, I am acting against my goals.
I want to live in a world where all of the software I need to use is free. All of the hardware that runs updatable software also must be free. Otherwise, I'm powerless when the developers' company decides to do something immoral. Having code under the GPLv3 protects us from both of these things, and it makes me sad when people use lax licenses for innovative work.
I used to use Photoshop. Most of the killer features are the workflow, which is what GIMP is lacking (GIMP is a bunch of hacked together tools). But that actual toolset is not _that_ complicated if you wanted to pay someone for a year or two to do it.
