FOSS cooperatives - A white paper (?)

@robertbenjamin my point exactly. There is a reason the multi-stakeholder cooperative is called that way :)

@michelekipiel

What I meant to say is I am under the impression that several developers are actively against democratic decisionmaking becuase of a poorly disguised rockstar complex.

That's what I thought you meant. I fundamentally disagree, as I tried to explain with my discussion of forking practice. My point is that that good programmers are exactly like rock stars, and this is a good thing. They know how to play their instruments, and what sound they're going for, and they're engaged in a fundamentally creative and technical practice that cannot be improved by committee style decision-making.

The music of Pearl Jam (or insert any band whose musicianship you deeply respect) would not be improved by allow their fans to democratically manage Eddie Vedder's singing, or Matt McReady's guitar solos. However, if the fans could organize themselves to create a platform cooperative for booking concert tickets, they could help both themselves and Pearl Jam break free of the Ticketmaster monopoly that screws all of them. The same is true of the record companies that manage the finances that allow Pearl Jam to record and release an album, Amanda Palmer (formerly of the Dresden Dolls) showed that crowdfunding could be used to facilitate this financing without a corporation taking the lion's share of the rights and revenue, but this too could be organized as an ongoing platform cooperative.

[forking] should be actually frowned upon and considered a waste of time and energy

It used to be, because the source code versioning tools that existed at the time made it very difficult to merge forked code back into the upstream project. Git totally transformed this. Not only is it the best way to avoid zero-sum ego battles over whose code is better, but forking is now the standard way of contributing to a free code project, which is why that banner saying "fork me on GH" is all on the homepages of so many projects.

If I want to suggest a code change to Mastodon, the first thing I do is fork the Mastodon code repo on GH, then make my changes, then do a "pull request" to invite Gargron to merge my suggested changes back into the core repo. If Gargron doesn't want to do that, I can throw my toys, or I can just use my variant of the code on my instance, as can anyone else who likes it better than Gargron's version. Unless both versions scratch distinct and mutually exclusive itches, one or the other will attract the majority of users, and eventually either Gargron will relent and marge, or I will accept the will of the crowd and abandon the extra effort of maintaining my fork. Nobody is coerced, and there is no need for a pissing contest. It's "rough consensus and running code".

To return to the musical analogy, if Stone Gossard writes some songs that the rest of Pearl Jam don't want to play as PJ songs, he can fork Pearl Jam, by creating a side band (Brad) to play these songs. If Curt Cobain hadn't died, Dave Groehl would probably still have formed Foo Fighters, because Curt didn't think Dave's songs were suitable for the Nirvana aesthetic, but Dave could have continued drumming for Nirvana too. Like forking in free code development, none of these things are mutually exclusive.

Benevolent dictators are only benevolent as long as they please, not one second longer.

Sure. Your point? As soon as they stop being benevolent, people can take a copy of the code and vote with their feet. Again, the examples of LibreOffice and NextCloud show that this is effective. Linus Torvalds' protohuman interpersonal skills (calling people "morons" on official mailing lists etc) are tolerated only because he is the most technically competent person in Linux kernel development. The day ... no, the hour that stops being the case, the rest of the developers can start working on one or more forks, and GNU-Linux distros can choose a fork to start using instead of Linux. Linus would continue to be the king of Linux, but he would rule a kingdom of one.

Here's a hypothetical example from the music world (I don't know the real story here, I'm totally guessing). Let's say Zack de la Rocha blocked consensus on playing a bunch of songs the other three members liked as Rage Against the Machine songs. So the rest of the members got Chris Cornell to sing them, and released them as Audioslave.

Zack got to protect his vision of the RatM aesthetic, but at the cost of getting sidelined for the next decade or so. However, when RatM reformed, their fans remembered them for albums like Evil Empire and Battle for Los Angeles, not the radio-friendly unit shifters Audioslave put out. In this instance, Zack's benevolent dictatorship didn't stop the rest of the band from making the music they wanted to make, but it did prevent the musical impact of RatM being watered down as a consequence.

