Why relicense from MIT to LGPL?

[jlarmstrongiv]

See

• 6dcab0d
• https://github.com/zen-fs/core/releases/tag/v2.4.0

Re-licensed under the LGPL. Most projects will not need to do anything, though any forks and patches (not dependents) of ZenFS must also use the LGPL in order to update. This does not extend to the rest of your code. Just like with the MIT license, distributing ZenFS requires inclusion of the license.

Does the LGPL license not require applications, websites, etc. to allow users to switch the library with anything else they choose? To comply with the LGPL license, many distributed projects will dynamically link to the library or allow users to compile projects from scratch. While that’s fine with server usage, web usage is severely impacted by this change, as sending a JavaScript file over the network may count as distribution and impose additional license requirements. Modern bundling setups for the web do not make this easy.

If your goal is for users to open-source library modifications while being allowed to use the library as-is in any project, consider the MPL 2.0 license instead or the LGPL with the static linking exception.

One solution would be to have multiple licenses under the LGPL, LGPL-3.0-linking-exception, and MPL-2.0.

[james-pre]

Hey @jlarmstrongiv, thanks for reaching out!

I'm not an attorney, though I've read through the entire license a few times and will try my best to address your concerns.

Does the LGPL license not require applications, websites, etc. to allow users to switch the library with anything else they choose?

Yes(*), dependents need to make sure that ZenFS can be swapped for different versions or forks. They don't need to make it compatible with them all though. For example if a project uses an experimental feature only present in a specific minor release, then there is no obligation to make it work with future minor releases.

To comply with the LGPL license, many distributed projects will dynamically link to the library or allow users to compile projects from scratch.

Essentially, users need to be able to modify ZenFS without the dependent imposing legal or technical restrictions on doing so. The cool thing about JavaScript is that the "compiled" code is still JS and can be modified as such. Section four and five of the license cover this in more detail.

Here is an example:
If an app is built with Electron the dependencies are all packed in the ASAR under. It is trivial to unpack the ASAR, change the ZenFS code at node_modules/@zenfs/core/, then repack the ASAR.

... web usage is severely impacted by this change, as sending a JavaScript file over the network ... Modern bundling setups for the web do not make this easy.

The AGPL was made specifically to address programs used over network, so I don't know entirely how the LGPL compares with regards to network-based code. Users can not modify code on the server, so they couldn't edit the JS sent anyway, including any libraries. Practically, if you have a web app that uses ZenFS, it is sufficient to include the attribution and repo/source link outlined in COPYING.md.

2.4.2 actually made this easier for projects using bundlers by including a comment that is preserved by bundlers. Any bundles of ZenFS v2.4.2+ will automatically include attribution and a link to the npm package in the code, though user-facing attribution is still required.

If your goal is for users to open-source library modifications while being allowed to use the library as-is in any project ...

This is definitely part of it, though one of my biggest motivations is user freedom and control. I recommend giving What is Free Software? a read.

In my opinion, if someone installs a program on their computer that uses ZenFS, they should have the freedom to modify ZenFS in order to serve them better. I personally wish free software was more prevalent, and would have gone with the (regular) GPL if not for the pervasiveness in the npm ecosystem of overly permissive licenses and competition from other packages licensed under permissive licenses.

Fun fact: MIT-licensed projects require that the license and copyright notice are included in distributions, yet very few actually are.

​

Here is my try at summarizing everything into an easy set of guidelines. Note that this only applies to ZenFS, not the rest of the dependent projects' code.

Overall:

• Intentional obfuscation (especially as anti-debugging measure) is not allowed.
• If you use ZenFS as an npm dependency in your own npm package, everything is already included and you don't need to do anything special as long as you don't distribute ZenFS directly in your package (e.g. a bundle of ZenFS with code that is licensed incompatibly).
• If you are developing a backend for ZenFS, that is completely separate from ZenFS and not treated as a derivative work unless you are copying ZenFS code instead of importing it.

Additionally, if the user installs the project or runs it locally on their computer:

