The first and consideration is whether or not the license is approved as an open source license by the Open Source Initiative (OSI). OSI created the Open Source Definition in the late 1990s as a set of attributes that a software license must support to be considered “open source.” Anyone can take a license to the OSI for discussion and if approved as meeting the OSD, then the license is added to the list.
This seems an obvious place to start,it was surprising to see a license called the “Clear BSD License.” It attempts to clarify that patents are not being discussed in the license. It is not on the OSI list (while the New BSD and Simplified BSD licenses are) and is not worth considering. Inventing new licenses as small derivatives of existing licenses is not helpful fand creates costlybusy work. There exists a collection of OSI-approved licenses today. These cover millions of lines of software involved in billions of dollars in procurement. One would be hard pressed to describe a set of circumstances that isn’t already covered by an OSI-approved license.
There are several levers available when considering an open source license:
How much license reciprocity is required with respect to the software, and any derivatives someone develops?
What is said about patent licensing?
What legal jurisdiction covers the license?
The reciprocity issue is all about “copyleft” and whether or not using the software source code attaches the license to the modifications and whether the source code to those modification needs to be published.
One end of the spectrum are licenses that have no copyleft requirements. These licenses allow anyone to use the software in anyway without requiring more than maintaining copyrights. Licenses that fall under this set include the New and Simplified BSD licenses, the MIT license, and the Apache 2.0.
There are a set of licenses that maintain a sense of copyleft around the software, but support the use of the software in works of software which contain software that is licensed differently (e.g. closed and proprietary). These licenses are the Eclipse Public License, the newer Mozilla Public License 2.0.
On the other end of the copyleft spectrum are copyleft licenses. Software freedom is understood by the Free Software Foundation in relation to the freedoms a user of software must have. Strong copyleft supports freedom.
Conclusion – Many developers support software freedom, and demonstrate this support using one of the family of GPL licenses (GPL2.0, GPL3.0, and the Affero GPL3.0) to ensure the strongest copy left and strongest attachment when the software in question is used in distributing other software.