Some relevant info from an email I received from Strype last week:

I generally recommend the AGPL for server-side packages.

I also recommend signing up to the Franklin St Statement:
http://autonomo.us/2008/07/14/franklin-street-statement/

...and the EFF Bill of Privacy Rights for Social Network Users
https://www.eff.org/deeplinks/2010/05/bill-privacy-rights-social-network-users

I would suggest stating and linking to the license you've chosen (and those statements) on both loom.io and loomio.org.

BTW As the copyright holder you can change license at any time, but any code released under the previous license can still be used under the terms of the older license. This is what happened when Oracle bought OpenOffice and attempted to turn it into a proprietary product. The Document Foundation was formed to develop a fork of the code as it existed at the time of Oracle's purchase, resulting in LIbreOffice, which has been so successful that Oracle threw in the towel and handed OO over to the Apache Foundation:
http://arstechnica.com/information-technology/2011/04/oracle-gives-up-on-ooo-after-community-forks-the-project/

My ideal would be something like "Anyone can use the Loomio code, which is free and open source, as long as what they're doing with it is also free and open source"... does this work that way?

The MIT license is simple, solid, and does everything that it says on the box. The only question is, do you want code from Loomio to be used in someone else's commercial application? If you don't, then the MIT license does not protect you from that. It requires you to distribute the MIT license with any version of the loomio codebase, but I think the think to consider is, what if Loomio is used as an open source component of a closed source app? The general reason the rails community likes that is they tend to think that's ok.

However, I'd be quite happy if you were to use some sort of GPL variant (such as the AGPL). I would quite like to see Loomio enginified, and if so I'd probably install the engine into the Atamai website. That website is currently under the MIT license, but it wouldn't be hard to change it to AGPL.

Alanna, what you're suggesting is what the AGPL license is designed for.

@Craig moving Atamai over to AGPL might not be difficult for you, but I can imagine many sites that might want to stick with their MIT license and still use Loomio inside of it. If we license Loomio with AGPL, other sites licensed under MIT wouldn't be able to use Loomio inside their app, correct?

@Richard - it sounds like what Strypey is saying is that it wouldn't be hard to move from AGPL back down to MIT if we wanted to. In which case we could play it safe and start out with AGPL.

My gut is still telling me that at this point there is not much risk of a for-profit company coming and taking our code and then making something better with it. Or at least, if they wanted to do that and had the resources to do so, restricting their access to our codebase probably wouldn't stop them.

This one also looks interesting! Not that I really know about this stuff... http://p2pfoundation.net/Peer_Production_License: "The peer production license is an example of the Copyfarleft type of license, in which only other commoners, cooperatives and nonprofits can share and re-use the material, but not commercial entities intent on making profit through the commons without explicit reciprocity"

Right... just realized that's the same one Rich mentioned

If there's no downside to it i'm in favour of starting off with AGPL (or Copyfarleft).

Jon - do you foresee any harm in going that way?

Sorry I just saw your worry Jon:

"If we license Loomio with AGPL, other sites licensed under MIT wouldn't be able to use Loomio inside their app, correct?"

Is this the only potential worry?

this is an important business decision and I would like us to seek advise so we know we make a good one, sorry about the double block \i was trying to figure out how to add the short comment

The proposal is to continue with what we've got while we research better options, so blocking suggests we should stop everything and pull our code offline.

Jon is correct that if Loomio is licenced under the AGPL, it will not be possible to use it inside an application (even just as a gem dependency) which is not itself licensed with the AGPL. That's why this is not a common approach for ruby gems.

Ok, doesn't sound real sensible to do that, could we agree a timeframe for reaching a decision and a process on how to do that?

this info should help and it looks like LGPL could be an option:

http://en.wikipedia.org/wiki/Comparison_of_free_software_licenses

excerpts:

"designed as a compromise between the strong-copyleft GNU General Public License or GPL and permissive licenses such as the BSD licenses and the MIT License.

The main difference between the GPL and the LGPL is that the latter allows the work to be linked with (in the case of a library, 'used by') a non-(L)GPLed program, regardless of whether it is free software or proprietary software.[1] The non-(L)GPLed program can then be distributed under any terms if it is not a derivative work"

I'm torn - on one hand I like the protection of the AGPL but if the open source community starts contributing based on that license then it will not be possible for us to provide loomio as an engine to people who aren't running an open source app which would be most of our potential client base.

So I think an AGPL would significantly limit our business model whereas if we have a permissive license then all the loomio contributors are aware that we (or anyone) can take this code and use it in commercial applications.

Personally I am in favor of a permissive license which allows loomio to be integrated for commercial use and we actively build a network of entities who do this sort of work as part of the loomio ecosystem and trust that enough of them will contribute back.

On the basis that we are working to answer the question of what will workbest in the longer term using what we currently are seems sensible.

Kia ora koutou

The fundamental difference between MIT and (A)GPL is 'share-alike'. Under the MIT license, a corporation can take some or all of your code, alter it and/or mix it with new code, and release the result as proprietary software. They are under no legal obligation to contribute their changes to your code (or the new code they've added to make their new program) back to the Loomio developers . Under (A)GPL, they are obliged to share back to the common pool (what Stallman calls being a good neighbour).

The share-alike condition included in AGPL provides the same protection as the PPL (Peer Production License), without the overly restrictive 'non-commercial' clause in the PPL. Having commercial organisations adopt and improve on Loomio (as they have with Linux) is to your advantage, as long as you use a 'share-alike' license, which obliges them to give their improvements back to the community.

As the copyright holder, you always have the ability to relicense in either direction. However, the version of the code released under License X will always be reusable under the License X conditions. This is why when Oracle bought the copyright for OpenOffice and changed the license against the will of the majority of the developer community, the developers were able to create the Document Foundation and republish OO as LibreOffice under the old license.

Hope this helps.
He mihi mahana
Strypey

BTW (A)GPL is "restrictive" in the same sense that rules against privatisation of public parks is restrictive.

An update on the business model is that we are looking to create a high number low cost price model, essentaially all groups under 10 people are free and from 11 people on it is $1 per person per month. This means although we will do business with large companies we are not relying on white label business to fund the organisation any more or less that virally growing groups of any other sort.
This might make a difference to the concerned Joshua is expressing about AGPL

I think this needs to be discussed within the context of our development and business models and how each could be potentially limited. Not willing to make a definitive decision until I'm more informed of the practical implications of either model. From what's been discussed here, it looks like a PPL will ensure we can provide the application to clients who wish to host Loomio privately even though it may isolate some of the Open-source Development community I don't think it would amount to an insurmountable obstacle for developers contributing to code.

Joshua, are you possibly able to give some more context for your concern about the ways you think Loomio would be restricted by an (A)GPL license? Some hypothetical examples of likely situations would be really helpful (i.e. what types of implementation of Loomio in organisations would be prohibited?)

@benjamin

say for example we made loomio an engine and wanted to integrate it in with an internal website like enspiral which is closed source. My understanding is that we wouldn't be able to do that If loomio was under an AGPL license. This means it would make it very difficult for us to work with larger organisations integrating loomio into their existing setups - which may be ok but is something to be aware of.

If we owned all of the copyright on loomio we would be able to license it to people using a more permissive license on a case by case basis but to do that we would need any open source developers to sign an agreement vesting the copyright of anything they create in us which would put them in exactly the same situation we don't want to be in - someone else profiting from their work.

If we use the MIT license then we (and anyone else) are free to do what they want with the code base and while we run the risk of people going and starting competing businesses based on loomio I think the benefit of being able to do whatever we like outweighs that risk. Anyone who really wanted to compete could just rewrite loomio anyway and I don't think trying to restrict what other people can do is a good competitive strategy - except in the case of protecting our name and trademarks.

Thanks for the clarification @Josh!

That is indeed pretty convincing - it would certainly be a hassle to need all OS devs to sign an agreement.

Does anyone know of a way around this? Any ideas Strypey?

The one thing I would want to investigate is the rules around using an AGPL engine as a library - if it was possible for a closed source app to integrate the engine and only be forced to contribute back changes they make to the engine itself (as opposed to other parts of their app) then that could be an ideal solution.

Might be worth consulting an expert on though and it may be we could actually tweak the AGPL itself to make that use case acceptable.

I'm ideological in favour of AGPL because it forces share-alike, encouraging transparency and openness.

Pragmatically though I'm in favour of MIT. While it allows private (e.g. commercial) contributors to take the code and not share back their changes, assuming there are more development resources in the public domain than the private, it would be in the interests of contributors to share-alike.

@Joshua
Keep in mind that a software license applies to a package, not a system. A GLAMP webserver is a system, containing a number of packages, under a number of licenses:
GNU/Linux: GPL
Apache: Apache 2.0
MySQL: GPL
PHP: PHP (BSD-style license)
plus any web application packages, each with their own license (eg Loom.io).

The license you apply to any server-side and client-side code you write for Loom.io applies only to the packages you publish, and any packages directly derived from them. Don't get confused by the MS lies that (A)GPL crawls through entire systems 'infecting' every package with copyleft obligations ;)

@ Ben
Copyright assignment is complicated. It's a bit like the choice between a Trust and an Incorporated Society. It's easier for the exec to make and action decisions in a Trust, and similarly where they have copyright assignments. However, a Society requires the exec to consult, and to be accountable to community members for decisions and actions taken, and this is similar with contributors keeping their own copyright. So it depends what your organisation priorities most - the ability to make and action decision quickly, or the accountability of the exec to the membership - ie democracy. I presume Loom.io is the latter ;)

