Cross License Foundations

After prompting from a few folks, I’ve gone ahead and taken first draft of a pared-down version of the Cross License Collaborative idea that omits any mechanism for payments and functions only to relicense the project over time. Here it is.

Cross License Foundation Agreement

Development Draft


These terms enable contributors working together on a project covered by copyrights or patents to make collective decisions about changing the license terms for their project over time.


In order to get any license under these terms, you must apply to become a contributor, be accepted, and agree to these terms. These terms are both obligations under an agreement among all contributors and conditions to all the cross licenses they give and receive under that agreement.



Only candidates offering contributions of copyrights or patent rights to the project can apply to become contributors.


To apply to become a contributor, a candidate must send the following to an existing contributor:

  1. their address for communication

  2. a World Wide Web or other Internet address where contributors can review the first contribution they are offering

  3. copies of, or World Wide Web links to, the terms of this agreement and the current statements of license criteria and communication system


For a candidate to become a contributor, an existing contributor must follow each of these steps, one after another, in order:

  1. circulate the candidate’s complete application

  2. secure majority approval in favor of their application

  3. circulate a current list of all contributor addresses, including the new contributor’s


Any contributor may resign at any time by circulating a message of resignation. When a contributor resigns, all cross licenses to that contributor end, but their cross licenses to other contributors, as well as any sublicenses they have given for relicensing, continue.

Cross Licenses


Each contributor gives a cross license covering all copyrights in their contributions to the project to each other contributor.


Each contributor gives a cross license for the project covering any patent claims they can license or become able to license to each other contributor.


Each cross license under these terms covers all contributors, past, present, and future, and all contributions submitted to the project, past, present, and future.


Cross licenses under these terms do not give contributors themselves any special permission for the project, only permission to relicense.


Any contributor may relicense the project as a whole by granting a sublicense under new terms meeting any license criteria in effect at the time within thirty calendar days of securing majority approval. When soliciting votes for relicensing, a contributor must circulate:

  1. identification of the contributor proposing to relicense the project

  2. an exact copy of the new license terms

  3. an exact copy of all the terms of any agreement that has, will, or could compensate the contributor for proposing or securing approval of the relicensing

License Criteria

The first two contributors must agree on any criteria for terms on which the project can be relicensed. They must publish a dated statement of those criteria, or a dated statement that there are no criteria, together with the terms of this agreement, where potential contributors can find and read them. No contributor can relicense the project onto new terms that fail to meet the license criteria. Any contributor may change the license criteria by securing supermajority approval in favor of the change.


Equal Information

Each contributor is entitled to receive each message sent to any other contributor under these terms.

Circulating Messages

To circulate a message under these terms, a contributor must send the message in the English language to each other contributor, retrying as necessary.

Circulating Notices

Any contributor who receives a notice under the terms of a relicensing must circulate that notice, retrying as necessary.


The first two contributors must agree on a global, free or low-cost, high-speed, electronic communication system, such as e-mail, and provide addresses for that system. They must publish dated statement of that choice, together with the terms of this agreement, where potential contributors can find and read them. Later contributors must provide addresses for the same system.

Change of Address

Any contributor may change their address by circulating their new address from their current address. Alternatively, any contributor may change their address by circulating their new address from a different address and securing supermajority approval, without any opposing message from their old address.


Equal Vote

Each contributor is entitled to cast a single, equal vote on each proposal under these terms.


For majority approval, a majority of responding contributors must vote in favor.


For supermajority approval, two thirds of responding contributors must vote in favor.


The contributor soliciting approval counts as a contributor voting in favor.


The deadline for approval of any proposal is thirty calendar days from when votes were first solicited.

Securing Approval

To secure an approval, a contributor must solicit votes, then tally votes, and finally report the result.

Soliciting Votes

To solicit votes, a contributor must circulate a single message with all of these details:

  1. the identity of the project

  2. the complete text of the proposal

  3. the voting standard required

  4. the date of the deadline

Casting Votes

Contributors may vote by replying to a message soliciting votes using the same communication system. Messages like “I approve.”, “I vote in favor.”, and “Aye” count as votes in favor. Messages like “I oppose.”, “I vote against.”, and “Nay” count as votes against.

Tallying Votes

To tally votes, the contributor who solicited votes must ensure that each vote message is circulated. If the communication system enables forwarding messages verbatim, such as by forwarding e-mail, the contributor must forward vote messages verbatim. If a voting contributor circulates their vote themself, the contributor soliciting votes need not circulate it again.

Reporting Results

To report a result, the contributor who solicited votes must circulate a single message with all of these details within seven calendar days after the deadline:

  1. all the information required to solicit votes

  2. copies of all vote messages

  3. counts of votes in favor, votes against, and contributors not responding by the deadline

  4. whether contributors approved the proposal or not


