search

googleforgames / quilkin

Quilkin is a non-transparent UDP proxy specifically designed for use with large scale multiplayer dedicated game server deployments, to ensure security, access control, telemetry data, metrics and more.
Apache License 2.0
1.28k stars 92 forks source link

Add cargo-deny config #239

Closed XAMPPRocky closed 3 years ago

XAMPPRocky commented 3 years ago

I was reading over the release steps and I noticed there's a step about ensuring dependencies with a specific licence are properly vendored. Embark has already made a tool for checking licences of a dependency. It might be worth automating that step by having a configuration that warns when a dependency with that licence is found in the graph, and then add it to an exception list once it has been archived.

markmandel commented 3 years ago

🤔 definitely an interesting idea. At the very least, we'll likely need to not allow *GPL licences in the codebase, because they spread. We could bake that into a CI step.

I had a look, but the tool can't do a check to see if the source code is vendored in any way, can it? (that's one of our OSS compliance steps for containers)?

XAMPPRocky commented 3 years ago

I had a look, but the tool can't do a check to see if the source code is vendored in any way, can it? (that's one of our OSS compliance steps for containers)?

Not automatically, but for the vendored licence deps, you could have it always deny or warn until you manually add them to the exception list with the changes to vendor them. That at least gives a trail of who approved what dep, when, and why.

markmandel commented 3 years ago

If someone added a new MPL licenced dependency (of which we already have one) - Would we get a new notification that there is now a second one above and beyond the first? Or no, since it's already an approved licence type?

I;m assuming we would only get a warning/error on each new licence we haven't previously allowed - not on new versions of an already allowed licence? (if that made sense?)

XAMPPRocky commented 3 years ago

If someone added a new MPL licenced dependency (of which we already have one) - Would we get a new notification that there is now a second one above and beyond the first? Or no, since it's already an approved licence type?

Hmm, yeah there isn't really a nice way to automate this at the moment. But as you said at the very least there are some licences that we don't want, so I can at least add a config covering that and we can go from there. Is there a specific list of licences I can cite or should we just start with the GPL variants?

markmandel commented 3 years ago

Is there a specific list of licences I can cite or should we just start with the GPL variants?

GPL variants solve both problems. So sounds good to me! 👍🏻

XAMPPRocky commented 3 years ago

Well I guess a better question would be, is copyleft a not allowed in general? For example, are MPL licensed dependencies allowed? Right now we have slog-json which is MPL-2.0.

markmandel commented 3 years ago

That's an excellent question! I went and double checked.

AGPL is definitely out: https://opensource.google/docs/using/agpl-policy/

From https://opensource.google/docs/thirdparty/licenses/#restricted I would also argue that LGPL and GPL are also out (and the others in this list). They tend to make it harder for external parties anyway, but if we include any of these licences, we can't use this open source product inside Google either.

MPL falls under "reciprocal" licences. They are a bit more tricky, but manageable and okay. https://opensource.google/docs/thirdparty/licenses/#reciprocal

To SYAC:

The ‘reciprocal’ licenses apply the same permissions and limitations set by the Restricted category of licenses, but with one important exception. The obligation to make source code available to recipients of software that depends on a Reciprocally-licensed library only extends to the contents of the library itself, together with any additions to or modifications of that individual library.

Sound good?