The solution could be to dual-license, like MySQL do. They have one license (GPL) for organisations who publish their code as part of open source collaboration, and another for commercial organisations who only use it internally or don't want to work under the terms of the free code license:
https://www.mysql.com/about/legal/licensing/index.html

Thanks for clarification @Strypey!

Copyright assignment is indeed complicated, and I'm completely ignorant about it. In terms of priorities, I would say what we want is to operate with perfect democratic accountability in a way that doesn't require any time. Is that likely to tear the space-time continuum?

@Joshua, do you see any problems with using a dual-license for Loomio (similar to the licensing for MySQL)?

@ Ben
Yes ;) However, the dual-licensing solution could keep the universe in one piece. The MySQL organisation might be able to provide advice on how to implement that, but my suggestion would be that you keep commit access to your GIT repository confined to a trusted core team. Then you just need to make it clear inside any patch submission system that to contribute code is to agree to the use of that code under either license.

BTW The international experts on licensing matters are the Software Freedom Law Centre:
https://www.softwarefreedom.org/

You could also seek more localised advice from the Open Source Society of NZ:
www.nzoss.org.nz

+1 to seeking advice from some of the foundations. I think a dual license could work

So, not to open up a can of worms or anything, but..... I was thinking the other day "Why not license the code under AGPL for now?"

We don't have anyone currently using Loomio externally in other applications yet, so the MIT license isn't really giving us any added benefit right now. If it comes to a time where we feel like AGPL is getting in the way, then we can address it at that point. Might as well start out on the safe side.

I know this is contrary to what I was saying before, but having chewed on this for a little bit longer, I'm leaning toward "let's play it safe for now." We can always choose to be more permissive in the future. Also, when I initially made the suggestion to stick with MIT, I wasn't aware that we could start with AGPL and switch to MIT later if desired.

For reference it's interesting to see what MongoDB did with AGPL (http://blog.mongodb.org/post/103832439/the-agpl).

Basically the core DB is AGPL and the drivers are Apache licensed so applications that "talk to" MongoDB don't have to be AGPL.

@Strypey - do you know how easy it is to switch to MIT at a later date if AGPL becomes problematic?

Great, I've had a chat with Rochelle and I've just emailed the Software Freedom organization and asked for advice. We'll see what they say.

From my conversation with Rochelle, it sounds like...

In order to switch the license we'll need to collect some form of a CLA (contributor license agreement) from all of the people who've contributed code so far. But that shouldn't be too hard.

The thing that is still unclear is the code surrounding the subscription aspect of Loomio. The thing is, if we're hosting a version of loom.io and we decide on having some sort of subscription fee, then we may not want to make the code regarding the subscription/payments open source (this deserves a separate conversation in itself).

