You over complicate this

Seriously? We're talking about the constitutions of businesses that people's livelihoods will depend on. To paraphrase Lessig, law is code". It runs exactly as it's written. If it's not written precisely, you get bugs coming back to bite you at run time.

and also place too little trust in people and cooperation.

Not at all. I trust that people will do their best to follow the rules they've agreed to. If those rules tell them to divide-by-zero, it's going to cause stress and disunity as everyone tries to figure out which of the self-contradictory rules to follow. I would not join a cooperative whose constitution has this clause in it (as currently written), and would strongly discourage anyone from using it for a software coops.

On trademarks and patents, I think the easiest solution is to exclude them right at the start of Clause 53

That's a good start. Then they can be addressed in their own clauses. No company can be without a trademark policy, even not-for-profit free code projects have one. Coops developing free code software, in jurisdictions where software patents are recognised, are strongly advise to have a patent policy, although you don't necessarily need one for every kind of coop.

I share offices (and work with) a law scholar on this particular issue, and three additional lawyers looked over this coop constitution last month.

Have you seen the film The Castle? Do you remember the scene where the smalltown lawyer was trying to argue constitutional law? Digital commons law is a new and highly specialized field. I strongly recommend you seek comment on clause 53 from at least one of the people I mentioned.

law professor in Australia is particularly supportive of this clause

That wouldn't be Professor Brian Fitzgerald would it? If not, he would definitely be a good person to seek comment from, and specifically mention that this "IP" clause would cover code as well as other kinds of publshed work.
https://creativecommons.org/author/brianfitzgerald/

precisely because it commits to opening up IP and ensuring public benefit from it

Don't get me wrong, the intent is great. I'm just suggesting a few patches that might encode that intent a bit more clearly.

"We're talking about the constitutions of businesses that people's livelihoods will depend on."

Yes - which is why I shared with you that I ran an IT coop for 12 years in a way that protected people's livelihoods (which I notice that you do not acknowledge). Legal agreements can be framed in ways that encourage and reward co-operative (joint) decision-making when disputes arise, rather than set out a 'follow the numbers' approach that kills both the human spirit and business relationships.

"To paraphrase Lessig, law is code". It runs exactly as it's written. If it's not written precisely, you get bugs coming back to bite you at run time."

If you think the law is like software, think again. Code is interpreted by machines that have no conception of ethics. The law is interpreted by human beings who are social, ethical and political all the time. But, if that is how you see it, I will never persuade you that it is folly to approach the law (and people) like this. It is the Weberian philosophy and perspective on law that I've spent my entire (cooperative) existence opposing.