Just think of the disaster that was the witches.town shutdown...

What about it? All their former users can just move to another instance, or set up their own. Yes, they have to re-establish all their follower/ followee relationships on their new account, but that's not a problem caused by the governance style of witches.town, it's a missing feature in fediverse software in general. It's a problem that Gargron and co are all working on, and when it's solved, users who don't like the governance decisions on their host instance get easily vote with their feet. Instances whose admins drift towards despotism will quickly find themselves nations of one.

As it happens, it's a problem Mike from Hubzilla already solved with Zot, it's just a shame the W3C Social WG refused to use this work in ActivityPub. But again, Zot exists, and AP exists, and developers can decide which standard to implement in their software, and users can decide (by their choice of software) which standard will have the most users. What cooperatives can do is help large groups of users make those decisions together, in an informed way. Thus funneling attention and funding to the projects that provide the best solutions to technical problems, rather than just to the ones with the best marketing departments (which is how we ended up with the FarceBooks and birdsites in the first place).

I don't agree 100% with the music analogy, as music is art, to which the maxim "Ars gratia artis" applies, whereas code (or at least code serving a true purpose) is not. This said, let's see where this goes.

The music of Pearl Jam (or insert any band whose musicianship you deeply respect) would not be improved by allow their fans to democratically manage Eddie Vedder's singing, or Matt McReady's guitar solos.

I might have expressed myself poorly, but this is precisely what I said in my previous reply, when I wrote "Developers would then have to agree among themselves what is the best way to achieve the goal defined by the users". Nobody except the core members of Pearl Jam (ie. the core developers, in my example) can say anything about the way PJ are supposed to sound. The only difference here is, as I pointed out in the first paragraph, that music is art and PJ were free to do whatever they wanted, while a codebase serving actual user needs has to follow... well, user needs. I hope this makes it clear.

only because he is the most technically competent person in Linux kernel development. The day ... no, the hour that stops being the case, the rest of the developers can start working on one or more forks

A fantastic way to waste millions of man-hours on narrow pet-projects, led by pet-benevolent dictators. Hardly a positive outcome, in my opinion, but let's agree to disagree.

All their former users can just move to another instance, or set up their own. Yes, they have to re-establish all their follower/ followee relationships on their new account, but that's not a problem caused by the governance style of witches.town, it's a missing feature in fediverse software in general.

You seem to dismiss the incredible amount of effort it takes to remember all of one's followers/following handles by heart, not to mention the emotional labor needed to recover those after seeing 1 year's worth of social interactions being wiped out overnight. Also, the missing feature argument is invalid, because even if exporting a graph was a one-click feature (which is not), users can hardly export anything, once the platform that holds their social graphs is shut down without any notice.

One more thing, that might put some of my previous comments in a more helpful context ...

@robertbenjamin

This way you can have the entire pipeline be owned by the cooperative

Can you? Isn't that what Microsoft tried to do (Windows, Internet Exploiter, Office365, Azure Cloud etc)? Isn't it more democratic to leave each team in the pipeline to be autonomous (self-owning and self-governing)? Isn't the ability to choose which teams to include in their own pipeline one of the things that make GNU-Linux distributions more democratic?

In theory, each team is its own worker-owned collective, and whether they structure themselves as an informal affinity group, a non-profit association, a cooperative company etc will depend on their size, age, shared goals etc. To me that seems totally compatible with constituting user interface organisations like distributions and hosted platforms as user-owned cooperatives.

(BTW just started reading 'Ours to Hack and Own'. Maybe I might meet some of you F2F in London in July?)

Nor sure they are mutually exclusive. Kind of like Nike has their own marketing and development teams but also uses outside agencies when it's a better fit.

From let's say a platform like social.coop's perspective I'm more saying that we could have our in-house development team(s) which are either run democratically or managed in a more classically hierarchal way but that have democratic/representation at the overall cooperative.

