Cygwin library now available under GNU LGPL
redhat.com
redhat.com
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.
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.
https://support.microsoft.com/en-ca/kb/2977003
"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++."
And an overview here:
https://msdn.microsoft.com/en-us/library/ms235299.aspx
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.)
Here's MSDN talking about it being a system component:
https://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.80).a...
At least since .NET 2003. It's handled differently in 2015.
https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=...
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.)
Now I'm even more motivated to stop using MinGW.
http://source.winehq.org/git/wine.git/tree/HEAD:/dlls/msvcrt
I don't know enough about MinGW to try it, but seems worth a shot!
If so, why did they actually create MSYS(2)? 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.
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).
/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.
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:
https://news.ycombinator.com/item?id=11964589
Oops!
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.
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
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.
Do you have an actual point, or are you just going to continue harassing me over irrelevant things?
If you're doing that, what's the difference between MinGW and compiling for native Windows?
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:
https://social.msdn.microsoft.com/Forums/windowsdesktop/en-U...
I don't know how many actual applications take advantage of this, though. But if they do, then Cygwin is definitely not obsolete for them.
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.
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.
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.
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.
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.
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!
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)
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.
Is this why Cygnus didn't buy Red Hat? :)
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.
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.
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.
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.
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!
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.)
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?
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.
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.
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.