A developer-friendly introduction to open source licenses

Martin Torp — Mon, 06 Mar 2023 13:04:02 +0000

The word 'license' probably triggers a sense of discomfort with most developers.
We may think of open licenses as a legal issue that belongs to the legal department, and thus as an issue largely to be ignored in our day-to-day work.
However, if you work with open source libraries and frameworks, which you almost certainly do, then you have to have at least a little bit of basic knowledge of open source licenses.
Licenses can be long, complicated, and full of legal jargon, but luckily, we, as developers can often ignore much of the content in the license by following some basic principles 😌

Let's first briefly consider why we need to care about open source licenses.
If a project is open source, it means that anybody can view, copy and build on top of the source under some conditions.
Those conditions are an important part of the license.
Generally, there are two types of licenses we need to distinguish between known as copyleft licenses and permissive licenses.
Here is the basic distinction.

Copyleft: You may copy, reuse and build on top of a copyleft-licensed project as long as you release your project using a compatible copyleft license.

Permissive: You may copy, reuse and build on top of the permissively-licensed project. You are typically required to credit (add attribution) the project.

If you want to build a project that is closed source, all of your dependencies should be licensed with a permissive license.
If you want to build an open source project, you should either license it with a copyleft license or only use permissively licensed dependencies.
Keep in mind that an open source library or framework tends to have a much broader adoption when it is permissively licensed exactly because it allows others to use it in closed source products.

The list below shows some of the most commonly used licenses and whether they are copyleft or permissive.

License	Type
MIT	Permissive
Apache	Permissive
BSD	Permissive
WTFPL	Permissive
AFL	Permissive
CC0	Public domain (less restrictive than permissive)
GPL	Copyleft

To check the license of a project you can either refer to the LICENSE file on its GitHub page or use one of the many tools available for providing an overview of used licenses.

For example:

If you use pnpm, then you can also use the pnpm licenses command.

I hope this quick introduction to open source licenses was useful.
Please keep in mind that there are many other aspects to licensing that this post doesn't cover.
I'm also not a legal advisor and cannot be held responsible for any legal violations.

Navigating lock files: best practices and tips

Martin Torp — Thu, 23 Feb 2023 11:51:24 +0000

If you are unsure about how to manage the package-lock.json (or yarn.lock) file in your project, you're not alone. This file is essential for ensuring that your project's dependencies are restored to the same versions on any machine where you run npm install(or yarn). This is important because without a lock file, legacy projects may break if a dependency version is changed between installations. Here are some best practices and tips for working with lock files:

Merge conflicts: Do not manually resolve merge conflicts in lock files. npm and yarn can do it for you automatically! If there are merge conflicts in the package.json file, first resolve them manually and then run the npm install (or yarn) command to automatically fix any corresponding conflicts in the lock file. See this gist for more details.
Use in CI: In CI environments, it is best to use npm ci (clean install) instead of npm install. npm ci will ensure a clean installation of dependencies by deleting the previous node_modules and by never making changes to package.json. npm install, on the other hand, may update the package-lock.json file if it is inconsistent with package.json. The yarn equivalent of npm ci is yarn install --immutable --immutable-cache --check-cache (See https://stackoverflow.com/a/69944063 for more details)
Converting between yarn.lock and package-lock.json: yarn uses yarn.lock and npm uses package-lock.json. You can convert a yarn.lock file to a package-lock.json using the yarn import command. Use synp to convert yarn.lock files to package-lock.json.
Don’t change lock files manually: Use npm update and npm install to add and update packages.

Lock files can be intimidating, but they are easy to work with as long as you avoid manually editing them. Following these practices will help ensure that your project runs smoothly.

DEV Community: Martin Torp

A developer-friendly introduction to open source licenses

Navigating lock files: best practices and tips