It seems that this is the way StatusNet operates (http://en.wikipedia.org/wiki/StatusNet). They are an open-source twitter/yammer clone, and they are licensed on the AGPL. But on their specific hosted version of the app, they have a subscription service and provide "premium" features at additional cost (which are available free if you set the application up on your own servers). However, I'm not sure how legally defendable their position is. This is what I've asked the Software Freedom organisation about.

@Jon I think what Mongo is doing relates to the issue you're talking about.

From my understanding you can develop a closed source subscription feature however I think it would have to be considered a plugin that just talks to the loomio application itself. I think the idea is that a subscription plugin can be developed to talk to any application and so isn't a part of Loomio and can be licensed seperately.

I think it's only when you add Premium features that things get sketchy as that is really pushing the boundary of external.

However: My understanding of this is from a software standpoint not a legal standpoint so I'd be interested to hear what the Software Freedom foundation say.

Ahh, that's really encouraging to hear Paul. Indeed, it will be interesting to hear what they say.

@Ben
AFAIK it will be as easy to switch licenses again in the future as it is to switch licenses now. The only thing that would make it harder is having lots of people submitting code who aren't part of the core team, and are hard to reason with and reach consensus.

As I've mentioned, this would be resolved by having such people assign their copyright to the Loom.io entity. This is really a separate discussion, but I recommend that you do this, to protect yourselves from what happened to the Horowhenua Library Trust after they commissioned Katipo to create the Koha project. If HLT had sought assignment of the rights to the code (and trademarks) they wouldn't have ended up owned by PTFS/ Liblime when it bought Katipo:
http://computerworld.co.nz/news.nsf/news/library-trademark-battle-heats-up

In the unlikely event that Loom.io governance fails the developers in some catastrophic way, both AGPL and X11 (MIT) licenses allow the developers fork the code and create a new kaitiaki organisation, which is what happened when Oracle bought OpenOffice, and most of the developers left to found the Document Foundation:
https://www.documentfoundation.org/foundation/history/

@Josh - I agree we should only do this once we've sorted out a CLA (that includes a clause about assignment as Strypey mentioned). However, what's the reason on holding off until Loomio has been enginified? Seems like that could potentially be an extra month or two down the tracks...

Joshua, I'm not sure what you mean by "enginify". Are you proposing to have some parts of Loomio under AGPL, and some parts under X11("MIT")? Or is it some parts open source, and other parts proprietary?

AFAIK all the current code is under X11. Just to clarify, you can issues another license on the current code (eg AGPL or even make it proprietary), but you can't retract the X11 license on it.

@strypey - enginify is the name for a piece of work which is extracting the core loomio codebase into a rails engine so it is possible to integrate it with other rails applications.

@jon - after thinking about it more I can't see a reason to hold off on the agpl because of the engines but I agree the CLAs are critical.

@Jon and Joshua
Since it's good etiquette to consult your open source community before changing the license on a project, you can ask them for a CLA at the same time. Question: is there currently a Loomio entity that can take on ownership of the copyrights?

BTW X11/BSD licensed code can be used in a proprietary project by anyone, they just can't stop other people using that code under the terms of the X11/BSD license. By the same token, even if a Loomio contributor opposed the relicensing, you could still do it, but any part of the code they could prove copyright over would also be usable under the old X11 license (not modified versions though, AFAIK they would be covered by the new license).

There's no legal loomio entity yet. Ben and Viv are currently working on that. Not sure where they are at... ?

Setting up the legal entity is in process - will keep you updated

Hopefully not far off!

The Enspiral Foundation can hold the copyright until loomio is setup - it would be worth holding off until the co-op is registered if it won't be far off

Great! Consensus on AGPL after CLAs. So the next steps would seem to be:
1) Make sure you have a complete contact list of all contributers who will need to agree to the CLA
2) Draw up your CLA text, and get consensus from contributors on its terms and wording (incl. planned change to AGPL)
3) Once, the Loom.io entity is incorporated, collect the signatures and file them
4) Formally announce relicense (press release?).
5) Party! (fundraising opportunity?)

Devel note: it would be nice if I, as the proposal scribe, was able to attach this summary and implementation suggestion to the proposal itself somehow

Update:

• We've now incorporated Loomio as a legal entity which we can now use to assign copyright to
• I've created a draft CLA using http://www.harmonyagreements.org/. View the draft here: https://docs.google.com/open?id=0BwwrFxc5jNt9MVV5Y1hoUlZGN0E

The basic settings I chose for the CLA were:

1. Full copyright assignment of the contributor's code to Loomio (given that the Loomio code-base is licensed under an OSI-approved license)
2. Any media submitted by a contributor will be licensed under Creative Commons Attribution Share Alike
3. Agreement will be governed in the legal jurisdiction of New Zealand

This is quite a widely encompassing agreement (we are asking for full copyright rights to change the code-base to whatever open-source license we choose at anytime). However, I think that we can start out broad and narrow down the agreement later on if the group decides it would like to do this.

I probably wouldn't normally feel comfortable with such a broad agreement to start with, however, since Loomio is going to be a democratic co-op I don't think it should be too much of a problem. We just need to make it clear in the constitution how the Loomio Co-op is going to make decisions. That way, when a contributor signs their copyright over, they know that there is a clear and democratic process that they can participate in for deciding what is going to happen with the copyright of the Loomio codebase.

