Licensing Icon

Licensing

Every open source line of code needs a license or it's not really open source.
8 Stories
All Topics

.NET github.com

It is expected that all developers become a Patron to use Fody

Here’s an interesting twist on open source funding: require all users to back the project on Open Collective, but only enforce that rule via social pressure. In other words, use an honesty policy: It is an honesty system with no code or legal enforcement. When raising an issue or a pull request, the user may be checked to ensure they are a patron, and that issue/PR may be closed without further examination. If a individual or organization has no interest in the long term sustainability of Fody, then they are legally free to ignore the honesty system. The software is MIT-licensed, so all of those liberal rules apply, but don’t expect to get your PR merged or your issue taken seriously unless you’re a patron. You must be a Patron to be a user of Fody. Contributing Pull Requests does not cancel this out. It may seem unfair to expect people both contribute PRs and also financially back this project. However it is important to remember the effort in reviewing and merging a PR is often similar to that of creating the PR. Also the project maintainers are committing to support that added code (feature or bug fix) for the life of the project. The project currently has 4 organizations and 10 individuals supporting it. What do you think those numbers will look like in 6 months or a year?

read more...

The Changelog The Changelog #322

There and back again (Dgraph's tale)

This week we talk with Manish Jain about Dgraph, graph databases, and licensing and re-licensing woes. Manish is the creator and founder Dgraph and we talked through all the details. We covered what a graph database is, the uses of a graph database, and how and when to choose a graph database over a relational database. We also talked through the hard subject of licensing/re-licensing. In this case, Dgraph has had to change their license a few times to maintain their focus on adoption while respecting the core ideas around what open source really means to developers.

read more...

link Icon github.com

Lerna license change, a follow up

Yesterday’s PR to restrict the MIT license on Lerna has been reverted by @evocateur First, I apologize for making the rash decision to support the addition of an unenforceable clause to the project’s MIT license. I failed to accurately assess the impact of this change, which led me to (incorrectly) focus on the intent. Despite the most noble of intentions, it is clear to me now that the impact of this change was almost 100% negative, with no appreciable progress toward the ostensible goal aside from rancorous sniping and harmful drama. I am reverting the license changes. In the future, such changes (if any) will go through a much more thorough, completely public, and fair-minded process.

read more...

link Icon github.com

Lerna alters license to ban ICE collaborators

Lerna, a tool for managing multiple packages from a single monorepo, is taking a hard stance against companies (and their subsidies) that collaborate with ICE, expressly forbidding those companies from using future versions of Lerna. For the companies that are known supporters of ICE: Lerna will no longer be licensed as MIT for you. You will receive no licensing rights and any use of Lerna will be considered theft. You will not be able to pay for a license, the only way that it is going to change is by you publicly tearing your contracts with ICE. @kittens later commented, discussing how companies subject to this new license could deal with this change: If you’re employed by a subsidiary listed, direct any questions about the usage of Lerna to your company lawyer. This license only applies to future versions, you’re free to use old versions that do not contain this clause. If you have concerns over the legality of relicensing. The MIT license allows sublicensing, which this falls under. Even still, all contributors implicitly agreed to the existing license, of which I am the original license holder, when they submitted code meaning we are within our rights to relicense.

read more...

Matt Klein Medium

The (broken) economics of OSS

In response to the post from Paul Dix on the misunderstandings going on around Redis and the Common Clause license — Matt Klein tweeted: Won’t defend Redis Labs, this is a dead end move, but there needs to be more recognition that the economics of OSS are fundamentally broken. In his post he starts by saying… I want to provide a long form discussion of my two Twitter threads as this topic is nuanced and quite interesting. Note: this post is heavy on opinion and light on facts/references backing up those opinions. Thus, preface everything that follows with “IMO.” Matt goes on to share some history of open source software and his opinions on modern expectations of software being free and open, startups and open source, and who pays…

read more...

Steven J. Vaughan-Nichols zdnet.com

Will Commons Clause destroy open source?

There is a big debate underway over Commons Clause and its recent application to certain Redis enterprise add-ons. The Commons Clause license is open source and was drafted by Heather Meeker — whom you might remember from Request for Commits #9. This language from the license forbids the ability to sell the software (similar to the the Elastic License discussed on The Changelog #292). …the grant of rights under the License will not include, and the License does not grant to you, the right to Sell the Software. Steven J. Vaughan-Nichols writes for ZDNet: Redis Labs has been unsuccessful in monetizing Redis, or at least not as successful as they’d like. Their executives were discovering, like the far more well-known Docker, that having a great open-source technology did not mean you’d be making millions. Redis’ solution was to embrace Commons Clause. This license forbids you from selling the software. It also states you may not host or offer consulting or support services as “a product or service whose value derives, entirely or substantially, from the functionality of the software”. I’m really curious to see how this tread plays out as more and more organizations see service providers (cloud hosting, SaaS, etc.) and consultants (support contracts, etc.) “getting rich” off of the projects they work so hard to maintain as open source, while they struggle to find a sustainable model for funding the efforts to keep the open source ship afloat.

read more...

Salvatore Sanfilippo antirez.com

Redis will remain BSD licensed

The rumors of Redis taking on a new Creative Common license ARE NOT true. Antirez (Salvatore Sanfilippo) writes on his personal blog: Redis is, and will remain, BSD licensed. However in the era of uncontrollable spreading of information, my attempts to provide the correct information failed, and I’m still seeing everywhere “Redis is no longer open source”. The reality is that Redis remains BSD, and actually Redis Labs did the right thing supporting my effort to keep Redis core open. Here’s what IS happening… What is happening instead is that certain Redis modules, developed inside Redis Labs, are now released under the Common Clause (using Apache license as a base license). This means that basically certain enterprise add-ons, instead of being completely closed source as they could be, will be available with a more permissive license. Here’s how Redis is licensed.

read more...
0:00 / 0:00