As a newly registered user, I want to agree to the FPCA so that I can proceed to join other groups that require it about noggin HOT 15 CLOSED

Does anyone have any further context on how CLA signing is going to be done with freeIPA?

from noggin.

We need to find out who to run this by @sfinn85

from noggin.

Hi @ryanlerch

CC @abompard

Please see doc from our conversation with Jim, Fabian, Rick and Aurelien around CentOS/FAS integration. It was decided that the merged FAS account should take the same action regarding the CLA. Can you review and let us know if you need further insight.

https://docs.google.com/document/d/1pAtWzIHIzFrq9t9cw8rq8vDo8s7TELXwXjLQHIYPneA/edit

Thank you

Sarah

from noggin.

A few notes and questions on this one:

• The CLA was replaced with the FPCA right? If so, we need to change the title of this issue
• currently in FAS, the FCPA is a group, that you get placed into when you "sign" the agreement, right?
• currently in FAS, you can't be added or join any other groups until you sign the FCPA, right?

do we want to emulate the same group behaviour in freeipa, or add something to freeipa-fas for this, or does freeipa have a limited user account concpet that we can use here?

Not sure what the plan was regarding the FPCA.

from noggin.

The CLA was replaced with the FPCA right?

Correct

currently in FAS, you can't be added or join any other groups until you sign the FCPA, right?

This is a group setting, which defaults to True indeed

from noggin.

@pypingou so there are groups that don't require the FCPA?

Another question, What is the use-case where someone has a fedora account, but hasn't signed the FCPA?

from noggin.

so there are groups that don't require the FCPA?

I do not know that there are (I'd have to check the DB), but there could be looking at the UI.

I think fedorahosted projects (and now pagure hosted projects) may not require the FPCA, so you could have an account there, contribute to the project without having to sign the FPCA.

@spotrh may be able to help us more on this

from noggin.

So, some history here:
yes, the old cla was replaced by the FPCA. It's not a CLA.
In fas2, groups could require membership in other groups before you could join, and a lot of them had fpca agreement as a pre-requisite group. (But not all of them).
The purpose of the FPCA is just to say "hey, you are contibuting, we are going to assume it's under the MIT license, unless you tell us otherwise and pick any other acceptable to fedora License to contribute under"

IMHO, I'd love to just add this to the new account process. So, you activate your account and it says 'here is the FPCA, click ok to say you have read it'. But that makes it more expansive than fas2 (making it seem at least to apply to anything where fas2 only made it seem to apply to things that required you be in that group).

Failing that, I'd love to see it be some per account attribute ('acked FPCA') and then have some groups say they need that set to allow someone to join, and have a process to ack it and get the attribute set on your account.

I don't know how much of this is legally possible, @spotrh hopefully could chime in on that?

from noggin.

IMHO, I'd love to just add this to the new account process. So, you activate your account and it says 'here is the FPCA, click ok to say you have read it'. But that makes it more expansive than fas2 (making it seem at least to apply to anything where fas2 only made it seem to apply to things that required you be in that group).

Ideally, this would be easiest, and if possible from a legal standpoint my vote is for this approach. However i have two questions:

1. is there a valid use-case for having a Fedora Account, but not agreeing to the FCPA? one example i have heard a while back was for Pagure.io -- someone might want to create an account to file an issue, but not sign the FCPA. (not sure if this is an edgecase we want to support anymore)

2. We would have to figure out what to do with all the accounts in FAS that havent signed the FCPA when we import them.

from noggin.

One angle to consider is also that CentOS doesn't have an FPCA equivalent, so if we consolidate both communities around one instance we'll need to take this into consideration

from noggin.

Yeah, I am not sure I understand this fully either. I think of the FPCA as a informative thing "hey, your contribution will be under MIT license unless you tell us otherwise". I guess there could be some projects on pagure.io or that centos folks contribute to that are not under a free license? If so, then yeah, there might be people who want to contribute to those under a different license. If just seems to me better/easier to get users to ack that here than in every place they might contribute. IANAL.

from noggin.

Unfortunately it seems to some people the issue isn't with the content of the FPCA but with the principle of it. Don't ask me, I don't understand it either, but we've seen people not wanting to sign it out of principle.

from noggin.

The FPCA serves to provide an explicit license for contributions to Fedora from contributors who make contributions without providing an explicit license in some way. We need Fedora contributors to explicitly agree to it before making contributions. If they don't ever want their contributions to be under MIT/CC-BY (code vs content), all they need to do is assert in a clear fashion what license they intend for their contributions to be under.

I would like to see CentOS contributions follow identical logic (we can rename the FPCA to be more generic if needed), especially as they appear to be moving to the same "implicit license default" of MIT.

As far as the logistics as to how they agree to the FPCA, as long as there are no paths where people create an account and make a contribution without agreeing to it, I don't care. :)

from noggin.

fedora-infra/freeipa-fas#103 implements the feature as simple multi-valued string attribute. The approach gets the job done, but it is inflexible and has several drawbacks.

I recommend to invest a bit more time and implement the agreements as first-level LDAP entries. On the one hand it's more work but on the other hand it's much more powerful:

• agreements can have name, description, link, and other attributes
• ability to query agreements (list of defined agreements, get all users that are member of an agreement)
• fine-grained member write permission for each agreement
• users / API cannot define their own agreement strings

from noggin.

To create agreements as first class citizens we have to

• define a new object class for agreements (fasAgreement)
• create a subtree to store agreements (cn=agreements,$SUFFIX)
• define a new plugin with a couple of commands:

class agreement(LDAPObject):

class agreement_add(LDAPCreate):

class agreement_del(LDAPDelete):

class agreement_mod(LDAPUpdate):

class agreement_find(LDAPSearch):

class agreement_show(LDAPRetrieve):

class agreement_add_user(LDAPAddMember):

class agreement_remove_user(LDAPRemoveMember):