Hacker Newsnew | comments | ask | jobs | submitlogin
tanoku 1095 days ago | link | parent

Why you shouldn't use talloc for your next C project:

GPL v3.



JoshTriplett 1095 days ago | link

Talloc uses the LGPL, not the GPL.

-----

haberman 1095 days ago | link

Even LGPL is a pretty steep price for the value being offered. The LGPL requires that is it possible to substitute a modified version of the library, which can be a logistical problem. Do you really want to have to link your malloc() as a shared library? How do you let the user substitute inline functions? What do you do when people start bugging you because they weren't able to substitute a modified version of the library due to some technical edge case?

Too much legal baggage for such a small piece of functionality.

-----

JoshTriplett 1095 days ago | link

I wouldn't call talloc a small piece of functionality. Also, the LGPL explicitly states that dynamic linking suffices, and also explicitly covers the inclusion of bits from header files. I do agree that the LGPL makes it non-trivial to statically link a proprietary application with the library; personally, I think it would help if the FSF had standard exception language libraries could use if they don't care about relinking and only care about requiring source for modified versions of the library. That said, I don't write proprietary software, so that doesn't affect me. :)

-----

haberman 1095 days ago | link

> Also, the LGPL explicitly states that dynamic linking suffices

Good point, I thought that the requirement was substitutability and dynamic linking was just given as an example of how a library can be substitutable, but it appears that dynamic linking is sufficient.

> and also explicitly covers the inclusion of bits from header files.

It's not clear to me exactly the meaning of these sections; if including bits from header files is truly allowed, then you could effectively circumvent the substitutability goal by simply inlining the whole library.

> That said, I don't write proprietary software, so that doesn't affect me. :)

I don't either, but I write a BSD-licensed library that I absolutely want to be usable with proprietary software without any difficulty.

-----

JoshTriplett 1095 days ago | link

> Good point, I thought that the requirement was substitutability and dynamic linking was just given as an example of how a library can be substitutable, but it appears that dynamic linking is sufficient.

You can satisfy the requirement without dynamically linking (by shipping object files or source code instead), making dynamic linking sufficient but not necessary. In practice, though, nobody seems to attempt anything other than dynamic linking against an LGPL library, or shipping enough source code for static linking (even if not all the source code).

> It's not clear to me exactly the meaning of these sections; if including bits from header files is truly allowed, then you could effectively circumvent the substitutability goal by simply inlining the whole library.

Substitutability represents a technical goal, and the library has to support that goal for it to prove useful. If the library provides the entirety of its functionality via inlines in header files, they clearly don't care about substitutability. And if you modify the library to move all of it into header files, you still have to supply the source for the modified version of the library, so you've broken substitutability but you haven't broken the copyleft. As far as I can tell, the LGPL's goal of substitutability seems primarily aimed at cases where you don't intend to substantially modify the library; after all, you can also change the library's API/ABI and thus make the original no longer substitutable. (Personally, I don't really see the point of the substitutability provisions anymore; I really just want a copyleft on the library itself.)

> I don't either, but I write a BSD-licensed library that I absolutely want to be usable with proprietary software without any difficulty.

Fair enough. However, in that case the copyleft on the LGPL software seems equally onerous, since users of your library would need to ship the source of talloc, even though they don't need to ship the source of your library. (One other interesting provision: the users of your library couldn't use a license that prohibits reverse-engineering.)

In any case, yes, talloc's license effectively makes it unusable by libraries that want to provide an all-permissive license. If you really want to use talloc, you might consider writing to the authors of talloc; they might prove sympathetic to the needs of a BSD-licensed library, and grant a suitable exception. (Personally, I'd like to see some standard wording for an exception similar to the one used in UPX, namely that you can use it under an all-permissive license as long as you use an unmodified version.)

-----

jojo1 1095 days ago | link

-1

-----

jojo1 1095 days ago | link

Yeah, down-vote me. I like it...

http://ccan.ozlabs.org/info/talloc.html talloc is LGPL v2

-----

Locke1689 1095 days ago | link

Why didn't you just put that link in your first comment?

-----

daxelrod 1095 days ago | link

This is actually a bit confusing. My guess is that talloc changed its license at some point.

The ccan version http://ccan.ozlabs.org/info/talloc.html says it is based upon svn://svnanon.samba.org/samba/branches/SAMBA_4_0/source/lib/talloc revision 23158 , and is LGPLv2.

I believe http://talloc.samba.org/talloc/doc/html/talloc_8h_source.htm... is the latest version, 2.0.5 from 10-Jan-2011. That version does appear to be LGPLv3.

(Note that both appear to have the "or (at your option) any later version" clause, but that's largely irrelevant in this case.)

-----




Lists | RSS | Bookmarklet | Guidelines | FAQ | DMCA | News News | Feature Requests | Bugs | Y Combinator | Apply | Library

Search: