It was drafted by Heather Meeker, a specialist in open-source software licensing and strategy, and meant to complement other licenses. Applying the Commons Clause to an open-source project means the source code is available and enables users to modify and distribute it, but it does not comply with the Open Source Initiative’s (OSI) 10 guidelines for open source. 

RELATED CONTENT:
The battle of open-source licenses
Open source is a community, not a brand

Since its announcement, Redis Labs has decided to move on from the Commons Clause and created its own Redis Source Available License (RSAL) for Redis Modules, which are modules running on top of open-source Redis. Under RSAL, software can be modified, integrated into an application, used and distributed. It restricts the software from being used as a database, caching engine, stream processing engine, search engine, indexing engine or ML/DL/AI servicing engine. 

Confluent switched some components of its platform to the Confluent Community License in 2018, which allows developers to access the software code, modify it and redistribute it, but does not allow developers to use it in a competing SaaS offering. “‘Excluded Purpose’ is making available any software-as-a-service, platform-as-a-service, infrastructure-as-a-service or other similar online service that competes with Confluent products or services that provide the Software,” the license states. 

Elastic just recently announced this year Elasticsearch and Kibana would be switching to dual licenses under MongoDB’s Server Side Public License (SSPL) and the Elastic License v2. The Elastic License is a non-copyleft license that has three limitations: developers cannot provide the software as a managed service; circumvent the license key functionality or remove/obscure features protected by license keys; or remove or obscure any licensing, copyright or other notices, the company explained. 

MongoDB’s SSPL is based on the GNU General Public License, and while the company believes it contains all the tenets of what it means to be open source, it has not been approved by the Open Source Initiative because the license contains conditions for providing the software as a service. “If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Software or modified version,” section 13 of the license states. 

According to Dev Ittycheria, CEO and president of MongoDB, since the company created and switched over to the SSPL more than two years ago, it has not had a negative impact on user adoption or impacted the success of the company.

MariaDB switched to the Business Source License as an alternative to closed source and the open core licensing models. It does not meet the criteria of the OSI because it allows the licensor to make an additional use grant that limits production use.

“If you write a new license, you also should be clear about whether you intend it to be open source or not,” Meeker told SD Times. “Fundamentally, open source licenses have no scope limitations. They cannot be limited by field of use, or time, or number of users  —  all of the typical limitations you see in proprietary licenses. Most of the new licenses that have been written recently —  like the Elastic License 2.0, the Confluence Community License, or the Business Source License — are not open source licenses. Most of the new licenses are source code licenses, and I would put them in the category of source available, though this category is still in its early stages. SSPL was more controversial, as there was some disagreement over whether it was an open source license.” 

“The future of open source is strong and still growing.  Some of the new licenses are used as alternatives to open source, but more often, complements to it,” she added.

The post Understanding the new “open” licenses appeared first on SD Times.

Elastic founder and CEO Shay Banon explained while this change will most likely have little to zero effort on its user community, cloud customers or self-managed software customers, he felt the change was necessary. 

RELATED CONTENT: 
New software licenses aim to protect against cloud providers
Making open source work for you and your business

“So why the change? AWS and Amazon Elasticsearch Service. They have been doing things that we think are just NOT OK since 2015 and it has only gotten worse. If we don’t stand up to them now, as a successful company and leader in the market, who will?” Banon wrote in a post. “Our license change is aimed at preventing companies from taking our Elasticsearch and Kibana products and providing them directly as a service without collaborating with us. Our license change comes after years of what we believe to be Amazon/AWS misleading and confusing the community – enough is enough.”

Elastic joins a number of other companies who have had similar sentiments towards Amazon as of lately. The SSPL that Elastic is switching to was created in 2018 by database company MongoDB. “This should be a time of incredible opportunity for open source. The revenue generated by a service can be a great source of funding for open source projects, far greater than what has historically been available. The reality, however, is that once an open source project becomes interesting, it is too easy for large cloud vendors to capture most of the value while contributing little or nothing back to the community,” Eliot Horowitz, CTO and co-founder of MongoDB, wrote at the time of its announcement. 

According to Banon, SSPL will provide users with free and unrestricted use and modification as long as they don’t provide the product as a service. Companies that provide the software as a service must release their management software back as free and open code under the SSPL.

The Elastic License was also first introduced in 2018 when the company changed its default distribution to include all features. Banon explained this has allowed users to continue to engage with customers in the open and build free features without other companies like Amazon profiting off them without contributing back. 

“While each open source company has taken a slightly different approach to address this issue, they have generally modified their open source license in order to protect their investment in free software, while trying to preserve the principles of openness, transparency, and collaboration. Similarly, we are taking the natural next step of making a targeted change to how we license our source code,” Banon wrote.

The license changes are expected to start with the upcoming release of Elastic 7.11. More information is available here.

The post Elastic changes software license to better protect Elasticsearch and Kibana appeared first on SD Times.

According to the guide, open-source licenses can be categorized under copyleft or permissive. Under a copyleft license, users who use a component of the open-source software must make their code available to others. Under a permissive open-source license, the open-source software can be free to use, modify or redistribute, but it also permits proprietary derivative works.

In addition, the guide reveals permissive open-source licenses are on the rise.

RELATED CONTENT: Making open source work for you and your business

“This can be explained by the continuous rise in open-source usage. Open source has become mainstream, and the open source community is embraced and supported by the commercial software community,” the guide states. “With companies like Microsoft and Google standing behind some major open-source projects, the ‘Us’ vs. ‘Them’ mentality that ruled in the early days of open source is long gone. In the interest of this widespread cooperation, and encouraging open source usage, permissive licenses are winning.” 

The top open-source licenses, according to WhiteSource, are:

1. MIT
2. Apache 2.0
3. GPLv3
4. GPLv2
5. BSD 3
6. LGPLv2.1
7. BSD 2
8. Microsoft Public
9. Eclipse 1.0
10. BSD

“The copyleft movement carried the interests of Open Source well, but pressure has grown recently due to it being either too restrictive or not restrictive enough in the eyes of creators. For those whose main motivation is seeing widespread use, permissive licenses work best even if that allows the possibility of being modified for use in closed source. Meanwhile for those who have an ideological motivation such as preventing the use of their code in weapons, copyleft is not restrictive enough because it forbids that type of discrimination,” said  Rhys Arkins, director of product management at open source security and license company WhiteSource. “Finally, you see creators of open source who want to make their software free except for usually a very narrow concept of direct commercial competition – this is again something not supported by traditional licenses. The latter two use cases chip away at the dominance of not just copyleft but also permissive licenses too.”

The post The top open source licenses appeared first on SD Times.

“Through this initiative, we hope ultimately to increase participation in the use and development of open source software by helping to ensure that enforcement, when it takes place, is fair and predictable,” according to the commitment’s website.

The new companies are Amazon, Arm, Canonical, GitLab, Intel, Liferay, Linaro, MariaDB, NEC, Pivotal, Royal Philips, SaS, Toyota, and VMware. Other existing members include: Red Hat, Facebook, Google, IBM, CA Technologies, Cisco, HPE, Microsoft, SAP and SUSE.

According to Red Hat, by joining the GPL Cooperation Commitment, these companies reject harsh tactics in open source licenses and support the idea that personal or corporate gain is not appropriate in open source.

“We are pleased to honor open source community traditions by encouraging this collaborative approach to license commitments among our fellow participants in the open source ecosystem. We are also grateful to the development community for having provided the intellectual underpinnings of the approach to us and the other companies,” said Michael Cunningham, executive vice president and general counsel for Red Hat. “Many thanks to the Free Software Foundation, Linux Foundation, Linux Foundation Technical Advisory Board, Software Freedom Conservancy, Software Freedom Law Center and all the others that helped lead the way.”

The post GPL Cooperation Commitment gets more support for open source licensing appeared first on SD Times.