Re: [gentoo-nfp] Merging Trustees and Council / Developers and Foundation - 1.0 reply

["Robin H. Johnson" <robbat2@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 4044 bytes --]

TL;DR: Unless a specific "evil" person/organization/entity is trying to
interact with Gentoo AND it's on restricted grounds AND we know they are
bad, we have no large concerns.

The devil is in the details.

On Tue, Jan 10, 2017 at 04:39:32PM -0600, Matthew Thode wrote:
> 3. US Embargo.
> 
>   We are already a US organization, that, in my non-lawyer mind, means
> we already have to deal with this.  Just because a developer is a member
> of the project and not directly under the foundation does not mean the
> foundation can ignore US embargo policy.
> 
> That said, I don't really think this has been a problem in the past and
> will likely not be a problem in the future.
As the person that has looked into this issue the most, with actual
legal counsel backing my answer, I will provide my definitive answer.

The research was triggered by a potential developer from a previously
sanctioned country. It was made moot by said person moving to the US.
They did not join us a developer however, citing lack of time after
moving.

The following definition based on the state of most broad sanctions
being replaced by very targeted sanctions in most cases, against
whatever the US government doesn't want to happen (arms dealers, russian
oil, WMDs etc.)

The Foundation, as a US entity,
1. CANNOT _knowingly_
1.1 do business with or
1.2. have as a member
2. ANY entity 
2.1. corporation, 
2.2. organization 
2.3. individual
3. Is covered by ANY of the following:
3.1. US BIS Denied Persons list [1]
3.2. US Federal Regulations (15)(B)(VII)(C)(744) [2]
3.3. US Department of State Trade Controls [3][4]
3.4. US Department of Treasury Specially Designated Nationals [5]
3.5. US Consolidated Screening List [6]
4. In certain cases, specific exemptions to the above CAN be applied
   for.

For some background, see [10]

[1] https://www.bis.doc.gov/index.php/the-denied-persons-list
[2] http://www.ecfr.gov/cgi-bin/retrieveECFR?gp=1&SID=9ae4a21068f2bd41d4a5aee843b63ef1&ty=HTML&h=L&n=15y2.1.3.4.28&r=PART#15:2.1.3.4.28.0.1.23.42
[3] http://www.pmddtc.state.gov/compliance/debar.html
[4] http://www.pmddtc.state.gov/compliance/debar_admin.html
[5] https://www.treasury.gov/resource-center/sanctions/SDN-List/Pages/default.aspx
[6] http://2016.export.gov/ecr/eg_main_023148.asp
[10] https://www.bis.doc.gov/index.php/policy-guidance/faqs#faq_104

> 
> 4. Why is the existing model bad? (more info)
> 
>   We have two voting pools that can be divergent in their goals.  What
> would happen if the foundation wanted x and the council wanted !x?
> 
> 5. We should have a BDFL (more or less)
> 
>   I don't agree with this personally and it is not the goal of this
> proposal to move to that model.
> 
> 6. Liability increase by having all devs be members of the Foundation.
> 
>   William summed it up pretty well, 'working on the project makes you
> and the project more liable than being a member'.
> 
> 7. Exclusion of the community.
> 
>   I don't think this is as much a problem as people think.  The
> definition of 'developer' changed about a year ago to mean what used to
> be 'staff or developer'.  So anyone who is what used to be called staff
> (which I think people applying to the foundation should probably be
> considered) would have representation (through their vote).
> 
> 8. Merging the voting pools.
> 
>   The process for this will be better defined in the next version of the
> proposal.
> 
> 9. Members of the 'board' having conflicts with their job.
> 
>   I'm, not sure about this as it's likely case by case.  But I
> personally don't see this causing much more issues than what is already
> caused by working on an open source project.
> 
> -- 
> Matthew Thode (prometheanfire)
> 
> 
> 




-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Trustee & Treasurer
E-Mail   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 1083 bytes --]