Inventory licensezero.json files (close #4)

[kemitchell]

This PR tries to address #1 and #3 by closing #4.

The basic approach is:

1. Recurse every directory of the project.
2. If you see a licensezero.json, parse it just like the licensezero property of a package.json file.
3. Look in the same directory.
4. If there's a setup.py, run python setup.py --name --version.
5. If there's a pom.xml, parse the XML for groupId, artifactId, and version.

There is some thinking to be done about how to whether and how to link licensezero.json files to packages, or more likely package metadata. We could require licensezero.json files to include signed data linking the two in some sense. But I'm not sure it's worth trying to enforce links between packages and license metadata technically.

[makkus]

But I'm not sure it's worth trying to enforce links between packages and license metadata technically.

Probably not. Developers would have a strong incentive to make sure everything is correct, and I don't really see the additional value that would provide. As long as the licensezero.json file is shipped with the source (and is included in the package), that should be enough, no? I might be overlooking something, haven't really looked into how the licensezero cli app works at all.

If I overlooked something, in a pinch: would including the hash for the setup.py (or, alternatively pyproject.toml in the future) file in licensezero.json be of any use? It'd probably need to be a list of hashes as it would change with every version change. But that would have the advantage of being portable to most other project types, as almost all of them have some sort of central project metadata file. Could even be used for a single bash script, if one wanted to license that...

[kemitchell]

@makkus I think you’re right. Whether the metadata appears in the same file as package manager data or a separate file, it’s up to the developer to make sure it’s accurate, and up to buyers to exercise basic caution.

I’m leaning strongly toward licensezero.json for all kinds of projects, even npm packages. And also displaying more information about where license data was found in quote output. For example, by displaying file system path and whatever basic package manager data can be found in the same directory. That should, make it much easier to sanity check, at a glance.

[kemitchell]

If I overlooked something, in a pinch: would including the hash for the setup.py (or, alternatively pyproject.toml in the future) file in licensezero.json be of any use? It'd probably need to be a list of hashes as it would change with every version change.

I think your instincts here are absolutely right. If you want to link two files, have one contain the signed hash of the other.

Unfortunately, the signing requirements mean you’d have to regenerate each time there’s a change to the hashed file, or settle for signing some subset of its data.

The latter seems more promising, but clashes with L0’S internal goal of avoiding storing data like user or project handles, project names, and so on. Publishing user selected names, as GitHub, npm, and other repositories and registries do, means trademark problems. Scaling trademark problems requires a full time team.

L0 does store repository URLs. But in stacked projects, the URLs for original work and forks could differ. Checking a signed URL against declared package URL could break stacking.

[makkus]

I’m leaning strongly toward licensezero.json for all kinds of projects, even npm packages.

I agree, if you can pull off a generic solution that works for any (or almost any) type of project, even at the expense of a bit of convenience for license sellers, I'd go for it. Having to support every possible language/project type separately doesn't seem desirable, if at all avoidable.

What properties exactly are stored in licensezero.json, by the way? Is there a schema or example around somewhere?

[makkus]

Another quick thought: how about hashing the url to the 'main' project file (package.json, setup.py, pyproject.toml -- the user could decide themselves which one to use), e.g. on github. Maybe in combination with the relative path within the project directory if necessary. The file itself could change then. Only requirement would be that the url doesn't change.

Hm, but that's probably no good either, because if you want to release a new major version with a new identifier, you'd have the same url...

[kemitchell]

What properties exactly are stored in licensezero.json, by the way? Is there a schema or example around somewhere?

Check out https://github.com/kemitchell/crgmw-diff.js/blob/5fe9e9d951862b3c596e4189023be96bf8351150/package.json#L22

[kemitchell]

@makkus now in licensezero.json: https://github.com/kemitchell/crgmw-diff.js/blob/4ed1841b83b384c843b485666a9add75cdcd2932/licensezero.json