Re: GPL Problems

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: der.hans
Date:  
To: plug-discuss
Subject: Re: GPL Problems
Am 30. Sep, 2004 schwätzte Nathan England so:

I'm not Jeremy, but I hope you don't mind me piping up :).

> This brings me to my next question. We want to offer our code as open source,
> but we want to release version 1.0, then when version 2.0 comes out, we'll
> open source (GPL probably) version 1.0...


Check out Aladin, the ghostscript providers. They were doing something
like that. There are a couple of other companies doing something similar.
Even rms doesn't think that's a bad setup.

> How does BSD compare? Would we be safer to be writing, compiling and doing
> everything on BSD? I'm just getting into this license thing and I don't want


Speaking only of licensing you're probably safer in *BSD, but *BSD also
brings in outside stuff, so you've still got to watch the licensing on
what you're using. Same thing w/ proprietary code. Imagine m$ and vxworks
code being freely available, but under typical licensing from those
vendors and then accidentally using their code in your product. Ouch! Your
great-great-grandchilden would be paying licensing fees... ;-)

> to get my company in trouble. Most importantly, we don't want to break any
> laws, assuming the GPL would hold up in court. We respect the GPL, you
> understand. Now, as far as I know right now, everything we have is kosher.
> What libraries we are using are unmodified LGPL libraries, mostly c/c++
> libraries part of the Gnu C libraries.


Good. You're safe with the LGPL. It's probably the best option for your
company. You get the guarantee of Free Software for the base, but you have
more choice on licensing your own code.

> Quick description. A package update component has the ability to connect to
> our servers to download updates for our products. When the source is compiled
> it will look for openssl libraries, if it finds them, it will compile
> additional code to allow the use of encrypted connections between you and our
> servers. If it does not find the openssl libraries, it will continue on
> without it. Now, assuming the openssl is GPL and not LGPL, would we have to
> make our code GPL, or only when compiled using the openssl encryption? If so,
> that's not possible for our company.


Ah, you're naming OpenSSL. Good choice because that one's a bit of a pain.

http://www.fsf.org/licenses/license-list.html#GPLIncompatibleLicenses

Part 3. of the first license could be a problem for your company.
Everywhere you list encryption support you must print their blurb. That
might bother marketing people and anyone else tasked with shoving lots of
advertising data in a small space.

Oh fun, two more advertising clauses in the SSLeay license.

If you don't compile against the OpenSSL code and instead connect to an
application that uses OpenSSL I think you're OK. In other words, I think
you'd be fine to make a socket connection to some SSL tunnel program that
uses OpenSSL.

GNUTLS, which is recommended on the FSF site, is GPL.

> But, on the other hand, we could still GPL our code now. Our customers
> wouldn't know what to do with the sources, and we don't have to give them
> out, only offer them the source and let them know they have so much time to
> ask us for the source after purchasing the product from us. So we don't have
> to give it away, per se. And that would limit our exposure to releasing the
> code. That's an option we are okay with. But the bean counters are still a
> little scared and I can't totally convince them.


And what if your competitor becomes a 'customer' just long enough to
demand the source code? Not trying to scare you. In fact, I still
recommend using GPL and LGPL over the other licenses, but your company
should take an honest look at what that means.

ciao,

der.hans
-- 
#  https://www.LuftHans.com/    http://www.AZOTO.org/
#  "Science is like sex: sometimes something useful comes out, but
#  that is not the reason we are doing it." -- Richard Feynman
---------------------------------------------------
PLUG-discuss mailing list - 
To subscribe, unsubscribe, or to change  you mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss