Open-source licenses
From WhyNotWiki
Open-source licenses edit (Category edit)
Aliases: Licenses
[edit] Permissive / MIT / X Window System / BSD / Academic Licenses
- If your goal is that your code be accessible by the greatest possible number of developers and derivative works, and you do not mind the code being used in proprietary programs, choose the MIT / X Window System license (so named because it is the license under which the Massachusetts Institute of Technology released the original X Window System code). This license's basic message is "You are free to use this code however you want." It is compatible with the GNU GPL, and it is short, simple, and easy to understand. [See http://www.opensource.org/licenses/mit-license.php]
BSD License Problem - GNU Project:
- The two major categories of free software license are copyleft and non-copyleft. Copyleft licenses such as the GNU GPL insist that modified versions of the program must be free software as well. Non-copyleft licenses do not insist on this. We recommend copyleft, because it protects freedom for all users, but non-copylefted software can still be free software, and useful to the free software community.
Eli Bendersky » Choosing an open-source license for my code : MIT vs. BSD
- The MIT license is very similar to the BSD license, the only difference being that it lacks the “endorsement clause”, which in the BSD license (including the "New BSD License") states:
-
- Neither the name of the {ORGANIZATION} nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
producingoss.com: Choosing a License
- The revised BSD license, which is simply the original BSD license with the advertising clause removed. However, this history makes the phrase "BSD license" a bit ambiguous: does it refer to the original, or the revised version? This is why I prefer the MIT/X license, which is essentially equivalent, and which does not suffer from any ambiguity. However, there is perhaps one reason to prefer the revised BSD license to the MIT/X license, which is that the BSD includes this clause:
-
- Neither the name of the <ORGANIZATION> nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
- It's not clear that without such a clause, a recipient of the software would have had the right to use the licensor's name anyway, but the clause removes any possible doubt. For organizations worried about trademark control, therefore, the revised BSD license may be slightly preferable to MIT/X. In general, however, a liberal copyright license does not imply that recipients have any right to use or dilute your trademarks — copyright law and trademark law are two different beasts.
http://www.sitepoint.com/article/open-source-licensing Navigating Open Source Licensing [Legal Issues]:
- Representing the most 'free' of open source licenses, Academic licenses place no requirements whatsoever on the license user -- there's not even a requirement for the user to share modifications or redistribute them. Licenses in this category include the BSD, MIT and Apache licenses.
- Academic licenses are designed to provide absolute freedom. The only marked restriction is that these licenses prohibit the leveraging of the original licensor's name as an endorsement in marketing efforts. Other than that, these licenses are truly intended for those who seek complete control over the software, its use, modifications, and subsequent re-releases independently or with another software package.
- The BSD, granddaddy of open source licensing, originated within the University of California to grant the free use, modification, and distribution of software built within the institution. It has since become a public license available to open source developers.
- The MIT was created by the Massachusetts Institute of Technology as a rewrite of the BSD license. The Apache license differs from the BSD and MIT only in its requirement that a notice be included in either documentation or source code of modified works to identify that the new distribution contains software created by the Apache Software Foundation.
http://dot.kde.org/1068879715/1068941118/1068947876/1069007728/1069010248/ (The BSD license allows companies like Microsoft to benefit)
- Look, the most damaging company for the worldwide computer industry, Microsoft, has benefited enormously from the BSD license: they were able to stabilize their horrible OS in early 2000 by using BSD code, and now they are in an even stronger position to abuse of their power. They even have a decent server product line to offer (this was not the case before).
- Being totally permissive with free software is not necessarily good. The GPL has done for free/open software much more than the BSD license has. Take a look at how popular is the software produced with one license or the other. I, for one, would never release code written in my spare time, to get used by a monopoly like MS.
[edit] Copyleft licences (including GPL)
http://www.gnu.org/philosophy/why-copyleft.html:
- Releasing your code under one of the BSD licenses, or some other permissive non-copyleft license, is not doing wrong; the program is still free software, and still a contribution to our community. But it is weak, and in most cases it is not the best way to promote users' freedom to share and change software.
[edit] Reciprocal Licenses
http://www.sitepoint.com/article/open-source-licensing Navigating Open Source Licensing [Legal Issues]:
- Like other licenses, Reciprocal licenses grant complete rights to the software's use to the developer and end user. The single difference lies in the requirement that any derivatives of the software be released under the same license, and that the source code must be released. The resulting new software must also be free.
- The intent of reciprocity is to ensure that a growing universe of free software emerges, and that original works -- as well as modified and new efforts -- remain free to users. Some of the most popular software available today remains free and accessible due to its use of the GPL including Linux, MySQL, the Bash shell, Mailman, gzip and grep.
- The centerpiece of this category is the GPL, which was last updated in 1991, though it is expected to be refreshed this year by original authors Richard Stallman and Eben Moglen, with input from the open source community at large. The Mozilla Public License also resides in this category.
[edit] GPL
producingoss.com: Choosing a License
- If you prefer that your project's code not be used in proprietary programs, or if you at least don't care whether or not it can be used in proprietary programs, choose the GNU General Public License. The GPL is probably the most widely-used free software license in the world today; this instant recognizability is itself one of the GPL's major advantages.
- When writing a code library that is meant mainly to be used as part of other programs, consider carefully whether the restrictions imposed by the GPL are in line with your project's goals. In some cases—for example, when you're trying to unseat a competing, proprietary library that does the same thing—it may make more strategic sense to license your code in such a way that it can be mixed into proprietary programs, even though you would otherwise not wish this. The Free Software Foundation even fashioned an alternative to the GPL for such circumstances: the GNU Library GPL, later renamed to the GNU Lesser GPL (most people just use the acronym LGPL, in any case). The LGPL has looser restrictions than the GPL, and can be mixed more easily with non-free code. However, it's also a bit complex and takes some time to understand, so if you're not going to use the GPL, I recommend just using the MIT/X-style license.
http://haacked.com/archive/2006/01/24/DevelopersGuideToOpenSourceSoftwareLicensing.aspx Developers Guide To Open Source Software Licensing
- The GPL is designed to guarantee the user’s freedom to share and change the software licensed under its terms. When using GPL code, no additional restrictions may be applied to resulting product. In this way, the GPL is similar to the Borg. If you wish to use GPL code within your own project, then your own project must be licensed in a compatible manner with GPL. Thus GPL code tends to begat more GPL code. It is not permissible under the GPL to use GPL in proprietary software while keeping that software closed source.
[edit] Against
http://lavender.cime.net/%7Ericky/lgpl_is_better.html LGPL is Better
- The GPL is an anti-commerce tool
- Suppose that a company, Alpha, writes and sells computer games. Alpha finds a library, for argument's sake it is libaiksaurus, which is an 'English-language thesaurus that is suitable for integration with word processors, email composers, and other authoring software', and is licenced under the GPL.
- If Alpha links with this library in its game, then the resulting executable must be released under the GPL, which means that source code must be released.
- Releasing source code is incompatible with Alpha's business model. Alpha can choose to either rewrite libaiksaurus, or not release the game. If Alpha chooses the former, work is duplicated, which is senseless. If Alpha chooses the latter, it goes bust, especially if it does this often. Either way it is bad for Alpha.
- It is likely that somebody arguing for the GPL will be itching at this point to mention that obviously Alpha is an archaic company, with an archaic business model, and it will be the first against the wall when the revolution comes. The problem, however, is one of perception. Business sees free software as threatening, because it puts the business of software as a product into trouble.
- The problem is that software is a product in many areas, especially the mass market areas. For instance, Playstation games are as much a product as a bar of chocolate. The GPL was invented in a climate where operating systems for computers were expensive. Now we live in a climate where they are free, at least in price.
- ...
- So, now that operating systems are lower in price, and the advent of Linux, FreeBSD, etc., have provided a free option, there is not the same feeling of desperation. The GPL is out of date, and should not be promoted as the answer to the problem of non-free software.
- Many people feel that they have to choose between free and non-free software for personal use, so they choose the easy option, which is the software installed on their PC. Microsoft has branded the GPL as a viral licence, which is true, as a work which links with a GPL library must also be GPL.
[edit] LGPL
http://www.gnu.org/licenses/why-not-lgpl.html
The GNU Project has two principal licenses to use for libraries. One is the GNU Library GPL; the other is the ordinary GNU GPL. The choice of license makes a big difference: using the Library GPL permits use of the library in proprietary programs; using the ordinary GPL for a library makes it available only for free programs.
Using the ordinary GPL is not advantageous for every library. There are reasons that can make it better to use the Library GPL in certain cases. The most common case is when a free library's features are readily available for proprietary software through other alternative libraries. In that case, the library cannot give free software any particular advantage, so it is better to use the Library GPL for that library.
This is why we used the Library GPL for the GNU C library. After all, there are plenty of other C libraries; using the GPL for ours would have driven proprietary software developers to use another--no problem for them, only for us.
However, when a library provides a significant unique capability, like GNU Readline, that's a horse of a different color. The Readline library implements input editing and history for interactive programs, and that's a facility not generally available elsewhere. Releasing it under the GPL and limiting its use to free programs gives our community a real boost. At least one application program is free software today specifically because that was necessary for using Readline.
[edit] The temptation of popularity / defense of GPL freedoms
http://www.gnu.org/licenses/why-not-lgpl.html
Proprietary software developers, seeking to deny the free competition an important advantage, will try to convince authors not to contribute libraries to the GPL-covered collection. For example, they may appeal to the ego, promising "more users for this library" if we let them use the code in proprietary software products. Popularity is tempting, and it is easy for a library developer to rationalize the idea that boosting the popularity of that one library is what the community needs above all.
But we should not listen to these temptations, because we can achieve much more if we stand together. We free software developers should support one another. By releasing libraries that are limited to free software only, we can help each other's free software packages outdo the proprietary alternatives. The whole free software movement will have more popularity, because free software as a whole will stack up better against the competition.
http://www.gnu.org/philosophy/x.html
Non-copyleft licenses such as the XFree86 and BSD licenses are based on the idea of never saying no to anyone--not even to someone who seeks to use your work as the basis for restricting other people. Non-copyleft licensing does nothing wrong, but it misses the opportunity to actively protect our freedom to change and redistribute software. For that, we need copyleft.
For many years, the X Consortium was the chief opponent of copyleft. It exerted both moral suasion and pressure to discourage free software developers from copylefting their programs. It used moral suasion by suggesting that it is not nice to say no. It used pressure through its rule that copylefted software could not be in the X Distribution.
Why did the X Consortium adopt this policy? It had to do with their definition of success. The X Consortium defined success as popularity--specifically, getting computer companies to use the X Window System. This definition put the computer companies in the driver's seat. Whatever they wanted, the X Consortium had to help them get it.
Computer companies normally distribute proprietary software. They wanted free software developers to donate their work for such use. If they had asked for this directly, people would have laughed. But the X Consortium, fronting for them, could present this request as an unselfish one. ``Join us in donating our work to proprietary software developers, they said, suggesting that this is a noble form of self-sacrifice. ``Join us in achieving popularity, they said, suggesting that it was not even a sacrifice.
But self-sacrifice is not the issue: tossing away the defense that copyleft provides, which protects the freedom of the whole community, is sacrificing more than yourself. Those who granted the X Consortium's request entrusted the community's future to the good will of the X Consortium.
...
Even if the X Consortium and the Open Group had never planned to restrict X, someone else could have done it. Non-copylefted software is vulnerable from all directions; it lets anyone make a non-free version dominant, if he will invest sufficient resources to add significantly important features using proprietary code. Users who choose software based on technical characteristics, rather than on freedom, could easily be lured to the non-free version for short-term convenience.
...
At the same time, it is better if we do not feel too much need for popularity. When a businessman tempts you with ``more popularity, he may try to convince you that his use of your program is crucial to its success. Don't believe it! If your program is good, it will find many users anyway; you don't need to feel desperate for any particular users, and you will be stronger if you do not. You can get an indescribable sense of joy and freedom by responding, ``Take it or leave it--that's no skin off my back. Often the businessman will turn around and accept the program with copyleft, once you call the bluff.
Friends, free software developers, don't repeat a mistake. If we do not copyleft our software, we put its future at the mercy of anyone equipped with more resources than scruples. With copyleft, we can defend freedom, not just for ourselves, but for our whole community.
[edit] Content Licenses
http://www.sitepoint.com/article/open-source-licensing Navigating Open Source Licensing [Legal Issues]
- Content licenses cover elements aside from code, such as art, copy and audio/video. Those familiar with Creative Commons will recognize this license, although a few are listed at OSI, including the Academic Free License.
- One caveat with Creative Commons (CC) licenses is that if a Share-Alike attribute is included in a CC license, it makes the license reciprocal, similar to the GPL.
[edit] Creative Commons
Is the main family of content licenses...
[edit] Creative Commons
I was surprised to see that they also have the GPL listed on their site... neat!
http://creativecommons.org/licenses/GPL/2.0/
It's not listed on their main list, but it's there.
Didn't see the GFDL though...
[edit] IBM License
http://www.opensource.org/licenses/ibmpl.php
http://www.flexwiki.com/default.aspx/FlexWiki/LicenseResearch.html
The IBM license (available here) is also a pretty good candidate. It is good, in my mind, because it effectively blends the things needed to enable non-commercial and commercial work on software:
- It's clear about patents.
- It's got a clear binding of contributors to a sensible set of obligations.
- It clarifies an approach to copyright notices for many people
- It's clear about representations and warranties as well as indemnification
[edit] Lucent Public License
http://plan9.bell-labs.com/plan9/about.html
The fourth edition (the current one) [of Plan 9] is made available under the Lucent Public License version 1.02. Adopted to address shortcomings in the Plan 9 License, the Lucent Public License 1.02 is identical the IBM Public License 1.0 except that it does not require source code to be distributed with derived works; it is non-viral.
[edit] Ruby License
http://www.ruby-lang.org/en/LICENSE.txt
The Ruby License is quite popular for Ruby software (it's used by many projects other than the Ruby language itself, much as the Perl license is used by many Perl projects). But it's not quite as popular as the GPL or permissive (MIT/BSD) licenses.
It looks like a lot of "core"-ish libraries (RubyGems, Facets, ...) use it ... but not all of them (Rake, ...).
I personally think it's needlessly complex and has some Ruby-language-project-/binary-specific wording. (I do like how it dual-licenses with the GPL though :-))
[edit] Open-source licenses / Comparisons
[edit] Choosing a license: Questions/issues
Based on GPL? MPL?
[edit] Reciprocity
Require that licensees distribute source code of derivative works be made available
Even if they weren't planning on distributing them at all?
[edit] License use of derivative works
Require that licensees use the same license for derivative works?
Allow multiple-licensed code? The MPL does.
[edit] Effect of new license versions
MPL part 6 is a little scary. But the MPL does allow the creation of modified versions of the MPL.
[edit] Allow modifications to license?
The MPL allows the creation of modified versions of the MPL.
The GPL strictly prohibits modifications.
[edit] Incorporation in a larger work
GPL does not permit integration with non-GPL licensed work.
MPL doesn't have that restriction.
[edit] Disclaim liabilities
Prevent patent litigation
Disclaim liabilities of warranty, damages, etc.
[edit] Trademark/name rights not granted
To protect the initial developers' reputation.
[edit] Inability to comply due to statute or regulation
See MPL part 4
[edit] GPL questions
"Program": What if your software isn't a program but rather a set of PHP scripts?
Would we really want to use a license that only allows redistribution in works that are GPL compatible? (Could license libraries differently and then distribute them with GPL core?)
[edit] How is it enforcable?
If someone just distributed their binaries, how would one be able to prove that those were created with open-source code?
[edit] Problems with existing licenses
They speak of "the program" and "the executable". Sometimes there is no executable.
[edit] Other interesting articles/links (not related to choosing a license)
BSD License Problem - GNU Project:
- ...
- If you would like to cite one specific example of a non-copyleft license, and you have no particular preference, please pick an example which has no particular problem. For instance, if you talk about "X11-style licenses", you will encourage people to copy the license from X11, which avoids the advertising clause for certain, rather than take a risk by randomly chosing one of the two BSD licenses.
- When you want to refer specifically to one of the BSD licenses, please always state which one: the "original BSD license" or the "revised BSD license".
[edit] Alternative licenses (not commonly used)
- This License is not an Open Source license: among other things, it places restrictions on distribution of the Program, specifically including sale of the Program. While Aladdin Enterprises respects and supports the philosophy of the Open Source Definition, and shares the desire of the GNU project to keep licensed software freely redistributable in both source and object form, we feel that Open Source licenses unfairly prevent developers of useful software from being compensated proportionately when others profit financially from their work. This License attempts to ensure that those who receive, redistribute, and contribute to the licensed Program according to the Open Source and Free Software philosophies have the right to do so, while retaining for the developer(s) of the Program the power to make those who use the Program to enhance the value of commercial products pay for the privilege of doing so.
http://www.sitepoint.com/article/open-source-licensing Navigating Open Source Licensing [Legal Issues]:
- Recently, questions have arisen as to whether some licenses should be consolidated, though some, such as the Academic Free License, serve niches. Eric Raymond, cofounder and president-emeritus of the OSI, suggests that many of the licenses the OSI lists are essentially individual or corporate vanity projects.
- "Only about half a dozen are in any wide use," Raymond told LinuxInsider. "We are mulling ways to push back against further proliferation, but up to now it's been our policy not to reject licenses that fit the OSD even if they are duplicative. That may soon change."
- ...
- For his part, Raymond does not always believe there is good argument to release new licenses, even if the company is big.
- "Most new licenses are exercises in monument-building by corporate legal departments with too much time on their hands," he said. "Occasionally you'll get a license that addresses the underlying legal issues in a genuinely new or interesting way. But that was never common and is now extremely rare."
[edit] Copyright Assignment and Ownership
http://producingoss.com/html-chunk/dual-licensing.html Dual Licensing Schemes
- Most projects have a single legal entity own the copyright on the entire code base. This is done for various reasons. If the terms of the copyright ever need to be defended or enforced in court, it's much easier if a single entity has the right to do so; otherwise, all of the contributors would have to cooperate, and some might not have time or even be reachable when the issue arises. Also, if the code is the target of a copyright infringement suit, you wouldn't want the individual developers to be personally exposed to liability.
- Remember that centralized ownership of the copyright does not make the code any less free. Open source licenses do not give the copyright holder the right to retroactively proprietize all copies of the code. Even if the copyright-holding entity suddenly turned around and started distributing all the code under a restrictive license, it wouldn't cause a problem for the public project. The other developers would simply start a fork based on the latest free copy of the code, and continue as if nothing had happened. Because they know they can do this, most developers do not object when asked to assign copyright to some sponsoring organization.
- Different organizations apply different amounts of rigor to the task of collecting copyright assignments. For most, simply getting an informal statement from a contributor on the public list is enough — something to the effect of "I hereby assign copyright in this code to the project, to be licensed under the same terms as the rest of the code." At least one lawyer I've talked to says that's really enough, presumably because it happens in a context where copyright assignment is normal and expected anyway, and because it represents a bona fide effort on the project's part to ascertain the developer's true intentions.
Who Owns the Copyright for An Open Source Project
- Imagine the logistical and legal nightmare if everyone retained the copyright to code contributed to an open source project, especially if some decided to choose their own compatible license. The source code would be littered with copyright statements and license files for every contributor.
- Instead, it is usually the policy for an open source project to assign copyright to a single legal entity or person. Keep in mind that although this person then owns the copyright, the code has been released under a license that allows free distribution. Thus the fact that the copyright has been assigned to an individual entity does not make the code any less open.
http://haacked.com/archive/2006/01/26/WhoOwnstheCopyrightforAnOpenSourceProject.aspx : Joe Brinkman:
- One thing that we learned on the DotNetNuke project, is that having a single copyright holder goes beyond just its effect on the code developers. When working with Web Hosting companies they expressed concerns with having multiple copyright holders for the project as it could lead to problems if some of the copyright holders choose to change their licensing terms. Ultimately there would not have been a single entity involved in the licensing of the product which could have potentially created problems for the users.
- When using licensed components, it is easier for a project to insulate itself from the negative impacts of changing licenses, however, when code is threaded throughout a project, it is not so easy to rip-and-replace if the copyright holder changes to an incompatible license.
- BTW, we follow the FSF model and require contributors to sign a legal document assigning copyrights to PMI.
http://haacked.com/archive/2006/01/26/WhoOwnstheCopyrightforAnOpenSourceProject.aspx : Christopher Baus:
- There a different schools of thought on this. http://boost.org/ keeps copyrights assigned to the original author, but the author must agree to the boost license or the code can not distributed with boost.
- This did become a problem when one of the contributors to boost.threads disappeared and could no longer be contacted, and the license couldn't be updated.
- by Haacked:
-
- Chris, that's one of the main arguments for copyright assignment. If the project wanted to change its license OR if the project was sued, it may not be possible to contact and organize all copyright holders at that time.
[edit] Mixing code with different licenses into one project/compilation
This appears to be something that Facets did, to some degree...
Ruby Facets, Copyright (c) 2005 Thomas Sawyer
Ruby Facets is provided under the Ruby License.
Credit and Copyrights for particular borrowed code segments are given in their respective source. All licenses are either compatible with the Ruby license (Ruby or GPL) or the original author has given permission for inclusion of their code under this license.
So although the software included in the Facets compilation may have originally been under a different license (and still may be), he has ensured that at least one of the following was true:
- that original license is compatible with the Ruby license (the license Facets uses)
- or: permission was granted from its author to also release it under the Ruby license (in addition to whatever that original license was)
[edit] Other issues, like patents
NewsForge | Choosing an open source license
- You have to consider what patents you are licensing, if any, and whether those licenses flow through to any derivative works. Do you want to protect your downstream developers from patent infringement? Warrantees and liability, or disclaiming such, should be on the radar as well. You should be considering issues like jurisdiction -- where you want any claims to go to court -- and governing law: contracts or copyright, or both? And if someone sues you or you sue a licensee, who pays for the lawyers? The license has to cover all those issues as well.
[edit] Patent rights
http://www.sitepoint.com/article/open-source-licensing Navigating Open Source Licensing [Legal Issues]
- In understanding the licensing process, it's important to distinguish between copyright, trademark and patents. All of these elements play a role in the software we use every day. In some cases, the freedom from patent risk has been included in the license (as in Sun Microsystems' CDDL and, to some extent, others).
- However, as Rosen makes clear in his book, many of the licenses protect users from patent requirements of the original software, but cannot necessarily extend that protection once you modify and redistribute the source code or binary.
- ...
- Due Diligence
-
- Reviews are carried out regularly, primarily for the purpose of showing due diligence.
-
- Raymond thinks the only strategy that makes sense in the crazed and toxic environment created by modern IP law (especially patents) is to complete just enough of a pro forma review to have on the record that a review was carried out, then basically ignore your risks until and unless you are sued.
-
- "And this is exactly the advice patent lawyers will give you. You don't 'want' to know what patents you may be infringing in advance -- that makes it 'willful' and trebles the damages," he said.
-
- "Yes, this is crazy," he admitted. "It reflects the fundamental insanity of modern IP law."
-
- In recognition of today's evolving IP issues, the GNU General Public License -- one of the most widespread variations -- will be refreshed for the first time in thirteen years. The revision is expected in 2005.
[edit] Switching to a different license later
http://www.sitepoint.com/article/open-source-licensing Navigating Open Source Licensing [Legal Issues]
- It's important to understand the impact of choosing your license. As you have seen, each license category has its own particular purpose, whether it's to ensure end-user freedom, prevent commercial use, or preserve a standard code base.
- Users can switch licensing schemes after they've made their selection and distributed software; however, the issue of existing code and license agreements is murky when it comes to making such a change. These unproven waters mean that developers need very carefully to select a license they can live with for the long term.
- For example, if a developer foresees only selling support and customization services over the long term, choosing a reciprocal license that may prevent the sale of the software itself would be sufficient. However, if there's a chance that a future application may become partially proprietary while including original or modified open source, an Academic license may be a better route.
http://fscked.org/writings/OpenSource.html
- Also remember that as long you are the only copyright holder to the code, you may change the licensing scheme at any time, but once other people begin to contribute modifications under a certain license, you are stuck with that license until you obtain every contributor's permission to change it, or you remove their contributions.
[edit] Derivative works obligated to use same (or compatible?) license
This is probably apparent to most people already. But I think it's still deserving of its own topic and its own discussion.
Because [this] does make certain demands of those who make derivative works, some developers may see this as a loss of their freedom and flexibility and choice. They may want to avoid deriving from an existing work and just build their own work from scratch, to avoid having these inheriting these restrictions and to ensure they have the most control over their work as possible. (But in the end, how much control does one really need? Isn't that supposed to be one of the beautiful things about free software, is that it limits the control that developers/copyright owners have in order to maximize the amount of freedom the end-user has?)
Is SharpMap free with no strings attached?
No (but almost) - There are some caveats:
Even though SharpMap is released under GNU Lesser General Public License, it doesn't make it completely free to use without any strings attached. SharpMap is free in the sense that anyone can download and use it for their applications, but the GNU LGPL license restricts its use. If you modify, add or create a new project based on SharpMap, that too will be bounded by GNU LGPL.
The LGPL does not require you to release your modified version. You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization.
But if you release the modified version to the public in some way, the LGPL requires you to make the modified source code available to the program's users, under the LGPL.
In other words: The GNU LGPL will require that all the released improved versions be free software.
[edit] Are there such thing as "compatible" licenses that derivative works could use?
As long as they grant all the freedoms of / follow all the terms as the original license, it seems like it should be theoretically possible... I haven't checked on the specifics though yet.
[edit] Popularity
Numbers/statistics as well as examples of notable users from each category/license...
RubyForge Project Tree by License
- GPL [~500]
- Permissive / MIT / X / BSD [493]
- MIT/X [360]
- BSD [163]
- Ruby License/GPL (dual license) [374]
- LGPL [123]
[edit] My preferred license
My personal preference (as a free software fanatic) is to release
- "small" stuff ("not big enough to worry about") (or anything I want to have as widespread usage/possibility as possible) under the super-simple, permissive MIT license (= BSD)
- anything significant under GPL (copyleft/reciprocal)
[edit] Other
Public Software Licenses Evaluated [finish reading]
Slashdot | Interview: Bruce Perens Answers Open Source License Questions [finish reading]
