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.
I've been racking my brain trying to come up with a basic, concise readme to include with my code as well as a cabin design I've been working on. At first glance, these are wildly differing things, so one license type E.G. creative commons had too many options.
Finally, I came up with one single readme file I can include in almost all my work (except where I have to combine other stuff under different licenses). It's basically a variant of the ISC license.
Feel free to use this for whatever...
Introduction...
Things your whatchamacallit does
___________________________________________________________________________
README
Important stuff about the project.
Requirements, preconditions, defaults etc...
___________________________________________________________________________
CONTACT
Twitter : @eksith
Website : http://eksith.com
Email : Eksith Rodrigo <reksith at gmail dot com>
___________________________________________________________________________
COPYING / LICENSE
The contents of this package are licensed under the following unless
otherwise noted.
Copyright (c) $YEAR, Eksith Rodrigo
Sources, libraries, binaries, diagrams and/or images and documentation
included with this package are hereby referred to as "materials".
Permission to use, copy, modify, and/or distribute these materials for
any purpose with or without fee is hereby granted, provided that the
above copyright notice and this permission notice be included in all copies
in an applicable and appropriate format.
THESE MATERIALS ARE PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL
WARRANTIES WITH REGARD TO THESE MATERIALS INCLUDING ALL IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR
IN CONNECTION WITH THE USE OR PERFORMANCE OF THESE MATERIALS.
END.
I would add, please use a known and widely-used license (IMO, preferably a 2-clause BSDL variant or LGPLv2, depending on your attitude towards derived works). Don't make up your own or just state that it's public domain. Public domain is actually not a well-defined concept internationally, and means different things in different countries.
http://creativecommons.org/choose/zero/ is a good alternative/method to releasing into the public domain, and is (to my knowledge, IANAL) unambiguous internationally.
Its becoming less of an issue as more and more as software migrates to being "as a service". A webapp is not distributed, so the license doesn't matter at all.
I will make a small off-topic question. I really like the ISC license but for a small snippet of code I think that it's still to big. I choped some parts and got it to this:
Copyright (c) 4-digit year, Company or Person's Name
Permission to use, copy, modify, and/or distribute this software for any purpose is hereby granted.
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE.
Would this be a valid open source license?
I am not using this license for anything big. Most of my code is pretty much useless and for the code I consider more useful I use the ISC license.
It is generally a bad idea to make your own, since you won't be aware of international issues. Similarly since your license is non-standard, anyone using the code now has to a do legal review to make sure things are ok, instead of looking in their list of standard approved ones.
I think it's interesting that in this time of fancy collaborative tools like github, the trend no longer seems to be collaboration but to reinvent everything as a "one man show". And it becomes apparent with new technologies like Go and redis where there are like 10 different implementations of the same database libraries at any given time, but they are all gone within a month...
Yes, because things are easier than ever for people that want to contribute but also for those who want to create new projects. Maybe GitHub could suggest existing projects to contribute on before creating a new repository :)
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/...