Well, I do believe in free software, and I believe in keeping free software
free. I just don't see why we can't dynamically link with other free libraries
that just don't happen to use the FSF's license.
I'm certainly not asking you to surrender your copyright, though! I'd much
rather work with you on licensing terms for FPM, and I'll risk not being able
to change the license later if I fail to convince at that time that it is a
good idea. The only time I'd ask a contributer to surrender their copyright
is for very minor contributions. I certainly wouldn't consider your
contributions to date minor.
I'm encouraged by your belief that we can work this out with well audited
GPL code. If we really can, that would be ideal.
The benefit of using encryption code from GnuPG like I did in v0.53 is that
it reduces the dependencies FPM has. The reason I went this route last time
was that openssl didn't come with most distributions and installing it wasn't
trivial, especially doing it legally in the US. The downside to using GnuPG
code in this way is that we are more prone to opening security holes through
implementation problems, especially with the wrapper functions.
Anyway, how does this sound? Let's start out with GPL, and retain shared
copyright. We will start out with GnuPG code for the encryption as we do
now, but create wrapper functions for everything so that we can switch to
something else if we find we run into problems later. In fact, we may want
to release the wrapper functions as a GGPL library so that other projects
can use it too that are in the same boat as us. If we do this, we may
attract a better audit of the interface functions than FPM alone would
generate. (We can't release the library under the LGPL because the GnuPG
encryption code is already covered under the GGPL.)
If over the next few weeks we run into problems with using the GnuPG code,
we just need to redefine the interface to bind to another library, like
openssl. In this case, you and I would need to hash out how we would need to
amend the GPL to allow linking with openssl. I think we both agree that we
want a license that keeps derivative works based on FPM as free software, but
allows us to create the most secure implementation possible.
After our initial release, I'd want to attract attention to our project and
attempt to get others to audit our code. After I feel that at least a few
people have looked at the code, we will allow ourselves to commit to our
implementation and software license by being less careful of who owns the
How does this sound?
BTW - When picking encryption methods, we need to make sure we don't use
algorithms which are encumbered by patents. I forget... how does RC4 fare
On Sat, Nov 11, 2000 at 05:03:52PM +0000, J.H. Steele wrote:
> I'm sure we can work it out using well audited GPL code if you want (it'd
> just take a bit more effort). Afterall, both GnuPG and Netscape 6
> (specifically, its NSS security) are both GPLed.
> It seems the GPL TSL (SSL) library is hosted at:
> The following notice is posted at that site:
> "GNUTLS is far from being complete and it was never audited so you
> shouldn't use it in any real world projects, yet"
> NSS is somewhat documented at
> Specific algorithms are listed at:
> It seems this code provides triple DES or RC4-128 encryption. I have no
> idea how difficult this library is to build and/or use. It does have the
> potential for enormous distribution since it'll be bundled with Netscape
> (I assume in dynamic library form).
> As a first strike, I'd be happy with completely unaltered GnuPG
> code. (Which seems very close to what you did in FPM-0.53.) Unfortunately,
> we'd probably need to build wrappers for the GnuPG util functions
> (esp. memory handling). I'll take a closer look at this code.
> I agree that the situation is crazy, but that's the cost of the GPL. I
> suppose I might be selfish, but I'm fairly set on using the GPL (esp
> for crypto and for small projects which can be easily taken).
> If that situation is unacceptable for you, then I would probably consider
> surrendering my copyright to you but not really working in earnest any
> more (not that I've done a whole lot of actual code to date!). Please
> understand, though---no hard feelings here if that's what you want.
> Hope my proposal sounds good.
> On Sat, 11 Nov 2000, John Conneely wrote:
> > This is absolutely ridiculous! OpenSSL now comes standard with Red Hat 7.0;
> > saying GPL programs can't use it doesn't make any sense, and is bad for free
> > software in general.
> > Since we are doing a complete rewrite, we have ultimate flexibility in our
> > license. I'm open to suggestions for a substitute to the GPL. I'd like to
> > use a license with the general intent of the GPL, but I don't want to be
> > told I can't use state of the art free encryption libraries. If that means
> > taking a BSD style license and having our software vulnerable to having
> > derivative non-free works, so be it. But I think it should be possible to have
> > a GPL like license that allows linking with non-GPL free libraries.
> > I read on slashdot that the FSF is working on the GPL, version 3. I wonder
> > if that might lift some of these barriers. We should probably write RMS and
> > let him know that this restriction is causing a free software project to have
> > second thoughts of using the GPL.
> > John, while we sort this out, let's be careful about submissions we accept on
> > FPM v0.60. I want to retain the ability to change the license of FPM until I
> > feel comfortable with it. For now, lets make sure any minor submission or
> > patches to FPM's code base include a transfer of the copyright of those
> > modifications to one of us. That way, as long as we agree on license
> > modifications, we have the power to do it legally. If someone contributes in a
> > more substantial way, we will consider adding them to our circle of trust.
> > Eventually, I hope these things get sorted out and we can commit to a license
> > by allowing even minor contributors to retain copyright on their modifications.
> > As for using OpenSSL: make the choice based on technical reasons, not legal
> > ones. We will figure out what we need to do with the license to make it work.
> FPM-devel mailing list