(Lastest article opposing this kind of Weberian rationality was published in the Journal of Business Ethics this year - see https://link.springer.com/article/10.1007/s10551-018-3794-5

My 30 years of experience in cooperatives is that democracy (i.e. deliberative processes) are much better at determining when rules should be enforced and when not enforced (don't leave it to lawyers!). Democracy can be extended to clients / suppliers if your constitution allows you to extend it. It is also possible to write legal agreements that incentivise mediatory rather adversarial justice. The papers I've published on this reported research findings that people who go through mediation are much happier than those that pursue court alternatives, and are also able to preserve important relationships.
[See https://onlinelibrary.wiley.com/doi/abs/10.1111/j.1468-2338.2011.00614.x

If you really believe the Lessig quote, we'll have to agree to differ. Give whatever advice you think is right and I'll continue to give advice (and write constitutions) that take account of (social) scientific evidence.

Relax guy! I'm not attacking you, or your project. I'm giving a detailed bug report. It's a contribution to your project.

The law is interpreted by human beings who are social, ethical and political all the time

Sure, which is precisely why lawyers have a job; it's really hard to write rules that clearly communicate your intent, and will be interpreted the same way by all parties. Put it this way; if it can all just be left up to deliberative democracy, why have a constitution at all?

I have been involved in many informal organizations that work on the Bill and Ted principle; "Be excellent to each other, and party on dudes!". It works fine for many low-commitment projects (not all), but I would never try to run a business without a formal constitution. Doing everything possible to make it legally bombproof is just due diligence.

Legal agreements can be framed in ways that encourage and reward co-operative (joint) decision-making when disputes arise,

I'm all for co-operative decision-making, but copyright and trademark licensing aren't just about what the coop members can and can't do. They're also about what an entire internet of potential external contributors and re-users can and can't do.

You could fix a lot of the problems in clause 53 by replacing every instance of "IP" with "copyright" (and adding separate clauses for trademarks and patents). But even then the current wording still creates issues, even with total goodwill on all sides. For example, 53.i.b is totally incompatible with free code software development.

Let's say I do some programming for a coop using this constitution. Under clause 53, I hold the copyright (53.a), and I have to license it under a CC license (53.b), but I also have to give the coop exclusive commercial rights (53.b.i). Huh? How can I do both.

OK, I can use a CC license with a NonCommercial clause, and give the coop a separate exclusive commercial use license. But then it's not free code, because both the Free Software Definition and the Open Source Definition exclude any license that reserves any commercial rights. Also, making NC clauses compulsory totally clashes with your assessment (one I agree with) that "BY-SA ... and BY-ND all have productive roles to play in a FairShares enterprise". You see the problem?

Also, what if want to re-use an existing piece of GPL software in my coop work? If I make any improvements to that code, the license obliges me to share them under GPL, but the constitution obliges me to license them CC NonCommercial. Huh? How can I do both?

I ran an IT coop for 12 years in a way that protected people's livelihoods adoptin

Let me ask you a question though; did this IT coop produce free code software, or proprietary software? Because clause 53 looks to me like it was written with the latter in mind, and CC shoe-horned in after-the-fact with no regard to the overall coherence of the clause.

(which I notice that you do not acknowledge)

Because it's not particularly relevant to whether or not this constitutional clause is workable. Any more than it's relevant that I co-founded a CC jurisdiction project, and have been involved in CC and software advocacy for about 15 years. I don't expect you to believe me because of what I've done. I expect you to evaluate the logic of what I'm saying (or lack there-of) , and seek advice from domain experts (like those I've mentioned) who know more about this than either of us.

I am relaxed - that's why we must agree to differ. Talking about 'bugs' in contracts simply reaffirms that we see the world differently and won't reach agreement on this. That's okay - you give your advice, and I'll give mine. The conversation was fruitful and I will amend Clause 53 as a result (to exclude or reframe issues on patents and trademarks) - for that I'm grateful. So we part amicably, even if we don't see eye to eye.

@roryridleyduff1

The conversation was fruitful and I will amend Clause 53 as a result

Glad to hear it. As you redraft it, it might be worth thinking through how it would apply if a foundation/ association like Apertus transitioned to being a cooperative, operating under your proposed constitution:
"Our intention is to create affordable, free software (FOSS) and open hardware (OSHW), digital, motion picture technology for the professional production environment ... We release all of our software under the GNU General Public License V3, all our documentation under the Creative Commons License, and all hardware under the Cern Open Hardware License. "
https://www.apertus.org/mission-statement

Nadia Eghbal published a good potted history of free code development.
https://medium.com/@nayafia/we-re-in-a-brave-new-post-open-source-world-56ef46d152a3

Scroll down to the section called 'Code is not above the law' for an insight into potential problems caused by code being automatically license under CC on Stack Overflow.

Thank you for sharing!

As it turns out, there's a long running thread on Mastodon governance on the Mastodon Meta discussion board with a little bit of recent discussion: https://discourse.joinmastodon.org/t/mastodon-project-governance/215

I can't wait to be out of office to read through it!

In the wake of the ForkOff situation ( https://social.coop/web/timelines/tag/forkoff ) I believe there is no more time to waste: we should reach out to Gargron and pitch the cooperative idea to him and whoever else is now at the helm of Mastodon.

The kind of drama happening now (ie. devs ignoring specific requests put forth by some users) is the natural outcome of the benevolent dictatorship model and proves that, no matter how decent, good and caring a person is when starting a massive FOSS project, they are ALL bound to reach the "I make the rules" stage, because that's the nature of human beings when exposed to massive stress.

It's interesting as a thought experiment: how would social.coop (as it stands now) manage the forkoff situation differently?

I'm seeing a potential connection between this and the MaaS co-op conversation we had a few weeks ago. The biz model could look like instances that host with the co-op are members, with a % of the monthly hosting fee devoted to the development fund, with instances hosted elsewhere also allowed to become members by making a minimum financial contribution to the development fund (per-user fee. Each member would have one vote, and could elect a council to oversee development, with some decisions put out to a vote of the full membership.

Some questions to consider:
- How would we deal with single-user instances? Would they have equal voting power as an instance with thousands of users? Or should voting be weighted by # of instance users, so more people effected = greater governance weight? Or should voting membership be limited to instances above a certain scale?
- How collective vs. representative should the governance be?

@michelekipiel agree that this would be a good opportunity to broach the subject with Gargon (et al). Couple considerations-

1: We should have a pretty solid rough alternative to pitch that shows how it would be less head ache and more financially stable.

2: A good number of FOSS developer community that have been primary contributors to Mastodon so far should be identified and approached at the same time to gain their support.

3: Some consideration should be placed on enshrining the contributions of the "founding" developers of Mastodon both symbolically and by an ability to earn a % based royalty on the work they have done thus far and for turning over the reigns of Mastodon Prime development to a cooperative entity.

@matthewcropp to weight in on your considerations.

The most fair and manageable option might be to have representation at the Federation level to be based a number of votes for user thresholds and monetary commitments. A fairly low bar could be set on the per user contribution and my guess is that is would still be much more than what is being contributed to Masto development under current donation system.

On Representative vs Direct democratic governance the Federation Council could determine what things go up for popular (individual user) vote and what is voted on by Instance Representative. Similar to how State ballot measures are used vs State governance. My guess is that things like new Functions would be where the popular vote gets used.

Agreed on points 1, 2 and 3.

As for the representation part, I believe user count is the fairest method: 1 representative each X users. It will allow every instance to have at least one vote, while allowing the largest to be granted a reasonable number of votes. Based on a one-head-one-vote rule, each instance would elect a number of delegates to represent it in the "global assembly" at Mastodon Coop. How each instance would handle such election would not be Mastodon's problem (ie. one less thing to manage).

Delegates wouldn't act as MPs in a parlimenti, but rather as liaisons between the global assembly and their instances: instead of voting on behalf of their instance, they would be responsible of taking the matters discussed by the assembly to their users, where such matters would be put to the vote. Once the vote is cast at the instance level, the delegates would then vote accordingly ot the global level, thus expressing the direct will of their instance.

One reason to not tie representation directly X amounts fo users but have it weighted (described in comment below) is to not allow for the largest instances to gobble up the representation and crowd out the voice of smaller instances.

One factor when looking at how much direct democracy vs representative democracy to include is to keep intact the self autonomous instance aspect which seems to be a primary draw to Mastodon. The majority of the instances aren't run democratically so not sure collective governance in all decision making aspects is a good fit?

to not allow for the largest instances to gobble up the representation and crowd out the voice of smaller instances

Good point, let's elaborate on this to reach a solid proposal.

The majority of the instances aren't run democratically so not sure collective governance in all decision making aspects is a good fit

That's hardly a problem from the Mastodon Coop point of view, in my opinion. How instances self-manage is their private matter, though Mastodon Coop could lead by example and even provide some high-level guidance on how to democratize instance governance.

This is very exciting! Happy to help on a proposal.

This seems very exciting -- I have no sense how realistic it is, not knowing the players and history well enough. Two general thoughts: a) a clear and strong statement of principles is needed to orient the proposed transition (including strong language on instance autonomy) and b) we need to clearly separate money from voting rights -- i.e., you don't get more votes if you put in more money. This raises the need for an Inter-Cooperation Working Group or Cooperative Development Working Group, I think.

Yes you should not be able to buy more representation although User count alone is also not a fair marker either as User count can be gamed fairly easily. Which is why a middle ground might be to set thresholds. Something like-

Class A: 1-100 Users 1 Vote (seat/representative)
Class B: 101-1000 Users 2 Votes (seat/representatives)
Class C: 1001-5000 Users 3 Votes (seat/representatives)
Class D: 5000-20,000 Users 4 Votes (seat/representatives)
Class E: 20,001....

Overlay that with an expectation of a tiered (A:$0.50, B:$0.25, C:$0.20, D:$0.15. E:$0.10/... user count) monthly dev contribution range per instance and you would have representative system that respects smaller instances as well as larger instances at the representative level but allows for popular vote when applicable at the user wide level.

This of course would be a big departure on how Masto dev and instances function right now but this could all start with an "expected" rather than a required financial contribution to allow for a more representative/democratic process to take hold while keeping some visibility on the finical sustainability aspect to all of this.

Not sure how Developer representation would work at the Federation level. Maybe they would have be a part of separately managed Coop/Collective dev group and have certain percentage of Votes in relation to the overall Federation council like (40%)?

I like the idea of scaling the contribution according to the user count. Larger instances will end up contributing more anyways, despite lower per-user fees.

I think the max number of representatives must be capped, otherwise you are putting pressure on the greater community to make big instances.

Or even go regressive, if they get too big.

On the #forkoff, it has raised a larger question for me around whether we should have a long-term goal of maintaining our own fork that is optimized for democratically-governed fediverse instances?

I think being able to maintain the server consistently stable and running a recent version of Mastodon would be a great first step on this path.

TruFax

@matthewcropp . . . 'maintaining our own fork that is optimized for democratically-governed fediverse instances' . . . a commons to be skilfully conceptualised and curated and stewarded with rigour and determination (much labour, some kit, some ££, and not a little legal/licence stuff?).

But not (?) a means of livelihood? Perhaps yes, this too? #Mastodon does this for @Gargon? But for most stakeholders, no? Careful balancing of multi-stakeholder coop form/governance.

Totally with you on this one: if we ever get to fork our version of Mastodon (whether this is a good idea is still to be seen) it should definitely offer a livelihood to those working on it. It can't be stressed enough how important it is for the FOSS community as a whole that we make it clear that the multi-stakeholder cooperative model we''re debating here is meant to replace the current donation model and the unsteady and volatile income stream tied to it.

A terrific and significant thread this @michelekipiel thanks. Is it sufficiently complex now that it would benefit from a bit of judicious editorial forking to make it more usable for the thread-purpose? Or a contents list in the context field? . . .coupled with a few editorial comments aggregating links to sub-threads? The latter we can contribute to. The former are open only to you.

Maybe run a poll on what the sub-threads seem to be? But maybe, wait until the dust of #ForkOff is settling a bit?

@mikeh8

Is it sufficiently complex now that it would benefit from a bit of judicious editorial forking

One thing that often helps with long-running Loomio threads is for a volunteer to edit the context box at the top, to summarize the discussion so far. That way, anyone arriving in the thread for the first time can get up to speed without reading a huge wall of text ;)

