Smart lawyers spent years on the current licenses, including rounds of open review and comments across multiple jurisdictions in the world.
It is doubtful lone efforts will match that sufficiently to make a bulletproof license, compared to existing ones.
Well I plan to have a lawyer look over the license before I would use it. Many people use customer software licenses which might not have as much review as the popular licenses you talk about but at least have lawyers look at them.
That's nice and all, but now if I'm going to use your software, I need to get
my lawyers to look over the license. On top of that, if I write some software using your library, and distribute it to others, they need to have
their lawyers look over it. With the standard licenses all our lawyers have already done this saving a tonne of effort. These days younger lawyers with a copyright law specialty might have even studied the standard open-source licenses in school. If I were a developer considering whether to use your license or not, I'd take one look at it and reject it purely out of the uncertainty.
Even the standard licenses are often misunderstood:
What about linking to the library which is what I really mean to say. That's a different story isn't it?
LGPL:Proprietary, closed source versions of the library are NOT permitted.
Proprietary, closed source applications
using cbitcoin library are permitted.
GPL:Proprietary, closed source versions of the library are NOT permitted.
Proprietary, closed source applications
using cbitcoin library are NOT permitted.
In either case, LGPL or GPL,
your cbitcoin code remains free software. Nobody is permitted to modify and distribute cbitcoin without also providing source code.
jgarzik got the gist of the LGPL right, and probably already knows about the point I'm about to make, but something a lot of people don't realize is that when you distribute LGPL using proprietary software in addition to distributing any changes to the LGPL library you must also make it possible for your end users to link your binaries to their own changed version of that library. While this is rarely an issue with dynamic libraries, let alone libraries in interpreted languages, it does mean you have to take special steps to distribute a statically linked binary. From the LGPL itself:
d) Do one of the following:
0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding
Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the
Application with a modified version of the Linked Version to produce a modified Combined Work, in the
manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that
(a) uses at run time a copy of the Library already present on the user's computer system, and (b) will
operate properly with a modified version of the Library that is interface-compatible with the Linked Version.
FWIW I just started a new timestamping project, written in Python, and have licensed the client command line utility and core library under the LGPL (>=3). However the server daemon and library functions related to implementing that server are license under the FSF AGPL, (>=3) which requires source-code distribution not only to those you distribute the software too, but also those who you allow to access servers running that software over a network. Basically that means that there is an RPC command called "getsourceurl" and to comply with the license if you modify the source for the server you need to put that source code up somewhere publicly (github would be ideal) and in the config file set the sourcecode url to the new location. I'm also going to include some explanation in the LICENSE file making it clear that trivial changes are just that and don't trigger that requirement. Similarly that config files are not considered a part of the sourcecode.
My thinking is quite like RMS's stance on Bitcoin: I want the timestamping system itself to become widely used, even integrated into proprietary applications. However I'd like to see the timestamping servers remain absolutely open source, and indeed, the system itself is most secure and tamper-proof in an "open source" environment where everyone validates each others timestamps.
Of course, even though the AGPL is an official Free Software Foundation license it's still obscure enough that I may be making the same mistake you are.
If you still really really want to use something different from the standard FSF licenses at least consider dual licensing, or licensing + additional license exemptions. For instance if you licensed your library under the standard GPL-3, but then included an additional statement like:
As an additional permission, above and beyond the standard rights granted by the GPL3.0, you may also distribute a binary containing code from this library, provided that you allow such binary to be freely distributed.
This clause only adds additional permissions to the GPL3 license; if you do not require such permissions, you are free to ignore this clause and follow the terms in the standard GPL3 license.
This kind of thing has precedent already with the GPL linking exemption
http://en.wikipedia.org/wiki/GPL_linking_exception used by some projects. Another example is in the modified GPL used by some ADA programs:
http://en.wikipedia.org/wiki/GNAT_Modified_General_Public_License Finally the GPL font exemption:
http://en.wikipedia.org/wiki/GPL_font_exceptionAt least with GPL+exemptions and GPL+other dual licensing a developer can look at the license file and immediately see that they can treat the project as GPL licensed and be "in the clear" by complying with the GPL. Lawyers don't need to be involved, and everyone already knows exactly what's required to comply.
