Finally got around to making some diagrams and writing out explanations. Hopefully this helps create some more “aha!” moments around the concept of XLC.
This is absolutely brilliant! Taking the p2p concepts and applying them to licensing. I have a gut feeling that this framework is going to be THE foundation for a new wave of licenses. In a way I find this approach much more desirable for cooperatives than https://lynnesbian.space/csl/formatted/. Rather than just picking a license that says
+ Use freely as long as you are You are a worker-owned business or worker-owned collective
The licensing model somewhat mirrors the cooperative’s governance of people coming together to create value together. Few questions that I have are. Cooperatives tend to have various bylaws and governance structures for voting. Some elect leaders that make decisions while others let all workers vote on decisions directly. How does that such license framework coincide with those governance arrangements? Separately, are there any guided instructions you could point to that describe practically how to setup a cross-license arrangement and how to manage such framework going forward? Written in practical terms for engineers starting new projects on github for example.
Furthermore, how would such license overlap with other creatives that might belong to a cooperative but that are not directly source code contributors? I find that often developers overlook the need for various other professions involved in a successful project. Product, design, business, legal, etc. Such collaborators might now strictly be commit or merging code. Does that mean that they are part of the license collaborator network for the specific project? Or would the cooperative then have to for them to commit something trivial to ensure their identities are linked to the project history.
Furthermore, I have contributed to open source projects in the past that after growing large would split the development into smaller sub-projects. When such process is done, the commit history for these sub-derivatives would not include the contributors of the original larger work. I guess that is just a technicality that can be follow up on from the main “trunk” project?!
Obviously most of my comments are geared towards implementing this strictly via a cooperative while the framework itself is much more abstract.
Governance-wise, XLC implements something close to a direct democracy of admitted members. You can think of it a bit like the board of directors of a company or co-op where all the “property” the company can own is licenses for contributions to the project, and all the “powers” the company has are to sublicense those rights and handle its own governance. Voting rights, rights to information, and rights to compensation are all equal.
Please understand that while a cross license collaborative has some very co-op like elements, like the governance structure, it’s not an actual co-op. In fact, it’s not any kind of legal or business organization at all. Just a kind of network of person-to-person licensing relationships.
There aren’t yet. It’s definitely on my list.
The crux of it boils down to treating the XLC Agreement a lot like a CLA, except existing contributors have to vote to offer new contributors membership when they offer contributions.
Some collaboratives may also want to take one-off or drive-by contributions from people who won’t become full contributor-members. In those cases, you ask for rights to the contributions under a permissive license, like the Blue Oak Model License.
To get voted in as a contributor, you have to offer some contribution covered by IP that can be licensed. That will usually mean copyrightable work, though that need not necessarily be software.
If the collaborative is going to sell any kind of license, they might cut a deal providing a royalty or other compensation to folks who aren’t contributor-members.
To be quite frank, I haven’t given much thought to projects splitting and merging. In most cases, I suspect those will come through as questions about the public license terms for the project. If a collaborative makes a project available under MIT, for example, everyone can fork and patch and so on, just as they would other MIT-licensed software. When pay is involved, say because a collaborative has chosen a restricted license and sells exceptions, it be more complicated. There’s no built-in mechanism for splitting or combining collaboratives.
XLC implements a very egalitarian, co-op-inspired governance model, because that’s what I want to see and support, and that’s what I thought many folks who might try it would like. I also think it’s among the more intuitive governance models.
That said, the same cross-licensing mechanism could be used to implement other models, including models we probably don’t find so exciting.
I’m aware of some open source projects that used CLAs, but had people sign them for the benefit of the maintainer, rather than a company or foundation. Last I checked, CLAs for Clojure give licenses to Rich Hickey, for example.
Successful teams often continue on building multiple projects together. For example when implementing a series of RFC standards or W3C standards they various stacks require many different implementations. I find it very common that a group of people that collaborate on one sub-project end up collaborating on another simply because those technologies are very related.
I am actually imagining that to be exactly that but where the projects co-exist in parallel with the coop organizational bylaws and other documents. Imagine it almost like a https://commonsclause.com/ infused with an XLC. Thus when a project is ran by a coop a contributor has to sign one such document just like a CLA effectively relegating his/her contributions to the management by the cooperative. The cooperative is then responsible for managing the licenses and if those are done for profits, the cooperative pays back to the contributors as part of the XLC. The incentive a contributor gets is that by relegating their contributors, there is like more chances that the contribution would be capitalized on financially. But because it is an XLC the contributor still gets some financial gain in return. A cooperative in such a scenario is like a worker-owned governance layer.
This also simplifies the sort of “distributed hiring” process. I mean as a contributor I can just go around looking for projects to contribute to. When I find cool projects worth my effort, I can spend time helping build it out. If I want to be apart of the governance of such project, I can apply to the cooperative. Otherwise I can think twice whether to contribute to them or not. If said cooperative has bad reputation of shabby governance then this would indicate that the project may not have the healthiest community for people to invest their time.
I see this a lot where there is a really cool project but is managed by a complete asshole who doesn’t do good job actually governing the project but such project may be a critical utility for a corporate client. Say a library or a embedded database.
Such royalties would probably have to be on the coop’s responsibility place.
This is absolutely phenomenal info-graphic.
There’s no rule against belonging to multiple collaboratives!
This was theoretically how crypto was supposed to work but really doesn’t.
I’ve been enjoying introducing people to XLC and can’t wait for more open source projects to try it out.
Great statement. Very much agreed.
Putting myself in the postion of a prospective adopter of XLC. Let’s say I’m a recent CompSci undergrad fed up with working for Raytheon and me and my cohorts want to do some good in the world, like build some educational software … what would draw me to XLC compared to say, grabbing a DCO, or maybe building a form like the Software Freedom Conservancy style CLA and set up a new tech coop, or maybe just joining an existing tech coop and then implementing a DCO protocol, or some such? TVM.
Probably because CLA style agreement are extra managerial work. Most out there in the wild just want a drop-in and start coding kind of agreement. Is there a way to rework XLC into an LICENSE.md kind of setup? The only major impediment that I see is that XLC bundles the economics and the politics within the same document by requiring someone to submit their payment method. But that is actually not in line of how cooperative governance works. Coops explicitly separate financial incentives and distribution from decision making. It is not to say that it is not egalitarian (or not) just that they are separate.
Unfortunately I feel like this is a 1920s` Russian idealistic few. Obviously we all know how that ended. Russian and Chinese Communism. Reading through modern cooperative ideas, is far less idealistic. I feel like this modern social movement is far more rooted at existential practicality. Asking the question: “How do we achieve what we want despite the competition?” By “competition” I primary reference the fact that both the far left and the far right have been greatly concentrating wealth. Whether it is Xi, any of the Russian oligarchs, or the American indastro-entrepreneurs the outcome is the same. Most of the wealth is concentrated in those few hands.
Anyhow, this is not a criticism of anyone’s views. I am an idealist and deep down at heart wish the same. But as I grow up and keep struggling through capitalism I make practical concessions.
Here is an interesting document that explains coop governance structures. This is provided by the US Federation of Worker Cooperatives.
I feel like this what my past self wanted / thought about open source licenses — whether GPL or MIT — 15-20 years ago.
I don’t know think a DCO (Developer Certificate of Origin) is a widely familiar term (I had to search for it to be reminded), nor is a CLA (Contributor License Agreement). The latter is familiar as a term but makes me think of complexity.
I think the attraction is that no entity is required. Just like Open Collective provides a bank account and accounting without needing to set up an organization, XLC is a handshake on how to work together?
And you probably want an OpenCollective to go with an XLC.
I’m not sure how those two would work together. The XLC would only cover payments to do with licensing, not gratuitous payments or payments for other perks, like advertising.
The same mechanism underlying XLC could be used to create something more like a “distributed foundation”, where the group can change the public license for the project, but not grant or sell other licenses.
Open Collective being a way to accept funds without one person or organization having tax exposure by accepting them on behalf of the XLC.
i.e. sell private licenses through OC and distribute funds through there with transparent budgeting.
I don’t know what to say about other payments other than my assumption would be to just split funds the same way based on contributorship status.
Ever since I have discovered XLC I have been imagining exactly that with the exception of instead of open collective people would form cooperatives with their own unique governance/finance structures. That is simply because not every project has the same business models behind them. A database (infrastructure) project relies on enterprise features and technical consulting whereas a project like resonate (coop alternative to spotify) relies on subscription fees and music creator compensation.
An “open core” concern could form an XLC around the “closed shell” of enterprise or other paid features, then delegate sales to a company, with a royalty.
An XLC for the code could license, say, a consultancy or hosting company, with a royalty.
You need some point at which somebody making needs a license. If your collaborative chooses a broad enough free, public license for the project, that may not be the case.
What you seem to be saying is that Russian (communist) ideology (e.g. Lenin/Trotsky?) gave rise to Xi and Putin?
Are you suggesting Xi is ‘far-left’? Where are you seeing the far left accumulating captal? I am only asking because I would love a slice of that action!
I have never been able to find a well funded far-left organization, anywhere!