I would like to add that when open sourcing a library, meaning software designed to be included within or used by other applications, please don't license it under the GPL. Of course you can license it under whatever you want, it's your code, but you need to understand the consequences. If the library is GPL it can only be used by other GPL applications (if the application is distributed), which excludes major open source projects like Rails (MIT) and Django (BSD). It seriously limits amount of people that can use your library, and hopefully you are open sourcing a library because you want to help as many people as possible.
Even the LGPL doesn't make sense for interpreted languages or compiled languages that don't link like C. The wording of the LGPL is pretty ambiguous when it comes to languages that 'include' libraries into their code instead of linking against complied libraries. FSF argues it's not ambiguous [1], but that fact that they even have to make that argument proves it is. As the original author of Twisted Python wrote "It would be a halfway accurate statement that I selected the LGPL exactly because it doesn't make any sense." [2] Twisted is now MIT licensed
> It seriously limits amount of people that can use your library, and hopefully you are open sourcing a library because you want to help as many people as possible.
This statement ignores the myriad alternative reasons, both personal and altruistic, why someone may wish to provide something as open source; in particular, it entirely dismisses as apparently-not-even-worthy-of-thought the actual arguments made those who use GPL-based licenses that concentrating on helping first-order consumers at the expense of those people further down the chain (the potential users of derivative software built by developers who are building on your work; especially and even specifically when your original software offered fairly unique and enabling functionality, as is described by the FSF as the situation where the GPL may be warranted for library use) seems like a strange and self-defeating bet to make about what the influence of your code will be, even when the goal is solely to "help as many people as possible".
You've contributed some really useful information about the GPL and the LGPL, but the whole "please don't license it under the GPL" angle did nothing but initially reduce my receptiveness to that information as a reader.
The GPL is a perfectly good license, and a lot of very good things only exist because of it. That you would implore people not to use it at all seems an unwarranted use of hyperbole, and one that does not contribute anything to your actual point, which is that people should understand the full extent of the restrictions imposed by their choice of license.
For me, all this accomplished was to put my mind on the defensive as I read the rest of your comment. I had to go back and read it a second time in order to give my mind a chance to digest the real message.
Your link [1] is FSF correcting a false representation of what they said:
"In July of 2003, Slashdot published a story claiming that I had claimed that the LGPL did not function as intended in the case of Java. This story was based on a misunderstanding of a response to a question sent to licensing@gnu.org, and many attempts to clarify the issue in the Slashdot story did not get across. I have received numerous questions about the story since, via both licensing@gnu.org and personal email."
It would not be complete without an explanation of why their posisition is correct, even if it is obvious to anyone who read the license.
As such, their opinion on the interpretation of the license has no particular standing. It's helpful that they're the author of the license, and if it came down to it in court, it may be persuasive. But another lawyer might have a different opinion, so the question of how it will actually be interpreted if two parties disagree remains open and unsettled. Therefore, anyone undertaking to release a bit of open code should consider the range of interpretations when choosing the license.
That's all that antoncohen was getting at, I think.
> The FSF is not a court of law. As such, their opinion on the interpretation of the license has no particular standing. It's helpful that they're the author of the license, and if it came down to it in court, it may be persuasive. But another lawyer might have a different opinion...
A key word there: "another lawyer".
So sure, if there was another lawyer here who in their professional opinion will state a contradiction, then that is indeed something worth to consider. An non-lawyer however, has about the same qualification in defining ambiguousness in legal documents as a non-engineer has in defining faults in a nuclear reactor.
> It seriously limits amount of people that can use your library
Yes, it does seriously limit the amount of people that can use your library--without giving anything back.
> hopefully you are open sourcing a library because you want to help as many people as possible.
Help as many people as possible do what? Get rich by composing together a bunch of liberally licensed software to do a task and then close sourcing it. No, thank you.
I see licensing as a Hawk-Dove-Retaliator game[1] for modeling resource competition. Each kind behaves differently: The Dove never fights and always flees. The Hawk always attacks and never flees. The Retaliator only attacks if attacked. Pay off matrices describe in detail how well each kind does against the other. Dove vs. Dove both do well; they share. Hawk vs. Dove, the Hawk wins everything. Hawk vs. Hawk, the beat each other up; both lose. Retaliator vs. Dove, just like Dove vs. Dove. Retaliator vs. Hawk, like Hawk vs. Hawk.
My analogy is this: The BSD licensor is a Dove, the proprietary licensor is a Hawk, and the GPL licensor is a Retaliator. If you want to be nice but make yourself vulnerable to exploitation, be a Dove; Doves like Doves, and Hawks love Doves--it's popular. If you want to get rich, then exploit all the Doves and be a Hawk; Doves worked hard, so you don't have to. If you want to have your work respected rather than exploited, be a Retaliator: happy to cooperate with those who cooperate, but willing to punish those who defect and refuse to cooperate. Which of these strategies is stable in the long-term? See the links below for a more detailed answer, but Doves certainly aren't.
Doves may enjoy a wonderful period of peace and cooperation, but they're so easily exploited that it makes one wonder how long it will last. In a population of Doves, it's best to be a Hawk. However, a population of pure Hawks does terribly. A population of Retaliators though is nearly immune from invasion.
Note: There are many salient differences between licensing and this animal behavior model. I don't contend that it is a perfect analogy, but I think it is worthwhile for considering long term trends.
I guess its your personal opinion to not use GPL for libraries. It's clearly not something everyone would agree with, especially not FSF with their article https://www.gnu.org/philosophy/why-not-lgpl.html explaining why.
As for your whole reasoning around LGPL for interpreted languages, I must say its mostly false. If there were a court case that said that LGPL is ambiguous, then you would have some facts behind the statement, but as it stands, it just you who think that LGPL is ambiguous as an legal document. Are you a lawyer? Do you work in any legal capacity somewhere? Do you have any actually credentials for backup the statement that LGPL would be ambiguous to use?
Last, as a side note, I would like to add that Blizzard used LGPL when they made Starcraft 2. Blizzard, a very much proprietary company which has a rather large legal department felt apparently perfectly fine in using LGPL in their flagship product.
I would like to add that I think your article on what should be in your README is awesome! I will be making use of it for a new project of mine. I just respectfully disagree on the licensing considerations.
Even the LGPL doesn't make sense for interpreted languages or compiled languages that don't link like C. The wording of the LGPL is pretty ambiguous when it comes to languages that 'include' libraries into their code instead of linking against complied libraries. FSF argues it's not ambiguous [1], but that fact that they even have to make that argument proves it is. As the original author of Twisted Python wrote "It would be a halfway accurate statement that I selected the LGPL exactly because it doesn't make any sense." [2] Twisted is now MIT licensed
[1] https://www.gnu.org/licenses/lgpl-java.html
[2] https://twistedmatrix.com/pipermail/twisted-python/2004-May/...