It's really about what way would most effectively and efficiently maintain continuously improving coverage.

But like you said we can also effectively steer development in the marketplace by creating a large enough pool of resources and using outside "agencies" that align with our needs and standards.

Nor sure they are mutually exclusive

Sure. User-owned coops will certainly want to employ some teams of in-house developers, especially if we define "developer" loosely to include not just back-end engineers, systems architects, and protocol designers, but also the people working on interface design, UX, graphics, and so on,. My only point is that this will never be owning "the entire pipeline". Even FB and the birdsite don't try to do that, everything is just too interdependent for that now (that's why they try to "own" users instead). To return to my musical analogy, although you might want to have a house band, it's not necessary (not really even possible) to own all bands you'd want to play at a music venue cooperative owned by the music fans who go there.

either run democratically or managed in a more classically hierarchal way

I'm confused by this. I'm not aware of any significant free code projects that are run in a "classically hierarchal way". Can you give me some examples?

If you mean the "benevolent developer", this is a quality control role, not a comand-and-control one. The title is a hacker in-joke like St IGNUcious, riffing on the fact that this person - often a volunteer - has to take more responsibility for the quality of the software that anyone else involved. While still having absolutely no top-down control over how developers spend their time working on it, or whether the canonical version they control commit access to will be the one people choose to keep using (rather than a fork or distribution that does things differently).

Only Bowie could release Bowie albums, but he couldn't control the writing process of the people writing songs for him (only decide whether their songs would become Bowie songs or not), or control whether people listened to his versions, or psy-trance remixes, or pan flute covers. Bowie was the "benevolent dictator" of albums by Bowie, and clearly a lot of people like how he did the job.

If you mean teams working on self-contained programs inside a single corporation, especially those whose managers go all-in on the Agile(TM) Scrum cargo-cult, then yes, some of these are quite hierarchical. Given the chance, such teams might be keen to take the free code they're working on, vote with their feet, and decamp to a cooperative owned and run by their end users. But this is the classical hierarchy of corporations, not open source, and is a rare exception to how most free code development works, even when corporations pay programmers to work on it.

Thinking more along the line of project managers, timelines, and a more formalized quality control and Remuneration system I suppose but I'm not from the FOSS development world. I'm thinking of it more from point of view of say a platform who wanted some kind of specific tool developed.

I'm not from the FOSS development world

I'm kind of the opposite. I'm familiar with the general theory of coops, and (tried and failed) to start an IT coop once, but I've had a lot more to do with the free code world than the cooperative business world. There will be a lot of myth-busting to be done on both sides as we bring the two together more ;)

There will be a lot of myth-busting to be done on both sides as we bring the two together more

This is very much the point of this thread, and I'm glad to see it is drawing a lot of attention!

Wow, an evolutionary design is super sexy! :)

Crucial is decision-making. Ya'all been working this hard from what I can tell.

"The idea of having what the developers might see as relatively 'passive' users of the software that they built having the same level of decision-making influence and power as they had was anathema to their world view. that was maybe 15 years ago."

Seems related to the so-called free rider problem, too.

@michelekipiel @strypey
As it seems like you two are actually agreeing on 80% of it, how about this for a for thought experiment?
1: Whether there is agreement on the auteur developer mentality there is probably consensus that software development benefits from some degree of centralized visionary leadership (shepherding) and doesn't fair as well if run fully by large committee.
2: The best software isn't developed in a vacuum but rather as an evolving organism that routinely takes into account feedback and demand signals from users and organizations.
3: Cooperative ownership could provide a needed degree of stability and contributor equity to the development process and can be segmented to balance the different interests of connected and reliant elements.
4: As forking seems to be a common and valid way to continue and extend FOSS development projects beyond their "benevolent controllers" why not form a Mastodon multi-stakeholder cooperative that takes over development of Mastodon (V.X) fork which gets its User demand signals from Instances that choose to become federated members?
5: As members, Instances would have input on what tools were developed but not at a granular level. In exchange they would provide easy to understand and reliable reoccurring donations (based on user thresholds) that would be used to attract and engage the best and brightest developers.
6: Social.coop could actually take the lead on this simply by creating a voluntary contributed pool of Mastodon development resources to get the fork started and then overtime help other federated Instance members cooperative themselves if it was good organizational fit.

