Add a native license package attribute

[JeanChristopheMorinPerso]

Rez currently has no way to officially communicate the license(s) associated to a package. By license I mean OSS license.

This is a feature we need in order to be able to scale rez's use cases.

I suggest that we add a new package attribute to track the license of a package. Most (if not all) package managers support this natively. Most of them only support SPDX identifiers. We should also support SPDX expressions. We also technically need a way to bundle one or multiple license files.

Before implementing this, we should survey the most popular package managers and package ecosystems (python, rust, ruby, brew, rpm, apt, spack, conan, etc).

Use cases:

• rez-pip needs to keep track of licenses. That's useful when studios have to comply to rules set by legal departments. And this doesn't just apply to rez-pip. License compliance applies to everything that is externally sourced.

Questions to answer:

• How flexible should we be regarding accepted values?
• What happens with packages that already use license?
• Should we have facilities to query licenses or limit licenses in a resolve? How would compliance be achieved by studios?

References:

• https://rfc.archlinux.page/0016-spdx-license-identifiers/

[jeffbradley-dreamworks]

This is a great question. I'd like to think about it a bit longer, but offhand, I'm not sure my studio currently has a need to track licenses in a way that's tightly coupled to the rez package. I recognize you're probably thinking further ahead, and I'd love to discuss it at an upcoming meeting.

We definitely check licenses and are careful about any use restrictions, but our overall tracking is more associated with regular checks of the source code, bringing OSS into the studio, and specific handoffs. Our rez packages are only consumed within our studio and the licensing has already been managed at that point.

We don't use rez-pip due to limitations in the original, and are interested in the new version but haven't had a chance to try it out. The pip install domain certainly makes this more exciting, when dozens of dependencies are brought in automatically. We perform some checks of those dependencies.

It's absolutely valuable when licenses are clearly defined. There's too much ambiguity in the OSS world with how licenses are associated with code.