Jan-Jaap van der Heijden wrote:
The new licensing terms for Cygwin32 permits anyone to make use of Cygwin32 without adhering to the GPL, and without being required to make their sources available, provided that in so doing they are not attempting to directly compete with Cygnus.
Doesn't this contradict the GPL? Or does it refer only to "add-ons" that are not GPLed?
On Sun, 13 Jul 1997, Frank Heckenbach wrote:
Jan-Jaap van der Heijden wrote:
The new licensing terms for Cygwin32 permits anyone to make use of Cygwin32 without adhering to the GPL, and without being required to make their sources available, provided that in so doing they are not attempting to directly compete with Cygnus.
Doesn't this contradict the GPL? Or does it refer only to "add-ons" that are not GPLed?
I think it does. I posted a message to the cygnus mailinglist with my complaints about this new license. The thing is, the new license says that using cygwin.dll is *only* legal when it is used in combination with the Cygnus GNUPro toolkit. GNUPro contains gcc, binutils etc. Other compilers are explicitly denied permission.
<RANT>
This means: 1) GPC is not allowed to use it (regardless of the fact that it's also GNU software etc. etc.)
2) If I modify GCC, it is no longer "GCC as distributed by Cynus as part of Cynus GNUPro" and usage of cygwin.dll is illegal. This limits my freedom to modify GCC as guaranteed by the GPL.
3) Last, but not least: a GNUPro subscription costs several thousand dollars per year, and I don't believe Cygnus will keep distributing free copies once the beta phase is over. (would you?)
There's only one possible conclusion: we have to get rid of any dependency on cygwin.dll a.s.a.p. Cygnus claims this new license is to secure their commercial edge in the embedded systems field. Since embedded systems don't run Windoze, they must be thinking about selling win32-hosted crosscompilers here. But the embedded system support is inside GCC, binutils and gdb. So, you can always use djgpp or a free unix to host your embedded-system tools.
The strength of cygwin.dll is that it makes it easy to port unix apps unmodified to a win32 world. But this is not really important for GPC (a dos-to-unix layer would be more useful ;-) )
Cygwin32 is not the only win32 targeting GCC project. EMX/NT exists for some time, but it uses pre-BFD binutils, so I can't setup a linux->win32 cross toolchain (I always build the win32 GPC binaries on Linux)
Then, there's "mingw32", a modified cygnus-gcc (now also illegal?), which produces binaries that don't rely on cygwin.dll, but use the CRTDLL.DLL which comes with win95 and NT. My current (unpublished) win32-gpc was already using this scheme, because the resulting code runs much faster, and building DLL's is easier.
So, what I did was port GCC and binutils *themselves* to mingw32. It took surprisingly little effort. The result is more or less a win32-djgpp, and neither GCC nor the programs you build with it rely on cygwin.dll anymore. I will build GPC using this scheme soon.
Although it doesn't use cygwin.dll, it is binary compatible with it. So, tools I haven't ported yet I simply borrow from cygwin32.
The funny part is that it's trivial to build my new toolchain targeting an embedded system, which was what Cygnus was trying to prevent. Not only that, but it also doesn't have the funny behaviour of the unix abstracion layer ("mount C: /dosc" -- what, I have to mount my own C drive?). So, it's probably commercially even more interesting to Cygnus' competitors in the embedded systems field than Cygnus' own stuff....
GPC/win32 will live!
</RANT>
Greetings, JanJaap
--- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925.