Thanks a bunch for your help.

As a stroke of luck, we didn't use any SSL stuff with libcurl.

That's a bummer to hear that we'll need a lawyer to sort it out...im a
big oss fan and figured things would be mostly ok but alas, seems that
i oversimplified the licensing requirements.

Thanks for the information!

On 3/11/08, Brian Dessent <brian_at_dessent.net> wrote:
> Alan Wolfe wrote:
>
> > I want to use libcurl in a commercial product and was wondering if I
> > had to do anything special to be able to do so?
>
> You really need to hire a lawyer and ask him or her that if you want to
> be sure. No one here or on any mailing list is going to be able to give
> you a definitive statement of any kind.
>
> That aside, you can read the license yourself, it's pretty simple:
> <http://curl.haxx.se/docs/copyright.html>. This is the standard MIT/X
> license <http://en.wikipedia.org/wiki/MIT_License> modified with the "no
> using the copyright holder's name in promotion" line. There's really
> not much that you aren't allowed to do with such a license.
>
> > I know about including the license.txt requirement but i was wondering
> > is there anything else?
>
> Don't be confused with the old "BSD 4 clause" license which required you
> to acknowledge the software in advertising materials. There's no such
> requirement with the MIT/X license.
>
> > Also our product is using zlib but since zlib is already a part of
> > libcurl does anyone know if we have to do anything special for that?
>
> zlib is not "a part of curl". curl links with zlib just like a million
> other software packages out there. That doesn't mean the zlib license
> is in any way modified by the fact that curl happens to be one consumer.
>
> > Or would satisfying libcurls needs be enough to satisfy zlib as well
> > since zlib is contained in libcurl?
>
> Again, it's not. A package does not subsume another just because they
> link with each other. The license that is associated with a given piece
> of code does not change based on where you found it.
>
> You must simultaneously satisfy the individual conditions of each
> license for every piece of code that is linked into the final binary.
> And anyway, the zlib license is just as permissive as curl's:
> <http://en.wikipedia.org/wiki/Zlib_license>. Seriously, when it comes
> to licenses it couldn't get any easier than MIT/X and zlib which pose
> almost no requirements, at least compared to e.g. GPL.
>
> The real problem however is not the license of curl (which is as
> permissive as possible), it's the fact that curl typically links with a
> lot of libraries and again you have to simultaneously satisfy them all.
> See <http://curl.haxx.se/legal/licmix.html> for some details.
>
> There is one noteworthy trap that distros have to be wary of: the
> openssl license is incompatible with GPL. This means if you build a SSL
> enabled libcurl (using openssl) then that libcurl cannot be used by
> other GPL apps (unless those apps have specifically exempted openssl.)
> This is particularly annoying for distros because they might not know
> all the possible things that libcurl might be used with, so they
> wouldn't necessarily know if somehow the combination of
> openssl+libcurl+anything_GPL accidently was linked. Anyway, that's
> probably not a concern for you and if it is, you can always use an
> alternative SSL lib.
>
> > I know this may not be the right place to ask about zlib requirement
> > but just hoping someone can help me figure out this legal labyrinth :P
>
> A lawyer under your hire is the only person who can truly help you.
>
> Brian
>
Received on 2008-03-11