Creating a Win32 Library for GPG?

[Paul D. Smith]

%% Sam Roberts <sam at cogent.ca> writes:

  sr> The FSFs goal is the end of commercial s/w.

  >> Not commercial software, of course.

  sr> There are a few thousand programmers *paid* for developing GPL s/w
  sr> as a primary source of income. Lets call it 10,000 (which I don't
  sr> believe). There are 2 million programmers working in the US, or so
  sr> I read in a recent DDJ journal. Free s/w development is profitable
  sr> in the same way that Amazon.com is profitable, imho, it
  sr> isn't. It's done by most people as a side line, to support their
  sr> money making ventures: sale of proprietary s/w that benefits from
  sr> the interoperability offered by free s/w, or sale of hardware.

Of course that's not true.  There are many examples of companies making
money from free software: Cygnus, RedHat, etc. to name a few.  There are
even more examples of companies who do a lot of proprietary software
development paying employees to work (often exclusively) on free
software; consider X11, Perl, Tcl, various companies like NeXT and Data
General that funded GCC development, etc.

_Obviously_ the business model involved with free software development
would have to be significantly different from the current norm.  But
I've certainly seen no definitive proof that it couldn't work.

At any rate, I'm not sure how your comments above directly address my
statement.

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

I'll have to check my Linux box when I get home; I'm sure I recall
seeing a statement about this somewhere in the Linux sources.

  sr> So, either what the kernel does to load modules isn't really dynamic
  sr> linking (yeah, right!) or dynamic linking isn't considered to require
  sr> the linked code to be under the GPL.

Well, I'm not as sure as you are about this.  Why is loading a module
necessarily closer to dynamically linking a shared library than it is to
running exec(2)?  There's a lot of fuzziness about this, esp. when
you're talking about the kernel where there's only one memory space,
etc.

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

I think RMS gets his legal advice from a legal scholar at a University
somewhere, but I've forgotten the name.

  sr> If I could grap large parts of the gnupg source, compile it as a
  sr> Win32 DLL, and then dynamically link that into my proprietary
  sr> Windows app, perhaps the gnupg developers would consider that a
  sr> violation.

You scoff, but in fact RMS has actually said this is OK.  There is at
least one example right now: a proprietary SCM system which uses a
DLL-ified version of RCS (which is GPL'd) to do its underlying per-file
management.

  sr> Now at least you have to make it into a GPLed executable with a nice
  sr> co-processing interface, which is a fair bit of work.

Or, just use expect :).

  sr> Hmmm, well I think a compiler and it's library kind-of go hand in
  sr> glove,

That may be true of some languages, but much less so with C, where the
compiler and the runtime library have always maintained a certain
distance.

And there's _NOTHING_ about GCC that requires or assumes GLIBC in any
way.  Indeed, GCC was a viable and widely-used compiler for a very long
time before GLIBC became a real alternative, which has really only
happened fairly recently due to Linux's requirements.  GCC was a decent
compiler (on at least some platforms) 'way back in the late 80's.  Back
in the early 90's it really got popular because almost no UNIX vendor
was shipping an ANSI standard compiler (now most don't ship _any_
compiler :-/).

  sr> and that the gcc and glibc have a certain synergy, and that gcc
  sr> without glibc wouldn't have seen anywhere near the popularity it
  sr> has now.

I really disagree with that.  The _ONLY_ platforms that use GLIBC are
Linux and Hurd.  Last time I tried it wouldn't even compile on Solaris,
which is the only other system it ever came close to supporting IIRC.

GCC is hugely popular on almost every variant of UNIX and is becoming
more common on Windows.  It even works on VMS.  Some UNIX vendors
provide(d) it as their standard, bundled C compiler rather than writing
their own compiler--but they all wrote their own libc!

GLIBC is _completely_ irrelevant to GCC's popularity and acceptance.

  sr> Of course, the "they'd use another libc" doesn't really apply to
  sr> Linux, (don't know what *BSD uses), where it would've been "this
  sr> is too intrusive, we'll have to write another from scratch".

Right, and it wasn't until Linux came along and really required a
full-featured, standard libc that GLIBC started becoming that.  Before
Linux, there was relatively little going on with GLIBC (at least,
publicly) and even die-hard free software fans never bothered to
build/install it on their platforms.  But nearly everyone got GCC.

(BSD uses the BSD libc, of course.)

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <psmith at baynetworks.com>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.