Document guidelines for inclusion of Chart repository in distributed search about hub HOT 7 CLOSED

One such guideline will need to be:

We cannot include repositories physically hosted in US embargoed countries.

The CNCF/Linux Foundation is a US non-profit and needs to comply with US laws.

from hub.

yes, good point

from hub.

These aren't all "legal" considerations but many are legal-adjacent.

1. For trademarked projects, will we allow anybody at all to submit a chart? E.g., for MySQL, can anybody submit a chart that could become the "official" MySQL chart, or only someone from Oracle? If someone from Oracle objected, would the community have processes in place to modify or remove a chart? This gets into trademark considerations as well as security / squatting issues, I expect.

2. How is license info communicated, for the chart vs. the software? I'm assuming that the charts themselves would be licensed under Apache-2.0. It should be made clear to users that this doesn't mean the underlying software itself is also all Apache-2.0. I would hope that an "approved" chart would need to accurately describe the license(s) for the applicable software, ideally using SPDX identifiers (https://spdx.org/licenses) to make automation more feasible.

3. What's the escalation process for reporting charts that are malware or include vulnerable versions of the software. Will these charts be pulled until they can be updated?

4. Since we aren't actually distributing the software, the export controls aren't critical. (It does make sense to add a policy not to list charts that point to repos under a TLD for a sanctioned country.)

Cc @swinslow

from hub.

@dankohn sorry I didn't link it here... we started a doc at #5

from hub.

For trademarked projects, will we allow anybody at all to submit a chart? E.g., for MySQL, can anybody submit a chart that could become the "official" MySQL chart, or only someone from Oracle? If someone from Oracle objected, would the community have processes in place to modify or remove a chart? This gets into trademark considerations as well as security / squatting issues, I expect.

Everything is going to be namespaced by repo. That means you can't squat on a name like some have done at npm.

Initially we are not looking to have "official" charts. It's more akin to Packagist with search and metadata to help find charts. Take, for example, mongodb on packagist... https://packagist.org/?query=mongodb. Expect the hub to have multiple versions of an app as a chart just like docker hub has multiple images for the same app (e.g., mongodb)

We can discuss official repos after launch. Right now we are trying to unblock people releasing new charts and updating them. We have too much growth to maintain the current processes with the community repo.

How is license info communicated, for the chart vs. the software? I'm assuming that the charts themselves would be licensed under Apache-2.0. It should be made clear to users that this doesn't mean the underlying software itself is also all Apache-2.0. I would hope that an "approved" chart would need to accurately describe the license(s) for the applicable software, ideally using SPDX identifiers (https://spdx.org/licenses) to make automation more feasible.

We've not discussed chart licensing. Since we are not distributing the apps themselves we're not responsible for their licenses. We are also not distributing the charts but rather providing search of them. Do we limit the licenses? Do we say only OSI approved licenses?

What's the escalation process for reporting charts that are malware or include vulnerable versions of the software. Will these charts be pulled until they can be updated?

Great question. We need to work this out. We are requiring all charts to have valid contact information so reports of security issues can go to the chart authors/repo managers to fix. Currently, we are not in the loop but it might be good to provide a method for handling this.

I've created issues to chase down reporting issues and looking into de-listing something.

from hub.

Do we limit the licenses? Do we say only OSI approved licenses?

I see no need to limit the license or require OSI-approved. But I would love to at least support (and ideally require) SPDX labeling, as it would enable a ton of useful automation later.

from hub.

This was documented via #5. Closing this issue.

from hub.