Could someone do that with this thread perhaps?

In most Loomio groups I've been part of any group member can edit a context box in a thread in that group. Seems that in this thread only @michelekipiel can edit the context box. Hmm. Is this a group level setting or something you set Michele?

No idea... I don't recall changing any setting when first opening the thread. I'll double check and let you know!

This is the kind of editorial thing I generally like to do. But right now I'm up to my ears, so am not open to this helpful work on this significant thread at this time. Sad to say. Any takers?

From the POV of an outside observer from GNU Social land (only recently moved to a Mastodon instance), a lot of the current conflict in the Mastodon community seems to derive from three things;

1) As @saper pointed out in the governance thread on Discourse, some confusion about which decisions only affect Mastodon.social (the flagship instance), vs which affect Mastodon (the software/ network of instances), vs. which affect the fediverse (the meta-network of all instances of all the social apps that can inter-operate)
2) Two overlapping but different sets of design goals for the UI
3) Two very different and conflicting sets of expectations about how to govern and manage the software development process

Issue #1 could be mitigated by user education, based on clear, user-friendly documentation explaining the boundaries between each layer. Issue #2 could be solved for instances that don’t like @Gargron’s UI design choices, by swapping out the vanilla Mastodon web client for something like Pinafore or Halcyon.

But I think the deepest and most difficult problem here is #3, and this one has no technical solution, because it’s a social problem, not a technical problem. There was an attempt to solve this problem by having @maloki employed as a Community Manager, but this doesn’t seem to have solved it. I agree with Maloki that the only solution that will allow everyone to get their needs met is a fork; a new project with its own name, identity, code repo(s), documentation, and community processes.