Basically, what I'm thinking is that we should keep the lid tight on all of our legal agreements, and then just have a super fucking awesome constitution that everyone believes in and actually works for facilitating democratic decision-making. I think in the long run this approach will give the most decision-making power to the largest number of people.

I love Jon.

Ah that 2.2 Patent License reads dodgy.

I'm pretty sure it's saying anything I own or will own the rights to will be transferred to the Loomio Org?

I might be mistaken though, I'm particularly bad at reading legal stuff.

Hmm, it does read a bit funny, eh?

From what I can tell, it seems to be saying:

• You grant the Loomio project the right to freely LICENSE any patents that you own that the Loomio codebase would otherwise be infringing upon (as long as the codebase stays open-source).

And the part that seems a little bit dodgey to me:

• You grant the Loomio project the right to sell your contribution provided that it stays under an open-source license

That said, I can't think of why anyone in their right mind would want to pay for open source code. ;-)

I've asked our lawyer Rochelle to weigh into this conversation, so we will see what she says.

"You grant the Loomio project the right to freely LICENSE any patents that you own that the Loomio codebase would otherwise be infringing upon (as long as the codebase stays open-source)."

If that's the case I have absolutely no issue with it, but I don't understand why they can't just write it that way lol.

I find 4 pages of legal code quite intimidating. I think it would be good to have a human-readable summary (a "compiled binary"?) of what the agreement is saying, similar to the CC deeds:
http://creativecommons.org/weblog/entry/12778

I can't think of why anyone in their right mind would want to pay for open source code. ;-) <<

Keep in mind that this section will be talking about selling the rights to the code, not the code itself. Any OSI or FSF approved license already grants the right to sell the code, or any derivative, or compiled version therefore -if you can develop a market for it ;)

I would add a clause saying the core codebase can only be relicensed to a license approved be either the FSF or the OSI. The free code license does protect developers in the worst-case scenario that zombies take control of Loomio Inc (as happened with Oracle buying OO along with Sun Inc, or Liblime buying Koha along with Katipo Inc). But since we can protect them from ever having so set up a whole new admin infrastructure (like Document Foundation folks did) or wrangle over trademarks, I think we should.

I believe section 2.3 covers the clause you're asking about Strypey?

"We agree to license the Contribution only under the terms of the license or licenses which We are using on the Submission Date for the Material or any licenses which are approved by the Open Source Initiative on or after the Effective Date, including both permissive and copyleft licenses, whether or not such licenses are subsequently disapproved (including any right to adopt any future version of a license if permitted)."

In regards to creating a human-readable version, I completely agree. It's just a matter of having a lawyer who can take the time to sum it all up. Because to be completely frank, I'm not entirely sure what it all means.

I'm also super keen on the idea of in the future attaching a "statement of intent" to each legal document. Just a clear summary of why the document/contract exists... You know, what's the spirit and purpose for this thing? So many times you see law being interpreted in exactly the opposite way it was intended (e.g. US patent law).

I'm assuming that a submitted Google form might not be the BEST in terms of legal coverage, but I think it's at least better than nothing for now. In the future we can look at using something like more official like DocuSign if required.

Also, I ran the CLA past Rochelle (lawyer) and she mentioned the following:

"Its a really good agreement, just written very formally and written for US conditions mostly, although it will work perfectly fine here.

I don't have any concerns about the clauses at all.

They effectively require an assignment of the copyright, with an assignment back of a very wide irrevocable license to the contributors. It does this in relation to patents as well as copyright.

It allows any non-code media to be assigned provided the CC-Attribution license is used.

It suggests that those under 18, or covered by employment agreements that could affect their code do the right thing and get permission before signing the agreement.

Each party agrees it won't be liable for any bad code, to the extent the law will allow that.

... It would be good to work on a plainer English version - it just takes quite a long time to get that right... I'm reluctant to promise that as I have a lot on at the moment."

I think it be wise, to add the FSF alongside the OSI as an organisation whose license endorsement is accepted. Not only out of respect for the originators of free code licensing, but so that if in the worst-case scenario the OSI were to fold, or delay endorsing a Free Software license for some petty reason, it could still be adopted. Obviously, by saying FSF OR OSI in your agreement, the same applies in reverse.