• It needs to be possible to change ZenFS.
• Like mentioned in the Electron example, packing is fine.
• Minifying and bundling (which isn't very useful in a local program anyway) should probably be avoided if you aren't sure it is compliant.
• This does not apply to web apps served by a different computer the user can only access from a browser/website.

Please let me know if you have any other concerns, I'm happy to discuss it further.

[jlarmstrongiv]

Hi @james-pre, thank you for your reply!

I really appreciate your detailed feedback. I agree with your electron analysis, where the code could be omitted from bundling and swapped out. I also agree with your server analysis, which is not impacted by this change because the code is not distributed; however, an AGPL license would affect server code.

The main impact of this change happens on websites, where:

• code is bundled and minified for performance
• there is no easy way to swap out or exclude pieces of the bundle
• the JavaScript is distributed, imposing additional license requirements

This does not apply to web apps served by a different computer the user can only access from a browser/website.

My main concern is that I do not believe this interpretation is correct. Distributing a website with JavaScript files triggers the same rules that Electron apps do, despite the lack of build tools, infrastructure, or any other options to handle the license requirements.

---

Fun fact: MIT-licensed projects require that the license and copyright notice are included in distributions, yet very few actually are.

Like you mentioned, popular bundlers like Vite and Esbuild inline all licenses above the minified JavaScript code. Some apps also include an acknowledgments section, popup window, or legal page where they credit the libraries they depend on. But I agree, many websites do not give the proper public-facing attributions.

---

I do not think you need to revert back to the MIT license. However, the LGPL license is not feasible for web projects, especially those relying on @zenfs/dom. A similar copyleft license like LGPL-3.0-linking-exception or MPL-2.0 would be feasible for web projects. I do not want to violate your license, so the practical effect is that I cannot upgrade the library in my project and will have to somehow replace it.

Having written open-source libraries with licensing ranging from MIT to AGPL, a lot of thought and care goes into the licenses and their requirements. When adding dependencies, I also take care that I do not add dependencies that are incompatible with the license I chose or other dependencies’ license requirements. I completely understand your goal of using a copy-left license, but I worry about the web use case being left out.

[james-pre]

The main impact of this change happens on websites, where:

• code is bundled and minified for performance
• there is no easy way to swap out or exclude pieces of the bundle
• the JavaScript is distributed, imposing additional license requirement

Distributing a website with JavaScript files triggers the same rules that Electron apps do

JavaScript is such a tricky thing to consider from a legal stand point. The user can't edit it since it lives on the server, but at the same time it still runs on the user's computer. I've gone ahead and cleared up that it is okay to use ZenFS in web apps with 5eefbee.

I do not want to violate your license
..., a lot of thought and care goes into the licenses and their requirements. When adding dependencies, I also take care that I do not add dependencies that are incompatible with the license I chose or other dependencies’ license requirements.

I really appreciate you going the extra mile when so many new programmers would just npm i ... without thinking. I hope the updated copying file will clear things up.

[jlarmstrongiv]

Thank you @james-pre! I really appreciate your thoughtfulness around licensing, your openness to feedback, and your adjustments to support the web use case.

JavaScript is such a tricky thing to consider from a legal stand point. The user can't edit it since it lives on the server, but at the same time it still runs on the user's computer.

It’s very tricky! Unfortunately, that’s why you don’t often see LGPL for web libraries. Other licenses like MPL-2.0 were created to help with that.

I've gone ahead and cleared up that it is okay to use ZenFS in web apps with 5eefbee.

Thank you! Does that apply to all backends, like @zenfs/archives, @zenfs/cloud, @zenfs/dom, and @zenfs/emscripten as well? Do all the repositories need a license update?

I hope the updated copying file will clear things up.

Thank you! It helps a lot. I really appreciate the addendum.

It covers the use case for personal projects, though it does not necessarily cover the use case for libraries and frameworks. The challenge with those is that:

• A well-known license listed in SPDX is helpful for general license management, to ensure that not only my dependencies, but also the dependencies of my dependencies, are in the clear. Automated licenses tools are easily able to pick up these standard licenses.
• The addendum may still be ambiguous in some use cases. For example, a common use of electron / tauri / pwa is to wrap a website into an app, where the actual hosted website (e.g. Slack, Spotfiy, Figma, etc.—not local HTML / CSS / JS) is embedded in the app. What happens then? Is it a website? An app? Both? That’s a common question for font licensing that gets different answers depending on which type foundry you ask.
• A well-known license generally has more FAQs, discussions, and clarifications for its use cases. They may have also been reviewed by the Open Source Initiative or legal attorneys too.
• The compatibility of other popular copyleft licenses is considered in the license, like MPL-2.0 which has specific exceptions for combining the code that are under other copyleft licenses, like GPL, etc.
• The more contributors that contribute to a project, the more difficult it is to relicense as time goes by, e.g. VLC.
• It’s important for any work built on top of my libraries, frameworks, and projects to have confidence that all licensing is in the clear, which is difficult with non-standard licenses.

I really appreciate the addendum, as it covers my personal projects. I still highly encourage you to consider the LGPL-3.0-linking-exception and MPL-2.0 license, so that I can use your library as a dependency in open source work in the future too. You can also license this code under all three.

I really appreciate you going the extra mile when so many new programmers would just npm i ... without thinking.

I worry for the programmers using AI without a legal basis. On projects where I care deeply about the licensing, no AI generated code is allowed.

Unfortunately, a lot of licensing is just pedantic by nature. One of my favorite examples is Douglas Crockford’s extra line “The Software shall be used for Good, not Evil” in his custom license. Some companies would ask for exemptions, or just ban the use of those libraries. Even the OSI and Debian stated that it is not an open source license. Eventually, libraries like JSHint relicensed, but it hindered their growth and eventually required a rewrite.

As for me, I just hope to be able to continue using ZenFS, without violating your license. Thanks again for this discussion and your consideration!

[james-pre]

Does that apply to all backends

Yes, I'll get around to updating them. Needless to say you can use them under the exception even though I haven't updated them yet.

A well-known license listed in SPDX ...

ZenFS uses the LGPL v3+ SPDX, however I can add a ... WITH exceptions.md or the like, which is valid SDPX expression syntax (though the exception identifier would be custom). This should be really easy with a semi-automatic license check and fixing script I wrote.

I read through the LGPL linking exception and feel that it is too broad. Even under the standard LGPL, dependents are only required to provide ZenFS' source (I'm satisfied with a link to the npm page or GitHub repo for whatever release is used), and to allow ZenFS to be modified. The latter can easily be satisfied by simply not bundling ZenFS in with all the other code— which for a installable/local app would offer no significant technical benefit anyway.

