A few weeks ago we found that our own pricing page listed a paid feature under the free tier. Nobody had noticed for a while. It made me wonder how many people pick a component because of a bullet point, and never check the thing they actually install.
So here are the checks I would run on any "free" grid before building on it. Every command below was run on our own Community package, and the output is pasted as it came out (one long npm error is trimmed, and marked as such), including the parts that do not flatter us. None of this is legal advice. It is the homework you do before asking a lawyer a better question.
1. Read the licence field, then ignore it
npm view @kanunilabs/datagrid-react license
SEE LICENSE IN LICENSE
That string is the npm convention for "the licence is custom, go read the file". An SPDX name like MIT is more informative, but it only describes that one package. If the features you need are in a second package, the second package has its own licence, and it is usually not MIT.
2. Read the LICENSE file from the tarball
Not the README, not the website. The file that ships with the version you install:
npm pack @kanunilabs/datagrid-react
tar -xzf kanunilabs-datagrid-react-*.tgz
cat package/LICENSE
Things to look for, roughly in order of how often they surprise people:
- Commercial use. Is it granted in words, or just not forbidden?
- Redistribution. Can it ship inside your app? Inside a library you publish?
- Modification. Can you patch it if a bug blocks your release?
- Competing products. Some free licences exclude people building component libraries or dev tools.
- Termination. What ends the licence, and what you must do then.
Ours grants use "including commercial applications" and distribution "as an incorporated, compiled part of such applications". It forbids modification, and it forbids shipping the package as part of a library or toolkit that competes with ours. If you are building an internal dashboard or a SaaS product, that is fine. If you are building a component kit to sell, it is not.
Save a copy of this file next to your release notes. If a later version changes its terms, you want to be able to show which text you agreed to.
3. Find out where the features you need actually live
npm view @kanunilabs/datagrid-react dependencies peerDependencies --json
{
"dependencies": {
"@kanunilabs/datagrid-core": "1.2.0"
},
"peerDependencies": {
"react": ">=18.0.0",
"react-dom": ">=18.0.0"
}
}
Nothing paid is pulled in. The paid edition is a different package, and it is not on the public registry at all:
npm view @kanunilabs/datagrid-react-enterprise version
npm error code E404
npm error 404 Not Found - GET https://registry.npmjs.org/@kanunilabs%2fdatagrid-react-enterprise - Not found
npm error 404
(trimmed)
This is a quick way to read a vendor's docs. If the example for the feature you need imports from a package that the first command did not list, that feature is probably not in the free tier, whatever the feature table says.
4. Call the feature from the free package
The fastest check of all. Take the one feature you would be most upset to lose, and call it on the free component. On ours, Excel export is a paid feature. You do not even need a browser to check, because the controller runs in Node:
import { DataGridController } from '@kanunilabs/datagrid-core';
const grid = new DataGridController({
columns: [{ field: 'id', dataType: 'number' }, { field: 'name' }],
dataSource: [{ id: 1, name: 'a' }, { id: 2, name: 'b' }],
rowKey: 'id',
});
try {
await grid.exportToExcel();
} catch (e) {
console.log(e.message);
}
[datagrid] Excel export is an Enterprise feature. Import EnterpriseDataGrid from @kanunilabs/datagrid-react-enterprise (CSV export is available in Community).
That is the behaviour I would want from any library: a loud, specific error at the moment of the call. A method that silently does nothing is much worse, because you find out from a user.
If you end up on a paid edition, repeat the test somewhere that is not localhost. Many licence checks treat localhost as always allowed, and ours is one of them. A key limited to certain domains will look fine on your machine and show a watermark on a staging domain you forgot to add to the key.
5. Search the build for licence and watermark code
grep -rilE "watermark|unlicensed|trial|licen[cs]e key" package/dist
On our two Community packages this matched only the type declaration files (index.d.ts, index.d.cts), never the JavaScript. The matches are doc comments: one describes the overlay slot the paid edition uses for its watermark, one mentions the unlicensed state in an API description. The code that draws a watermark is not in the free packages.
A match in the JavaScript is not proof of anything bad. It is a pointer to read that part of the bundle and find out when it runs.
6. Search for network calls
grep -rEo "fetch\(|XMLHttpRequest|sendBeacon|new WebSocket" package/dist | sort | uniq -c
No output on ours. That means the Community packages do not phone home for licence checks or telemetry.
A static search can miss calls built at runtime, so do the dynamic version too: load your app with the grid, open the network tab, filter out your own API, and use the grid for a minute. If anything leaves the page that you did not ask for, find out what it is before production does it for you.
What these checks do not cover
They will not tell you whether a library is maintained, whether the vendor will still exist in three years, or what the paid tier costs once your team grows. They also cannot catch terms that live outside the package, such as a separate EULA on a website. For those, ask the vendor in writing.
What they do give you is the licence you would actually be installing and the behaviour you would actually get, checked in about twenty minutes.
Disclosure: this article was drafted with AI assistance. Every command was run by us against the published packages (@kanunilabs/datagrid-react 1.1.1, @kanunilabs/datagrid-core 1.2.0) in September 2026; outputs are unedited except where marked as trimmed.