When a communication system fails to deliver a message:

  1. The sending contributor must circulate word of the failure and any failure message from the system.

  2. The sending contributor must wait forty-eight hours, then try again. If the receiving contributor changed their address since the first try, the sending contributor must use the new address.

  3. If the second try also fails, the sending contributor must circulate word of the failure and any failure message from the system. The receiving contributor is then considered to be not responding.

Broken Rules

If any contributor unintentionally breaks a rule of these terms at the expense of another contributor, and the contributor who was wronged circulates a message about the breach, other contributors can keep their cross licenses from the contributor who was wronged if any one or more of them makes the situation right within fourteen calendar days. If the contributor did not get an equal vote, contributors must retake the vote. If the contributor did not get equal information, contributors must circulate the message again, and if any vote was taken between when the message was not sent and when the contributor finally received it, contributors must retake that vote.


Any contributor may change these terms by securing supermajority approval in favor of the change. Changes apply from the time of approval going forward, not retroactively.

No Liability

As far as the law allows, the project comes as is, without any warranty or condition, and no contributor will be liable to any other contributor for any damages related to the use or quality of the project, under any kind of legal claim.

There’s also a worksheet for the first two contributors to fill out. They get to choose the communication method—probably e-mail—as well as any initial rules about how the project can be relicensed.

Cross License Foundation Founders’ Worksheet

Development Draft

Last Updated: {date}


Founders of new cross license foundations should fill out and date this worksheet, then publish it, along with the Cross License Foundation Agreement, where potential contributors can find and read them.

Communication System

What system will contributors use to communicate? The system must be global, free or low-cost, high-speed, and electronic. In the vast majority of cases, this should be “e-mail”.

License Criteria

What criteria must new license terms for the project meet? For example:

The new license terms must grant licenses to the public as a whole, or to anyone who receives a copy of the project.

The new license must be completely free of any license fee, royalty, or other charge.

The new license must be a new version of {specific license} published by {license steward} or its legal successor.

The new license must appear on the {list} published by {organization} or its legal successor.


First impression is a slightly pessimistic one… it is about as comprehensive as incorporating as a company, but I am not sure if the ‘no liability’ clause would be as robust as the ‘limited liability’ of incorporating? Also, the power of this foundation is very tightly scoped which may stifle diversification options in the startup/juvenile phases? Lets say the project codebase isn’t successful but the brand concept or some aspect of a patent attracts a lot of attention… that may inhibit spinoffs in a way another business format could integrate better? Second impression is ‘it might just work’. It needs testing out. A real life case study would be great.

This is essentially a Licensing Foundation? So it defines how one can work with a group to adapt licensing?

Like a CLA without a central entity?

I think that’s exactly the point — that formal government entities are a very large step for people to take. The “operating stack” of incorporating is a lot more to maintain than this kind of agreement.

That’s correct.

Of, if you will, a Cross License Collaborative without payment.

1 Like

This tool addresses only the issue of licensing flexibility over time. It does not create any kind of legal entity, much less one with limited liability. It cannot own trademarks or other ancillary rights.

1 Like

This is definitely a great move as opposed to XLC.

Q: Does this have to be a CLA type format?

I find (personal opinion based on reading enough engineering reddit forums and contributing to projects) that across smaller oss project maintainers are often back off from using CLA type agreements. It makes it harder for new contributors to submit changes because it requires them to manage CLAs.

Most of the time the place where I see CLAs in action are on projects by bigger groups (corporations or foundations.)

I once contributed to a project that had an automated CI check that required me to add my name and email to a file. Could such XLF license be rewritten in a way that essential acts like a single coupled with some requirement of a public document listing out the names of co-members? I am not a lawyer so this obviously might seem like a super stupid idea but hey, if I don’t speak up, how would I know if it is stupid?!

One other comment question is, the license has a Resignation but nothing about removal. I guess Removal is not particularly needed since people can just re-license if there is a super majority. But I am not sure the implication of allowing “orphan” licensors on the cross-agreement be left. Could a situation be created where there are so many cross-licensors that a super-majority consensus cannot be reached?!

p.s. This seems like a really cool license for OSI to adopt.

1 Like

I see the knee-jerk reactions to CLAs, as well. In the end, contributors need to take some affirmative step, creating a written record, that shows they agreed to the terms.

I’d also keep in mind that after the first two “founding” contributors, there’s a more elaborate process for voting new contributors in. It can all be done online, but it’s not something that can just be dropped into a GitHub repo and forgotten. It’s a governance thing.

That’s definitely crossed my mind, and I’m glad you brought it up.

The obvious answer is to allow removing existing members by supermajority vote. But that gets tricky when you expect that many contributors will become unresponsive over time, which I think we have to.

There’s no concept of “quorum”—a minimum number of contributors who have to vote one way or another for the outcome to count—in either XLF or XLC at the moment.