For example, a common use of electron / tauri / pwa is to wrap a website into an app, where the actual hosted website (...) is embedded in the app.

This is a good question.

The deciding factor is whether the JS is stored on the user's device.

As I alluded to with my Electron example, the exception applys to apps "only accessed by users from other computers over a network". The exception is meant for cases where unmodified ZenFS code is not stored on the user's device(s), excluding browser cache.

The compatibility of other popular copyleft licenses is considered in the license

ZenFS is still licensed under the LGPL (albeit with the exception), so a good starting point is to assume ZenFS is compatible with any LGPL compatible license. The exception is intentionally very narrow, since I can't see any other reasonable use case that wold require such an exception.

I still highly encourage you to consider ..., so that I can use your library as a dependency

For the most part you shouldn't have to worry about using ZenFS. The worst case is that I reach out and request a minor change to some tooling or something. You're clearly conscious about respecting licenses, so I doubt you would have any issues with license compliance.

If you are really that worried, my advice is to keep ZenFS separate from the (potentially minified) bundle for local/installed apps. For web apps the main constraint is to not prevent debugging or reverse engineering ZenFS, so avoiding minification would probably be enough.

As always make sure to include the attribution and link to ZenFS source— for bundles that is automatically included, for user-facing apps you can just add a line/item to the attribution/licenses section of the app.

[jlarmstrongiv]

Thank you @james-pre!

For web apps the main constraint is to not prevent debugging or reverse engineering ZenFS, so avoiding minification would probably be enough.
If you are really that worried, my advice is to keep ZenFS separate from the (potentially minified) bundle for local/installed apps.

I am that worried, because minification is similar to obfusction, which is expressly prohibited in the license. I still think it’s difficult to fiddle around with bundler settings to exclude specifically ZenFS or disable entire optimizations like bundling, minifying, and polyfilling when granular control is unavailable. Loosing the performance gains—fewer requests, less bandwidth, easier caching, etc.—is a difficult trade off. Speaking of compiled JavaScript artifacts, another reason why the MPL-2.0 license is popular is because it specifically covers that use case.

I appreciate you clarifying the combined electron and website example. Another use case I think will be impacted are CLI bundles generated from Node SEA or Deno Compile. It’s a case of distributing JavaScript, but the whole reason it’s bundled in an executable is to make it simple to install and run. Another use case is with ebooks / epubs / SCORM (which are zip files of xhtml, css, and js, and are similar to electron asar files) but some platforms encrypt their content, which would violate the license. I guess my main point is that JavaScript is just about everywhere and in any environment, and the LGPL isn’t easily compatible with many of them.

All in all, I understand your decision not to use the LGPL-3.0-linking-exception and MPL-2.0 license. I am glad that I can continue using the library in my person project with the exception.

However, I still believe the license is hard to use in another library or framework, and may omit other project use cases. Choosing this low-level library as a dependency to other open-source libraries adds requirements to projects that build on top of it, that are at best difficult to implement and may have other tradeoffs, or at worst are difficult to educate users about and lead to license violations.

One other note is that when changing licenses from permissive licenses like MIT to copyleft licenses like LGPL, a major version bump would be helpful. I only found that change because I was reading the patch notes. A major version would help tell users that they are no longer be in compliance with your license. That would help bring attention to the new bundling and attribution requirements.

Does that apply to all backends

Yes, I'll get around to updating them. Needless to say you can use them under the exception even though I haven't updated them yet.

Thanks again!

[jlarmstrongiv]

@james-pre I went ahead and created PRs for the other repos:

• Updated copying.md for clarity archives#18
• Updated copying.md for clarity cloud#4
• Updated copying.md for clarity dom#36
• Updated copying.md for clarity emscripten#5

[james-pre]

Merged =).

[jlarmstrongiv]

Thank you =)