Why bsd license

This final consideration may often be the dominant one, as it was when the Apache project decided upon its license:. Developers tend to find the BSD license attractive as it keeps legal issues out of the way and lets them do whatever they want with the code.

In contrast, those who expect primarily to use a system rather than program it, or expect others to evolve the code, or who do not expect to make a living from their work associated with the system such as government employees , find the GPL attractive, because it forces code developed by others to be given to them and keeps their employer from retaining copyright and thus potentially "burying" or orphaning the software.

If you want to force your competitors to help you, the GPL is attractive. A BSD license is not simply a gift. The question "why should we help our competitors or let them steal our work? Under a BSD license, if one company came to dominate a product niche that others considered strategic, the other companies can, with minimal effort, form a mini-consortium aimed at reestablishing parity by contributing to a competitive BSD variant that increases market competition and fairness.

This permits each company to believe that it will be able to profit from some advantage it can provide, while also contributing to economic flexibility and efficiency.

The more rapidly and easily the cooperating members can do this, the more successful they will be. A BSD license is essentially a minimally complicated license that enables such behavior. A key effect of the GPL, making a complete and competitive Open Source system widely available at cost of media, is a reasonable goal.

A BSD style license, in conjunction with ad-hoc-consortiums of individuals, can achieve this goal without destroying the economic assumptions built around the deployment-end of the technology transfer pipeline. The BSD license is preferable for transferring research results in a way that will widely be deployed and most benefit an economy.

They should also encourage formation of standards based around implemented Open Source systems and ongoing Open Source projects. Government policy should minimize the costs and difficulties in moving from research to deployment. When possible, grants should require results to be available under a commercialization friendly BSD style license.

In many cases, the long-term results of a BSD style license more accurately reflect the goals proclaimed in the research charter of universities than what occurs when results are copyrighted or patented and subject to proprietary university licensing. Anecdotal evidence exists that universities are financially better rewarded in the long run by releasing research results and then appealing to donations from commercially successful alumni.

Companies have long recognized that the creation of de facto standards is a key marketing technique. The BSD license serves this role well, if a company really has a unique advantage in evolving the system.

There are times when the GPL may be the appropriate vehicle for an attempt to create such a standard, especially when attempting to undermine or co-opt others.

The GPL, however, penalizes the evolution of that standard, because it promotes a suite rather than a commercially applicable standard. Use of such a suite constantly raises commercialization and legal issues. It may not be possible to mix standards when some are under the GPL and others are not. A true technical standard should not mandate exclusion of other standards for non-technical reasons.

Companies interested in promoting an evolving standard, which can become the core of other companies' commercial products, should be wary of the GPL. Regardless of the license used, the resulting software will usually devolve to whoever actually makes the majority of the engineering changes and most understands the state of the system. The GPL simply adds more legal friction to the result.

Large companies, in which Open Source code is developed, should be aware that programmers appreciate Open Source because it leaves the software available to the employee when they change employers. Some companies encourage this behavior as an employment perk, especially when the software involved is not directly strategic.

It is, in effect, a front-loaded retirement benefit with potential lost opportunity costs but no direct costs. Do you have any more? I would be happy to find the answers for you. The author of this blog is not a lawyer, and you should not interpret this BSD-license information as legal advice of any kind. Information is provided on an as-is basis. For a legal consultation, please contact your legal advisor. Rami Sass. Contents hide. What are the terms and conditions of the License?

Is it considered copyleft? Is it compatible with GPL? Does it grant patent rights? Can I combine BSD-licensed components with proprietary code or code licensed under other open source licenses? The complete guide to Open Source Licenses These are the 4-clause, 2-clause, 1-clause, and 0-clause license variants. As the names imply, the key differences between them have to do with the number of clauses in the license.

An important note: Open source licenses generally have deprecated advertising clauses. So, if you find code under a license with an advertising clause, you may want to consider whether it is up-to-date and secure. This is the clause that prohibits users from using the name of the project to promote their derivative work s. Finally, the 0-Clause BSD License does not require users to include the license text or copyright notice in their copy or modification of the code. In other words, it has no requirements whatsoever, making it a public-domain-equivalent license.

The popularity of permissive licenses has been growing steadily over the past few years, particularly that of the MIT License and the Apache License 2. In addition, the language of the MIT License is simpler and shorter. The Apache License 2.

This aspect of the license provides legal protection and peace of mind to companies that make use of Apache-licensed code. In contrast, the BSD license is thought to grant some patent rights by implication, and the scope of that license is, at best, unclear. As long as the developers include the original copyright and attributions in the software, they can redistribute variants commercially without also shipping the source code.

To use the BSD license, users need to include it in the compiled version of the code and all associated documentation and other materials.

Choose the BSD License template, click on review and submit, and finally commit the file. Any user or team can use the BSD license by copying the original text and updating the information to reflect the owners, organizations, and copyright year. There are no additional licensing fees required. BSD licenses are popular and used on many projects, ranking as the sixth most popular license on Github in Another variant is the Zero Clause BSD , which only has the copyright notices and disclaimer, without requiring the acknowledgment or redistribution of the copyright notice.