1 |
On Thu, Jul 13, 2017 at 8:58 AM, Andrew Savchenko <bircoph@g.o> wrote: |
2 |
> On Wed, 12 Jul 2017 13:16:50 -0400 Rich Freeman wrote: |
3 |
>> |
4 |
>> So, the structure would look something like: |
5 |
>> |
6 |
>> Council |
7 |
>> - QA |
8 |
>> - arch teams |
9 |
>> - KDE team |
10 |
>> - Comrel |
11 |
>> - Local Organization team |
12 |
>> - e.V. |
13 |
>> - Gentoo Foundation |
14 |
>> - Umbrella Org 1 |
15 |
>> |
16 |
>> (Just a smattering of projects above for illustration - this isn't a |
17 |
>> change to how the rest of the distro works. The relationship between |
18 |
>> the various legal bodies and the Council is not legally formalized - |
19 |
>> they would be accountable to their members which should be aligned to |
20 |
>> the distro members, and should be controlled in a way to avoid |
21 |
>> forks/etc.) |
22 |
>> |
23 |
>> Just my thoughts on the matter... |
24 |
> |
25 |
> Thanks, this is indeed a good architecture. Actually we'll have this |
26 |
> way a container/VM-level separation of legislative risks and |
27 |
> opportunities while still connected via the same host system to |
28 |
> achieve the same goals. I really like that :) |
29 |
> |
30 |
|
31 |
It still has a weakness that IMO is not easily avoidable: legally the |
32 |
various orgs are not accountable to the Council directly, which means |
33 |
that they could do hostile forks/etc. The issue is that countries |
34 |
operate with sovereignty and their laws operate accordingly. So, to |
35 |
DE the e.V. is Gentoo, and to the US the Foundation is Gentoo, and |
36 |
maybe in some other country some umbrella org is Gentoo. The overall |
37 |
distro really is a non-entity from a legal standpoint everywhere. |
38 |
|
39 |
The strength is that the boards running the various legal entities |
40 |
only need to focus on keeping the legal entity running, and formal |
41 |
legal activities are firewalled inside their borders so that the |
42 |
overall distro has a lower overhead. It also allows individual legal |
43 |
entities to be spun up or down as needed, and firewalls them from each |
44 |
other. |
45 |
|
46 |
Note that the firewalls are not perfect. You can't have the parent |
47 |
distro just doing blatantly illegal stuff because if that happens |
48 |
somebody will be determined enough to poke holes in this, and of |
49 |
course anything that happens in the physical world happens on a box |
50 |
owned by somebody. Since criminal organizations tend to play legal |
51 |
games the laws generally are written to handle them. |
52 |
|
53 |
The more traditional approach would be something like this: |
54 |
|
55 |
Gentoo Foundation (US) |
56 |
- Distro Ops Team (Council) |
57 |
- arch teams |
58 |
- KDE team |
59 |
- Accounting |
60 |
- HR |
61 |
- Legal |
62 |
- Subsidiary Relations Team |
63 |
- e.V |
64 |
- Umbrella org 1 |
65 |
- Gentoo run subsidiary in random country |
66 |
|
67 |
(You could of course put any of the legal entities on the top and the |
68 |
US foundation underneath too.) |
69 |
|
70 |
In this model (which is how most multinational companies operate) |
71 |
there would be formal legal control. In this instance the US board |
72 |
would have overall governance of everything. The issues with the |
73 |
traditional model are: |
74 |
1. The board has to be jacks of all trades, or at least be trusted to |
75 |
stay in the lines because legally they control everything everywhere. |
76 |
2. Everything falls under the legal umbrella, so the laws of the |
77 |
parent country basically apply to everything we do. The really tricky |
78 |
US laws like embargoes/etc generally apply to foreign subsidiaries, |
79 |
for example. |
80 |
3. There will inevitably be a debate over which country ends up on |
81 |
top. Even if the "right" choice is made, as manpower shifts the |
82 |
structure could become inconvenient, with the country that was picked |
83 |
because that is where most devs live becoming the country where nobody |
84 |
lives anymore. Changing the structure is difficult or impossible. |
85 |
4. It has more of a sense of putting the suits in charge. To be fair |
86 |
this is how a LOT of FOSS orgs operate (think Apache, Mozilla, |
87 |
Canonical, etc). However, I suspect it is not the model most would |
88 |
prefer here. |
89 |
|
90 |
-- |
91 |
Rich |