I'll come back to this issue at a later date. Once again I said I'm thinking through cbitcoin over the next few weeks. This is one thing I will look at and consider what license is best. So you just have to stay tuned. I do think the GPL has got problems, so yes I will figure this out. The LGPL might not be perfect either, so we will see.

Was there this discussion with the AGPL with Armory? I'm not using the AGPL before anyone is scared.

Where is the hate, in my message?  I am simply stating facts.  Linux kernel developers have been deeply involved in the arcane legal issues of licenses and linking for well over a decade.

And even excluding my kernel work, you will see that many of my projects are GPL license: https://github.com/jgarzik    (basically all the non-python projects are GPL'd)

The Linux kernel example is simply not applicable to the cbitcoin licensing situation, because it is not a library against which people directly link their end user applications.

The facts are:

1) If cbitcoin is LGPL, an application using cbitcoin may be any license.
2) If cbitcoin is GPL, an application using cbitcoin must be GPL.
3) Linux kernel is not a library against which user applications directly link.  The kernel is GPL, but applications using the kernel's system call interface may be any license.

Just so you know, I've just sent an email to RMS about this.  As I said, I think it's an important enough issue to bother him.

The linux kernel is not a library.  I can create closed source software that runs on the linux kernel.

However, a vast number of the libraries that make up linux are LGPL, so that just proves my point.

Just because something is closed source doesn't mean it isn't free.

On a practical level, it is doubtful that the user community would trust a closed source implementation with their money, when so many open source implementations exist.

Is it?  Oh shit it is.  I really thought it was GPL.   My bad.   I guess you guys win.

If you are talking about wallet ripoffs, then you are probably right.  But what about POS systems, ATM firmware, ERP applications, all which could use some bitcoin integration but are unable to open source for one reason or another.  Maybe the codebase uses other third-party closed source code... maybe there are corporate license restrictions to conform to a specific industry law... maybe there are security implications for open sourcing the code.

The point is that there are so many untold reasons why someone may want to use the cbitcoin library in their code to further bitcoin adoption.  Pigeonholing it with GPL unnecessarily limits it, especially considering that the LGPL was designed specifically with libraries in mind to fix this issue.

I think the main question is what is the end goal.  To expand the uptake of bitcoin?  Or make sure that developers of open source software have a competitive advantage over the corporations?  If we were further along with bitcoin, I think you could make an argument for a GPL library. Unfortunately, unless those with closed source interests have an easy and cheap way into bitcoin, they aren't going to spend their money.  Bitcoin isn't big enough.

If LGPL is going to be a no go... let me make a suggestion.  How about a dual license.  GPL and a closed source license where the closed source licensee pays some fee to use the library how they see fit.

What exactly is it that you want to "protect" against?

Check out this article:
The GPL Family of Licenses Sees a Decline in Adoption