From: Charles W. <cwi...@us...> - 2011-08-31 23:22:21
|
On 8/31/2011 5:39 PM, K. Frank wrote: > Wasn't there also some licensing issue? I never understood the details, but > I recall seeing warnings, perhaps on one of these lists, that the pthreads-win32 > license was not as liberal as that of mingw / mingw-w64, and that there were > things I couldn't use it for. > > If there are things that I can do with mingw / mingw-w64 that I can't do with > pthreads-win32, have those restrictions been relaxed with winpthreads? pthreads-win32 is LGPL. Most libs ***that are an intrinsic part of the mingw.org compiler*** are either public domain (libmingwex, e.g. no restrictions imposed on compiled programs) or GPL-with-linking-exception (libgcc_s, libstdc++ -- e.g. no restrictions imposed on compiled programs). This is true whether you link statically or dynamically. Assuming you 1) don't link to OTHER libraries with copyleft or viral terms, and that themselves don't require source redist, and 2) your app doesn't have licensing terms requiring source redist you can ship to your clients a binary copy of your app and the DLLs that it links to, without worrying about GPLishness or shipping source code. However, the LGPL pthreads library is an issue. (A) If you ship that dll, you also have to be able to provide the source code *for that copy of the pthreads-win32 dll*. (B) Opinions vary, but some people claim that if you link *statically* against an LGPL library, then the LGPL becomes just as "viral" as the GPL -- and you have to distribute the source code of your application. Kai's winpthreads is partly MIT/X and partly (mostly?) 3-clause BSD. So, "permissive" licensing. Licensing wise, this is clearly a better fit for mingw.org as well as mingw64. -- Chuck |