Creating a Win32 Library for GPG?

[Sam Roberts]

From: Paul D. Smith <pausmith at nortelnetworks.com>
To: <gnupg-devel at gnupg.org>
Sent: Tuesday, April 25, 2000 1:08 PM
Subject: Re: Creating a Win32 Library for GPG?


> %% "Sam Roberts" <sam at cogent.ca> writes:
> 
>   sr> The FSFs goal is the end of commercial s/w.
> 
> Not commercial software, of course.  They don't want all software
> development to be done free-of-charge.  The FSF themselves sell their
> own software commercially!
> 
> What they're against is proprietary software, or the idea that when you
> purchase some software you don't actually own it, but just a license to
> use it, and you don't see the source code, etc.

There are a few thousand programmers *paid* for developing GPL
s/w as a primary source of income. Lets call it 10,000 (which I don't
believe). There are 2 million programmers working in the US, or so
I read in a recent DDJ journal. Free s/w development is profitable
in the same way that Amazon.com is profitable, imho, it isn't. It's
done by most people as a side line, to support their money making
ventures: sale of proprietary s/w that benefits from the interoperability
offered by free s/w, or sale of hardware.
 
>   sr> Whether GPL s/w can be dynamically linked to non-GPL s/w is a
>   sr> matter of interpretation: Linus says you can dynamically link
>   sr> non-GPL modules into the GPLed Linux kernel, RMS has stated that
>   sr> he believes this to be against the GPL,
> 
> I'm not sure it's true that Linus interprets this (dynamic linking)
> differently than RMS at all; IIRC Linus added an exception to the
> licensing of the Linux kernel clarifying that modules are to be
> considered separate works, much like the GPL considers different
> programs separate works.  I don't think you can count that as a position
> that dynamic linking in general doesn't violate the GPL.  In fact,
> putting an explicit exception there might show he thinks otherwise.

There is no such exception (I just checked). It's distributed under
the terms of GPL v2, 1991. So his statement that modules are
seperate works must indicate a belief that this is in agreement with
the GPL.

So, either what the kernel does to load modules isn't really dynamic
linking (yeah, right!) or dynamic linking isn't considered to require
the linked code to be under the GPL. RMS has publicly stated (sorry,
I don't have ref anymore, so I may be paraphrasing, but I don't
think so) that he believes that proprietary Linux modules are in
violation of the GPL.
 
>   sr> but copyright holders must enforce their copyright, so its a grey
>   sr> area.
> 
> This is true, but I think the "grey" comes in when you try to define a
> "derived work", from a legal standpoint, and not so much how the license
> is meant to be applied.

Exactly.

Static linking -> GPL: derived, LGPL: not derived.
Shared library -> derived
dynamic linking -> maybe derived.
Use as a "co-processing engine" via pipes -> not derived.
Use as a server via sockets -> not derived

I see this as a continuum.
 
> That is, the "grey" is the question of whether the GPL can actually
> enforce this clause in a dynamic linked sense, or, even if it
> theoretically could, whether the legal wording of the GPL _does_ enforce
> it.

RMS says it does, but that's just his opinion, his wife's the lawyer,
he's just a programmer. :-)

If I could grap large parts of the gnupg source,
compile it as a Win32 DLL, and then dynamically link that into my proprietary
Windows app, perhaps the gnupg developers would consider that a violation.
Considering that almost everything on a Linux system is now a shared library,
I could make gnupg into a library, call it GPLed, and link it as a shared
library. GPL violation? I sure as hell think so! Otherwise any GPL source
could be made part of a non-GPL program by just making it a shared library!

Now at least you have to make it into a GPLed executable with a nice
co-processing interface, which is a fair bit of work.
 
> Many people (including me) wish the FSF would make some official
> clarifying statements about the new kinds of link technologies and how
> they impact the GPL (CORBA?  Etc.) but so far they haven't.

I guess they don't want to commit until there's trouble. So far
public opinion pressure has seemed to keep everybody in line with
the "spirit" of the GPL. The selling of the rights to the GPLed
code that cracks Cyber Cop is an interesting case. You can't "sell away"
others GPLed rights after you've given them the s/w.
 
>   sr> The LGPL was a strategic move by the FSF to get the gcc compiler
>   sr> accepted when there were no free operating systems. Without
>   sr> libc being LGPLed, no one would use gcc.
> 
> This isn't right.  Anyone can (and many do) use GCC with their system
> libc.  That's perfectly OK.  GCC applies _no_ licensing and _no_
> restrictions on its output, so whether you use GLIBC or not is
> irrelevant.
> 
> The reason the LGPL was created was that since everyone already had a
> system libc for no cost (or at least, included with their OS) already,
> the feeling was no one would use GLIBC if it were licensed under the
> GPL.  So, the LGPL was created to promote the use and progress of
> _GLIBC_.  It didn't have anything to do with GCC.

Hmmm, well I think a compiler and it's library kind-of go hand in
glove, and that the gcc and glibc have a certain synergy, and that
gcc without glibc wouldn't have seen anywhere near the popularity
it has now. I know that gcc alone doesn't put restrictions on its
output.

Of course, the "they'd use another libc" doesn't really
apply to Linux, (don't know what *BSD uses), where it would've been
"this is too intrusive, we'll have to write another from scratch".
 
>   sr> It's also more in-line with commercial compilers which obviously
>   sr> allow linking against and redistributing their libraries. The
>   sr> recent push by the FSF to GPL more libraries instead of LGPLing
>   sr> them is an indication of the strength and popularity of free s/w,
>   sr> allowing them to push closer to there stated goals.
> 
> Yes... well, the FSF has always felt that libraries that were unique or
> a real strength for free software, like readline for example, should be
> GPL'd.  Only libraries that re-implemented other already
> widely-available libraries (libc, termcap, etc.) should use the LGPL,
> else many people wouldn't bother with them.

Yep, the LGPL is the carrot where the GPL stick won't work.
 
Sam