This basically anticipates where I was planning to direct the above discussion!
I find all 6 points absolutely valid, though I'm not sure forking Mastodon is a necessary step in order to develop it into a cooperative. Besides the risk of fragmenting the codebase, we might incur in the even worse risk of becoming a minor version with zero attractivness for the brightest talent. If I were to make the call, I'd rather try and introduce the idea to gargron and those working with him as a way to ensure the best possible survival chances for the project. It might seem a lofty goal, at a glance, but if the guys at Mondragon can run a multi-million € network of cooperatives, why can't we? :)

PS. For those reading "Ours to Hack and to Own", chapter 28 of the book is basically an intro to what we're trying to achieve in this discussion.

I agree presenting a cooperative structure to Gargron first is definitely a better option. In fact the 1st step should be to speak through regular re-occurring support contributions from a Social.Coop Mastodon development fund (being discussed as part of an overall budget discussion in Finance working group) that shows the cooperative potential.

Agreed! There's no better way than to lead by example. Let's focus on that Mastodon development fund and see where that leads us. In the meantime, let's keep this thread alive with links, news, updates and comments. I believe there's a lot we can achieve by pooling all our competences and resources!

Open source and cooperative business can be combined through application of the FairShares Model - www.anyshare.coop has done this by adapting a FairShares Company constitution to register a business that has been awarded the .coop marque. However, they varied the clause covering
members IP and this was tigthened up is FairShares V3.0.

You can generate FairShares constitutions for registration as companies, cooperatives, associations and partnerships containing this clause (53) by using the FairShares Rules Generator accessed at http://www.fairshares.coop/ownership/

Next week, we send revisions to the FCA for a specific UK option for ‘FCA Accepted Model Rules for a FairShares Cooperative. It must be registered in the UK but can cover EU ventures too. This contains clause 53 (all submitted revisions are based on FCA legal advice).

Sounds good in general, and IANAL, but here are a few points on clause 53 as it pertains to free code, free culture, peer production, and related issues from an activist POV:

• "Intellectual property" isn't a thing. See:
  https://www.gnu.org/philosophy/not-ipr.en.html

• this isn’t just splitting hairs about preferred wording. As Stallman’s essay explains, the key point is that the areas of law that get included under the “IP” umbrella (copyright, patents, trademarks, and so on) have totally different purposes and work very differently. Clauses that work if you're talking about one don't always apply the same way to the others, and some of the points below are examples of this.

• specifying that creators get to keep ownership of their own work is cool when it come to copyright, as its a strong protection against proprietary relicensing, but is usually inappropriate for trademarks. If I am paid to design a logo for the cooperative, it's not really appropriate for that logo to be owned by me as a private trademark, and licensed to the cooperative. Software patents are a misuse of patent law, and in some countries (like Aotearoa/ NZ) software is not covered by patent law “as such” (only as an embedded part of a hardware invention). Neither the company nor the creator of software should ever apply for software patents nor recognise their validity (see the short film ‘Patent Absurdity’).