I've posed some discussion questions for the would-be forkers here:
https://discourse.joinmastodon.org/t/mastodon-project-governance/215/41?u=strypey

the only solution that will allow everyone to get their needs met is a fork; a new project with its own name, identity, code repo(s), documentation, and community processes

Mastodon is already borderline impossible to get for the layman as it is, let's not make things worse. I'm not against specific groups forking their own version to serve their peculiar needs, I'm against spreading the idea that fragmentation is the only viable solution.

"If we consider the OECD findings on computer literacy accurate, Mastodon is inaccessible to all but maybe 25% of the population. It has a high social friction coefficient and a disturbingly exponential technical friction coefficient."
(Quote from: https://hackernoon.com/my-journey-into-mastodon-three-ish-days-of-overcoming-friction-d8d80285c23c )

I responded to this by email, but the reply seems to have got stuck in #TheClacks ;) TL;DR a) the fork is a happening whether we approve or not (eg see: https://elekk.xyz/@maloki/100184064777891255) b) I expect Gargon will be relieved to see most of these people go. c) I think this is all a distraction from building coops around hosting and improved #UX (an area where user-driven design can help a lot), but if you want to make a proposal I suspect Maloki's crew will be much more welcoming of governance input than Gagron

think this is all a distraction from building coops around hosting and improved #UX

Agreed. The UX of Mastodon as a whole (ie. everything from understanding what federation is, to picking an instance, to finding people etc...) is frankly sub-par compared to corporate social media.

This thread is getting a bit tangled to follow! @strypey says "this is all a distraction". But if this is the question of taking a stake in a Mastodon development fork, and instituting a coop to govern this, then I would say that this is very much about creating the conditions for developing the Mastodon UX, through user-driven design as Strypey advocates. And as @michelekipiel says, the Mastodon UX sure as hell does need improving!

A question to those who are more technically familiar with the app . . . do you believe that the architecture of Mastodon is open to a very much redesigned UX? Strypey has been wowed by his new UX of the Pinafore skin for Mastodon - and I do think that it is cleaner, which is a step up. But still a bit nerdy, requiring a lot of tech- and fediverse-literacy, and not very accommodating to folks like me who don't sit all day in front of a screenful of dev tools and internet feeds, but just want to 'see' a community's traffic flowing by in a filterable, attributable, trackable, searchable, non-intrusive, beautiful way. If the Mastodon architecture can be framed that way, great, let's take a stake and build a coop to build the UX.

I'm very impressed by the way that social.coop folks talk carefully and collaboratively together. And it would be great to have an app/UX that supported conversation comfortably in these kinds of considerate and diverse and diversifying and purposeful community.

Not a distraction at all then? Rather, a great gift to humankind and a great leap forward in the history of internet cooperation and literacy? If there's something clunky in the underlying architecture of Mastodon, which means it always will feel nerdy - forget it. But maybe it's the fediverse that's nerdy, in which case the solution is to develop the UX that welcomes and makes comfortable and inspires a different user community, who are not nerds (all the time! self included)? And not the undisciplined ego-blasters who trip-out in commercial social media and in the widest Mastodon public feed ;-) Am I really saying 'Build it, and they will come'? Hmmnn not sure about that. But as a designer and a cooperator, I do have faith that a lovely tool will find a community of skilful loving users.

Based on my insight as a developer who haunts the Mastodon github on and off and has several pet issues ... yes, it's very very possible to use Mastodon with presentation layer (like Pinafore, or any number of mobile apps) that isn't the same as the official mainline UI. I do probably more than 90% of my activity in the fediverse on my phone, in part because I've moved to mobile for a lot of my interaction, and in part because I don't like the mainline UI. The software is set up such that it's not that difficult to put different front ends on it.

As for the rest of the conversation... I don't think contributing to #ForkOff in the near future is a good idea for social.coop. There is a great deal of nastiness involved, and the entire thing exists as someone else said due to a social problem, not a technical one, and further, it's not a social problem that the co-op model will necessarily go a long way to solve (in my opinion anyway).

I strongly agree that the fediverse could benefit from better UX, but I think a particular UI to suit the needs of co-op modeled instances should be its own concept/project completely separate from #ForkOff.

There are two things tangled together in this thread as I see it. One is the broader issue/opportunity/potential of the applicability of the cooperative business model as an effective sustainable solution to the challenges of running successful FOSS projects. The title talks about developing a white paper as a start point to move that on, and I'd support that approach.

The second is the specific opportunity(?) presented by the current debate within the Mastodon project. I've not got involved in the guts of that debate, but it looks/looked pretty fraught, so whether there is actually a real solid opportunity there or not I don't know. I'll leave others to assess that and act accordingly.

Other possibilities/opportunities. The Drutopia project, for example (don't know it that's already been mentioned in this thread) which describes itself as a 'software cooperative', might provide a better place to learn, develop and refine the thinking?

@mikeh8 @michelekipiel
I've used a cafe metaphor to explain how I see the situation. It got long (who, me?), and I thought it might be of more general interest, so I blogged it:
https://www.coactivate.org/projects/disintermedia/blog/2018/06/12/from-digital-cages-to-cooperative-digital-cafes/

TL;DR the distraction I meant was the ongoing Mastodon drama, something I think the fork is the most likely way to resolve. Yes, I see #ForkOffTogether as on opportunity to bring coop governance to a new fediverse project, go for it. But social.coop has many software options either way.

I agree with Muninn that working on a cooperative model/concept/project for the larger Mastodon (Fediverse) in which SC resides is and should be separate from the current #ForkOff activity.

That being said I do believe that the lack of (democratic or other) representation into main line of Masto dev nor a verifiable process to air grievances by users has contributed to and exacerbated the current and past social ills of the community at large and will continue to do so in any community/fork that fails to address that.

I wish we could dis-entangle this idea - posted 3 months ago now as I write this - from #ForkOff. There are people behaving quite unpleasantly under that banner at present.

Perhaps we could make a separate thread, and send a couple representatives of our community to their meeting once they get the time set up and everything, and then discuss any potential for working with the #ForkOff folks after their initial meeting? Hopefully I'm not just adding more noise, but this thread is already pretty long, some other people were talking above about how it's hard to get into.

Hell, maybe two separate threads - a Part 2 on this one, and a ForkOff-specific thread, and lock this one?? Just throwing ideas out there to keep the discussion(s) focused..

I wish we could too. Even though it was an accelerant and maybe an opportunity to catch the attention of some dissatisfied users, admins, and devs the label is more of a distraction. possible @michelekipiel could get rid of the ForkOff language in the Proposal but I think it's now colored the thread a fair bit. Given the split of support and concerns of diversion away from things that critically need to do get done for SC alone there is a good chance this may be split off from SC activities for those like myself and Michele (or any others interested) who might want to explore deeper into a Federated Mastodon Coop model. Once there is something solid it could be resubmitted back to SC for feedback, etc.

Hi,

thanks for asking the question. I believe the "ForkOff" label in the poll is being misinterpreted a fair bit. I didn't mean it as a declaration of allegiance, so to say (ie. I'm not taking sides here), but rather as a keyword to better ground the poll in a given context (ie. the whole situation that erupted around the #ForkOff hashtag).

I am by no means willing to tie this thread to the fortunes, or lack thereof, of the ForkOff group, as the matters at hand are MUCH more important than the mere squabble of a few disgruntled users.

I'll remove the label at once to avoid further confusion.

Thank you and sorry for the inconvenience.

There are people behaving quite unpleasantly under that banner at present.

... and since this appears to be their typical modus operandi, if you read some of the Mastodon GH issues, this is precisely why I suspect Gargron will be thrilled to see them go. Sadly, a lot of their ill-mannered noise included demands for "democratic governance" (reading between the lines, systems they could more easily game to put themselves in charge of the active developers), so I suspect it will be a while before Gargron won't be re-traumatized by any proposal to democratize Mastodon dev.