跳到正文
DEV Community· Elsie Rainee·· 3 小時前AI 評分51

開源仍然開放嗎?近期授權變更及其影響對象

Is Open Source Still Open? A Look at Recent License Changes and Who They Hurt

AI 導讀

Elsie Rainee 梳理近期開源項目的授權變更,指出授權可能隨版本改變,部分項目改用 source-available 或非商業授權。例子包括 Loki Mode 於 2026 年 3 月 19 日由 MIT 改用 BSL 1.1、Unleash 宣佈核心儲存庫由 Apache 2.0 轉向 AGPLv3,以及 MiniMax M2.7 由 MIT 改為非商業授權。

正文

Cover image for Is Open Source Still Open? A Look at Recent License Changes and Who They Hurt

Elsie Rainee

A few years ago, I checked a dependency’s license once, at install time, and never again. That habit is getting expensive.

License changes aren’t new, but they’re happening often enough that “it’s open source” is no longer a permanent property of a project. It’s a status that can change between releases.

The pattern is almost always the same.

The shift nearly always runs one way: from an OSI-approved permissive or copyleft license toward a “source-available” license the Open Source Initiative doesn’t recognize as open source.

The Business Source License (BSL) is the most common destination. It’s a “delayed open source” license: the vendor sets restrictions up front, and each version converts to a true open-source license after a change date, typically four years out.

It’s not just the famous cases anymore. A few from this year alone:

  • Loki Mode moved from the MIT License to BSL 1.1 effective March 19, 2026.
  • Unleash announced in June 2026 that its core repository is moving from Apache 2.0 to AGPLv3. AGPL is OSI-approved, so this one is a different kind of change, but it still affects anyone embedding the code.
  • MiniMax moved its M2.7 AI model from MIT to a non-commercial license, which drew immediate backlash.

Who it actually hurts

  • 1. Small teams and agencies building on top: If your product depends on a library that relicenses, you now have three options: pay, migrate, or fork. Big companies have legal teams for that. A five-person shop usually doesn’t.
  • 2. Contributors: People gave their time to a project under one set of terms. When the company controlling it changes the rules, the community’s work becomes part of a product they no longer fully share in.
  • 3. Downstream projects: Plugins, integrations, and tutorials built around a tool inherit the uncertainty when its license shifts.

The fair counterargument

I don’t think vendors are simply villains here. Many of these changes were a response to cloud providers selling managed versions of a project without funding it. Maintainers need a sustainable model, and “be open and hope for donations” has a poor track record.

It’s also not always one-way. Redis is back under a recognized open-source license for those who choose it, while Valkey continues to be actively developed. Competition between the original and the fork may have pushed both toward better outcomes. Broader data also suggests permissive licensing has been rising, so this isn’t a total collapse of open source.

What I do now

  • Check who controls the project A single company controlling a project can relicense future versions at any time, while a project run by a neutral foundation with many contributing companies is much harder to change.
  • Read the license on every major upgrade, not just at install.
  • Pin versions so a surprise change doesn’t land in your next deploy.
  • Know your exit. Is there a credible fork? A foundation-backed alternative?
  • Set up license-change alerts for your critical dependencies.

So, is open source still open?

My honest answer: the code is still often open. The guarantee isn’t. Open source has always depended on trust, and trust now needs a little due diligence.

Over to you: Has a license change ever forced your team to migrate? Do you think relicensing is a fair business move, or a betrayal of the community that built the project? Tell me in the comments.

來源:DEV Community · dev.to