• I’m an enthusiastic support of CC licenses (I helped start CC Aotearoa/ NZ), but:

  • they are copyright licenses, and they only apply to things subject to copyright law. Although you could apply a CC license to a logo, not only does that not confer trademark protection, it actively breaks it (every CC license permits all verbatim re-use). You can’t apply CC to other kinds of trademark like generic words used as a brand name, and if you could, it would break them as well. You can’t apply CC licenses to patents. Publishing a detailed description of an invention creates “prior art”, thus making it a sort of “open patent”, but this puts the invention in the public domain, with no ability to stop anyone from doing anything with it (except patenting it).
  • CC licenses are not the only commons licenses (others include the Free Art License, the Peer Production License, and all the free code licenses), and each CC license does a different combinations of things (even more so if you include CC0 and the CC Public Domain Dedication). Rather than specify that people apply CC to every copyrightable thing they create at work, it’s probably better to think about what you want the license to allow and forbid, for each kind of work, and let the creator choose a specific one (or a subset) that does that.
  • only the subset of CC licenses that are “free culture” licenses (see: https://creativecommons.org/choose/), are appropriate for licensing any work to be included in a free code project, and CC themselves say their licenses are not appropriate for source code, and that an FSF or OSI approved free code license should be used instead for code.

• In order for 53.a and 53.b. to work, the CC license chosen can’t include a NonCommercial clause. But this is directly contradicted by the point in 53.b.i about the company having “exclusive right to use and commercialize the IP”, in fact, using a CC license at all directly contradicts that aspect of 53.b.i. That clause is certainly incompatible with a free code license of any kind. None of this makes any sense when applied to patents or trademarks.

• You can give ownership of copyright to a work to both the creator(s) [53.a] and the company [53.b.i], but what’s the point? Especially when the copyright is being released through a CC or free code license allowing commercial re-use, and anybody can use it for anything anyway? Why not just decide whether it makes more sense for the creator or the company to defend the conditions of the copyright license and make them the nominal copyright owner? Again, none of this makes any sense when applied to patents or trademarks.

• The purpose of 53.c is unclear. For a copyright, patent, or a trademark to be “owned collectively” implies that is held in trust by the company, as the agent of the current members, which would happen automatically when the copyright is assigned to or bought by the company.

• Or is 53.c saying that when a copyright is assigned to or bought by the company, each person who is a member at the time becomes a co-owner with the company? If so, what happens when a new member joins? Do they also become a co-owner of all copyrights held by the company? What happens if a member resign their membership, do they remain a co-owner? If not, it’s a bit meaningless. If so, how does this ever-growing crowd of legacy co-owners make decisions about uses of the copyright not covered by the CC or free code license it’s under, or legal action to defend that license?

• all the same questions apply to 53.c when it applies to patents.

• 53.c makes no sense when applied to trademarks.

• 53.d contradicts 53.c. If you’re going to manage “IP” as an “‘intellectual commons’ for the benefit of company members”, why restrict “IP” assigned to the company or bought from third parties to “non-commercial use and private study”? In copyright law these are pretty much just their Fair Use/ Fair Dealing rights in most jurisdictions anyway. Patent law doesn’t restrict either of these activities anyway. How would anyone use a trademark for non-commercial user or private study anyway?

• 53.e this is the only clause whose meaning doesn’t have a hole big enough to drive a truck through. But free code projects often delegate this work to specialist organisations like the Free Software Foundation, Software Freedom Law Centre, Software Freedom Conservancy, or Software in the Public Interest. Unless your cooperative is a legal firm, or has a dedicated legal department, I’m not sure offering to take on complicated legal work for all comers really engages with how complex and contentious defending copyleft or other aspects of commons licenses can become. For example:
  https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003580.html

If the version in that image is the “tightened up” version, and they paid a lawyer to review it, then IMHO they deserve a full refund. This clause opens up multiple cans of works and need significant refactoring to be a useful guide, let alone a legal agreement.

Thanks for the comments - I’ll work with law scholars to see if any changes are needed. A few clarifications.

1. You ignore the emphasis on voluntary transfer of IP. If a member creates a logo, they can voluntarily transfer ownership of that IP under Clause 53, so the trademark issue is moot. Alternatively, commission the IP from a third party in which case ownership is help collectively (not jointly as you imply).

2. Agree with the attitude to patents - these clauses are designed to break the idea of patents.

3. Power rests with the member to choose the licence. In practice, BY-SA, BY-NC-SA and BY-ND all have productive roles to play in a FairShares enterprise.

4. Unilateral powers to enforce CC licences are needed to cover what might happen after a member leaves (to stop privatisation).

As I said, I'm an activist, not a lawyer, and this is not legal advice, just suggestions based on my reading and experience. I suggest consulting people like Lawrence Lessig, Eben Moglen, Karen Sandler, or Richard Fontana, all of whom are qualified in law, and have extensive experience in the field of commons-orientated copyright licensing, and trademark and patent issues as they relate to peer production projects.

1. Who owns the trademark is not the major problem here. It's that applying a permissive CC license to a trademark work (where it's even possible), as required by 53a and 53b, negates its value as a trademark (I explained why above). Clause 53 needs subclauses that deal specifically with trademark issues separately from copyright (or patents). See:
   http://www.softwarefreedom.org/resources/2008/foss-primer.html#x1-600005
   http://fossmarks.org/

