Re: [Mingw-users] enable std::thread experimental patch

Preface: this whole discussion REALLY boils down to: IANAL, YANAL, so
nobody needs to listen to either one of us (but the folks who wrote the
GPL FAQ *are* lawyers, so we should probably listen to them). Also, seek
competent counsel and pay for your own analysis of the licenses, if this
is a business-critical need for you.



On 9/1/2011 3:27 AM, Prof Brian Ripley wrote:
> Are you an authority on licensing?

I'm the guy who invented the unpronounceable acronym
http://www.cygwin.com/acronyms/#YANALATEYHSMBSI

So, no, I'm not a laywer, thank god -- and if I was, I probably wouldn't
be giving out free legal analysis on a mailing list (no billable hours).
 Nor did I stay at a Holiday Inn last night -- but I have studied the
issue quite a bit, over the 15 or 20 years I've been involved in the
Free Software movement.  And read what a lot of real lawyers say about
it, including the ones who work for the FSF, and the ones at my company.

Everybody should, slowly and carefully, read the GPL FAQ; it will answer
most questions: http://www.gnu.org/licenses/gpl-faq.html

> I ask because others have posted 
> contrary opinions when asked for clarification by a Mingw.org 
> developer on the gcc lists: see the thread starting
> 
> http://gcc.gnu.org/ml/gcc/2004-06/msg01123.html

That thread is about the *runtime libraries* that are part of gcc itself
-- as you mention below, the libgcc_s*.dll (or libgcc.a), libstdc++*.dll
(or .a), libgfortran*.dll (or .a), etc. [*]

THOSE libraries are "GPL-with-linking-exception", not LGPL or "pure"
GPL.  That *exception* is why you don't have to ship THEIR sources (NOR
your own app's sources) even if you link against them ("pure" GPL would
require you to ship both YOUR sources and THEIR sources; the "exception"
requires you only to ship THEIR sources **IF** you have modified them;
but your own app is not "virally infected")

If I understand correctly, if (say) mingw64 has modified libstdc++, then
they must provide their modified sources with the modified dll. But if I
simply USE that modified libstdc++ as part of a compilation, and don't
change the library, then I can treat it just like I would if it came
from the FSF unmodified: I can (re)distribute that DLL with my apps
without worrying about the DLL's source code (or (re)distribute an exe
that includes bits of the static libstdc++).  But that's only for
libraries that are "GPL-with-linking-exception", which pthreads-win32 is
not.

[*] pthreads-win32 is NOT part of gcc; it is an external lib USED by gcc
to provide threading support on win32.  mingw.org ships a copy of it
with our gcc, but that doesn't make it part of gcc or force gcc's
GPL-with-linking-exception license to apply to it.  It has its own
license -- which happens to be LGPL.

>> 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*.
> 
> Many have expresed the opinion that is no different from the cases of
> libgcc_s.dll, libgfortran.dll and libstdc++.dll.

"Many". Are they lawyers? Did they consult lawyers or the statements of
lawyers (e.g. the gpl faq)?  Did they back it up by quoting parts of the
GPL license in question?

> Indeed, the relevant exception seems to be
> http://www.gnu.org/licenses/gcc-exception.html
> and I see nothing there which removes the obligation to supply sources 
> for those DLLs if you ship them: it only applies to 'Target Code' 
> (which does seem to include static linking against these).

"You have permission to propagate a work of Target Code formed by
combining the Runtime Library with Independent Modules, even if such
propagation would otherwise violate the terms of GPLv3, provided that
all Target Code was generated by Eligible Compilation Processes.  You
may then convey such a combination under terms of your choice,
consistent with the licensing of the Independent Modules."

Combination: e.g. your app + the libstdc++ dll, or your app (with the
included libstdc++.a) bits. (definition included in your link)

Independent Modules: your code (again, definition included at your
link). The definition of this term explicitly excludes the contents of
the GCC runtime libraries.  So, you can convey the "combination" under
terms "consistent with the licensing of the independent modules".  After
that point, the license of the runtime lib itself doesn't come into
play, and you can ship it together with your app (because that is "the
combination").


Now, if you've modified the runtime lib, then at some point you had to
compile it, right?  Well, because its contents are EXCLUDED from the
definition of "Independent Module"s, the license exception doesn't apply
to the product of THAT compilation process. Therefore, distribution of
your new modified runtime lib requires distribution of ITS source.
However, if you then use that modified runtime lib to build another app,
then the same analysis above applies: no viralness extends to
Independent Modules.

But none of that applies to pthreads-win32. Its license is strict LGPL
-- which says "you have to provide source for this library, with all
your changes to it" (Whether it "virally" infects your app with
GPLishness, at all, or only if statically linked, etc, we'll leave to
the real lawyers. I've told you what my company's lawyers say.)

>> (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.
> 
> Is there a static version of pthreads-win32 or is this hypothetical? 

It's about any LGPL library. The upstream pthreads-win32 project does
provide static libs; mingw's packages do not -- even our "libpthread.a"
is just an import lib for the DLL.

> If so, there are different versions of LGPL, and we need to know 
> which you are referring to (3.0 mentions dynamic mechanisms, 2.1 does 
> not, and pthreads-win32 2.8.0 seems to use the latter).

I'm not up on all the differences between the 2.x and 3.0 versions of
the (L)GPL.  I suspect the confusion about dyn/stat linking + LGPL is
*why* LGPL3.0 mentions dynamic linking, but I'll have to research it.

But, to repeat the preface: this whole discussion REALLY boils down to:
IANAL, YANAL, so nobody needs to listen to either one of us (but the
folks who wrote the GPL FAQ *are* lawyers, so we should probably listen
to them). Also, seek competent counsel and pay for your own analysis of
the licenses, if this is a business-critical need for you.

--
Chuck