Terms of Service

[chouseknecht]

• [ ] Create an actual TOS for Galaxy
• [ ] Prompt users to accept on login
• [ ] Prompt users to accept on login whenever there is a TOS update
• [ ] Track TOS acceptance so that Galaxy only prompts the user 1x, or until accepted
• [ ] For an authenticated user, don't allow further access until TOS is accepted.

[chouseknecht]

@gregdek

We need some legalese for a Galaxy TOS. Specifically what we're concerned about is protecting namespaces that may be associate with a third party's trademark.

For example, imagine Acmeco (insert any company name) comes along and wants their name represented in Galaxy. However, someone else, not related to, nor part of Acmeco has already registered the 'Acmeco' name. We (Red Hat) should have the right to reassign ownership of the 'Acmeco' name in Galaxy to the rightful owners of the trademark.

The same may happen for a regular user where no trademark actually exists. For example, imagine somehow that someone other than Jeff Geerling claimed the name 'geerlingguy'. We should have the right to reassign the name to the rightful owner, as we see fit.

Those are the things we're concerned about, as we add the ability for users to create top-level namespaces (or Organizations) in Galaxy. For this new feature, the user will be able to create an Organization in Galaxy with whatever name they want, and then associate SCM (i.e., GitHub) namespaces to the Galaxy organization.

Obviously there are likely a lot of other things that should be in our TOS, and so we need a proper, Red Hat approved TOS that also covers our concerns.

[gregdek]

This is part of why I think the top-level namespace is just a mapping, and in the near term we give those top-level namespaces only to specific partners.

If Acmeco has specific control over what namespaces they map, this should be a non-issue, because regular users shouldn't yet be able to claim their own namespaces at all.

Any corporate ToS can be very simple: "don't claim projects in your namespace if you don't own them, and we reserve the right to remove projects from namespaces."

This also insulates us from confusion at the GitHub level. If some random person in GitHub creates "TheAcmeCoOrg" as a namespace, then that's an issue between AcmeCo and GitHub. But in the meantime, AcmeCo can make sure that any Galaxy content that might appear there doesn't appear in their Galaxy namespace.

[chouseknecht]

I updated #243 to better explain what we're attempting to do with the notion of 'namespace' inside of Galaxy.

Here's the gist...

Firstly, the Group (the model for the Galaxy top-level namespace) is not limited to a 'partner' for the following reasons:

• A Group is not a 'partner'. 'Group' and 'partner' are two separate concepts.
• In the future, a Group may be designated as a 'partner' by simply turning a Group attribute on or off.
• We don't know today who or what a partner is.
• We do know we need to deliver content by Group.Repository_Name.Content_Name.
• Because of wanting to deliver content based on Group, and not SCM Namespace, every SCM_Namespace needs to map to Group.
• Group future-proofs the Galaxy data model, and puts us closer to supporting multiple SCMs.

Once we're ready to define what a 'partner' is, and the process for achieving 'partner' status, then we simply create a mechanism for turning-on the 'partner' attribute for a Group. Simple. And if in the future, the business wants to create more designations, we can simply add new attributes to the Group. Again, simple.

Secondly, we're allowing users to create a Group for a couple reasons:

• A group does not hold any special meaning. As mentioned above, a Group is not automatically a 'partner'.
• We don't want to attempt to define and support a manual process for creating or giving out Groups.
• A Group creates a nice mechanism for anyone to have a public Profile within Galaxy that is completely separate from their SCM Profile(s)
• A Group allows everyone the ability to aggregate their content repositories from multiple SCMs under one Galaxy namespace.

[gregdek]

OK, understood. That makes sense.

My next question, then: should users be allowed to add Group content that isn't "theirs"?

I would argue that the answer is "no", especially if (a) the purpose of the Group is to indicate "owner-ness", and (b) you want it to be fully automated. Which means that ToS for this should not be needed; it should driven automatically by policy. The mechanism for adding a repo namespace to a group should ensure that the party adding has access to that namespace.

If you try to add a namespace that you do not own to a Group, it should fail.

This also means that we're going to have to get all of the owner relationships exactly right. What happens when someone has access to a Group, but not to one of the namespaces in the Group? Who decides who has admin rights to a Group?

I'll comment more in #243.

[gregdek]

OK, on reading #243 more closely, I've got a better understanding. This in particular:

"...a given SCM_Namespace can only belong to a single Group..."

...clearly implies that Group means Ownership.

My next question is: what does cleanup look like if someone goes "rogue"?

If the only purpose of a Group is a pretty landing page, then it's probably no big deal either way. We kick the squatter off, we hand the Group to the "rightful" owner, and everything is fine.

But if the purpose of a Group is also some kind of "group-install", such a cleanup could get ugly, fast.

For example: I decide to squat on the "Cisco" Group name, and because I got there first, I set up a bunch of roles that I think are the best Cisco roles/modules. And I set up "Cisco:gregdek/cisco-role-1" through "Cisco:gregdek/cisco-role-100". Which I do with impunity, because Cisco isn't paying attention -- until I've got a hundred roles/modules with a hundred thousand users, and a whole bunch of legacy infrastructure that uses "group-install Cisco" across their entire CI farms.

The cleanup in that scenario is a nightmare. We say "sorry, you violated the ToS that you didn't read, so we're dumping this group and handing it to Cisco." And we get a lot of super-angry users, whose only mistake was using the "wrong" content.

If we're successful, then I believe this scenario is not only possible, but even likely.

I would much rather have some simple "ack" mechanism to prevent this. Maybe it's an "apply for Group" process that's simple, and not too onerous on the back-end to administer.

[chouseknecht]

@gregdek

My original thought on preventing squatters was to come up with some sort of automated workflow.

Maybe something like this:

• User enters a new Group name
• Galaxy checks if the Group name matches a namespace on each supported SCM.
• If there is a match, then check if the user is part of the SCM namespace.
  • If the user is part of the SCM namespace, the Group can be created.
  • If the user is not part of the SCM namespace, the Group cannot be created.
• If there is no match, the Group can be created.
• The next step in creating the Group is, asking the user to acknowledge what may happen, if they squat on a third-party's name.

[chouseknecht]

Agreed, if we have to kick a squatter off of a Group, the fallout could be bad for downstream users. But without a manual process, I don't know that we can completely fool-proof it, and at the same time, I really don't want us to plan to rely on a manual process. Historically, we haven't been good at keeping up with manual processes.

[chouseknecht]

Group is now 'Namespace', and SCM_Namespace is now 'Provider_Namespace'.