If I was thinking about coding on Loomio, that document would put me off. I have no idea what rights I might be signing away. Jon, you have already written two human-readable summaries in this thread, could you not get Rochelle, as your legal consultant, to merge them into a final version, and add it to the top of the license?

I would suggest Stephen might be willing to help out with a human-readable version, working off the great work Jon has already done writing summaries...

Jon and I had a good conversation about this with Stephen today (Stephen is a lawyer that works with Rochelle at Enspiral Legal).

Here's where we stand as far as I'm concerned:

A plain English version is nice in theory, but difficult to include in a legal document as plain English and legalese are mutually exclusive. It would need to be included as an Abstract or Appendix or something. Stephen has volunteered to spend an evening this week researching what kind of disclaimer we'd need to use to get around this, something like "This is a summary of the intent of the document for guidance, but is not legally binding." On the face of it, 500px does a great job of this, but whether or not this would hold up to legal scrutiny is another question: http://500px.com/terms

Part of the plain-English summary would point to the intent of the CLA, which as I understand it is to sign the copyright of the individual developers over to the collective will of the cooperative, as guided by a constitution.

Strypey, are you suggesting we just need to edit clause 2.3 to say "...or any licenses which are approved by the Open Source Initiative or the Free Software Foundation on or after the Effective Date..." to address your concerns? Like everything else in this project we are iterating towards an ideal; right now we need to get agreements made ASAP so we can accept code contributions without fear of litigation.

Having this proposal run through Loomio raises an interesting question about stakeholding. Obviously it is good to get broad input from people with diverse levels of stakeholding, but just bear in mind that the only people that need to accept the terms of the CLA are people actually contributing code, i.e. none of the three voters so far :P

Wellll at first it's aweful to read, no offense to any lawyers involved!

However I left it a few days and read through it again and I'm pretty sure I understand what it's saying and I'm alright with signing it now that I understand 2.2 (it seems clearer than it was before?).

After reading Strypey's point about FSF and OSI, it seems like it's a good idea. It's a minor change to add it in though and seems like it protects the project even more. Having said that I WOULD sign it as is anyway.

@Richard Having this discussion alongside even including people who aren't required really helps inform us on whether or not to sign, it's incredibly useful for me atleast.

oops, misclicked the block

Rochelle has passed this off, however I've just mailed her your concern, so we will see what she says.

@jon, sweet - if rochelle's happy i'm happy with it - seems fair and reasonably clear.

@Richard

Strypey, are you suggesting we just need to edit clause 2.3 to say "...or any licenses which are approved by the Open Source Initiative or the Free Software Foundation on or after the Effective Date..." to address your concerns? <<

Yes.

@Human-readable summary discussion

Again, I suggest following the model of the CC "deeds":
https://creativecommons.org/licenses/by-sa/3.0/nz/

Clicking that link, you'll see that the "deed" is a human-readable summary of the license conditions, which then links to the actual license in "legal code":
https://creativecommons.org/licenses/by-sa/3.0/nz/legalcode

Besides helping contributers understand v1.0 of the agreement, the advantage of a deed is that if you need to change the CLA terms, you would write a new deed which sums up the new terms. Contributors can then easily compare the deeds to see what's changed, and if they need to, ask why it's changed. Otherwise, they just get a message that one obscure bit of legal code has changed to another obscure bit of legal code, its hard to know what questions to ask to get clarity, and harder to get buy-in to the change.

Hey @Strypey - thanks for your input! Would you possibly be keen/able to help write up the human-readable summary? Code team is pretty overloaded, and it sounds like you've got a fair bit of experience with this stuff!

@Strypey

I've modified the clause to include your suggestion about including the FSF foundation.

Regarding human-readable summary - I would also really like the contract to have one as well. However, at the moment we just don't have the resources to get something like this done. I'll echo what Ben said: if you are interested in creating a legally-defendable human-readable summary that would be awesome! If not, then I'm afraid we'll have to wait until someone with the time and legal expertise comes along to pick up this task.

As an alternative to a human readable summary, do we have someone we could recommend confused people to for clarification? I'm guessing it's not going to come up that often, but having someone to call on that understands it is a pretty good plan B? Just a suggestion as an alternative short-mid term.

@Paul that's probably a good idea. I mentioned in the agreement that if people have any questions to email the loomio-dev mailing list. However, I'm also happy to be a specific point of contact if anyone has questions or concerns about the CLA. I probably wouldn't be able to answer extremely technical details, but I could at least answer questions about the intent of the document. Would that be helpful?