2. How? Patents work completely differently from copyrights (or trademarks), for the reasons I offered above, and others. Sometimes patents may be appropriate to temporarily protect new commons against enclosure by highly-capitalized corporations. Other time, they may be totally unethical (IMHO neither software nor drug patents are necessary or justified, ever). Clause 53 needs subclauses that deal specifically with patent issues separately from copyright (or trademarks). See:
   http://www.softwarefreedom.org/resources/2008/foss-primer.html#x1-390004

3. So why limit their choice to only CC licenses? At the very minimum, for this constitution to work for cooperatives working on free code software, clause 53 needs to allow members creating software at work to use a license approved by the FSF and/or OSI:
   https://creativecommons.org/faq/#can-i-apply-a-creative-commons-license-to-software
   http://oss-watch.ac.uk/resources/cclicensing

4. Once a CC license (or any other commons license) has been publicly issued, it can't be revoked, and anyone can use the work under any license the copyright holder has issued at any time. However, the copyright holder can issue new licenses on the same work with different conditions (eg issue a commercial license on a work covered by CC BY-NC-SA, or allow a company to opt-out of the copyleft clause of GPL for a fee). Is 53.b.1 meant to prevent this? If so, wouldn't it be simpler just to make it a joint copyright between the company and the creator, right from the time copyright applies (when the work is "published")? That would make all of 53b unnecessary, as permission from all joint copyright holders is required to engage in any kind of proprietary relicensing, "exception sellng", or exclusive commecial licensing.

I want to make it clear that despite my niggles about the details, I think it's a fantastic idea to offer open source constitutions (so to speak) that groups can adapt and use to reduce the barriers to forming new cooperatives. It's precisely because I see the immense value in it that I want to make sure it is applicable to free code software cooperatives. The constitution for Loomio Ltd. (the cooperative company that develops Loomio and hosts this service) might be useful for comparison:
https://loomio.coop/constitution.html

You over complicate this, I think, and also place too little trust in people and cooperation. On trademarks and patents, I think the easiest solution is to exclude them right at the start of Clause 53. But even if you do not, I’ve only ever known logos to be commissioned so they are covered by the third party provisions.

I was director of a worker coop (an IT company) for 12 years before going into academia (where I have been for the last 15 years). The best use of the law and contracts is to write in powers for both parties that prevent either ever going to court (or even threatening it). For the software projects I negotiated, we wrote in rights for both supplier and customer to be able to amend code supplied for their own purposes. In 12 years, we never got into a legal dispute with any client about IP for any reason.

I share offices (and work with) a law scholar on this particular issue, and three additional lawyers looked over this coop constitution last month. Lastly, law professor in Australia is particularly supportive of this clause precisely because it commits to opening up IP and ensuring public benefit from it (bearing in mind it covers more than code) I’m a professor of cooperative social entrepreneurship, not law, but my expertise is in crafting governance systems that forge cooperation, not competition.

My law scholar colleagues do not share your concerns, but I will alert them.

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.