[Idpy-discuss] Notes: Chatting with the Commons Conservancy, 11 April 2018

Heather Flanagan hlflanagan at sphericalcowgroup.com
Wed Apr 11 13:16:32 UTC 2018


hi all,

A few of us met with Michiel Leenaars from the Commons Conservancy today 
to talk about CC as a potential IPR home for idpy. I still have to get a 
call with Apereo on the calendar. For those of you that are interested 
but were unable to attend the call today with CC, notes are below.

----
Attendees:
Benn, Roland, Ivan, Michiel, Heather, Leif

Handling money:
How do donations work? How do we handle money? How do tax agreements get 
handled with multiple countries? Given that we’re giving with 
contributors across national boundaries, where do the CCLAs fall in 
terms of jurisdiction? What is the international suitability of their CCLA?

What kind of volume are we talking about? Right now, none at all.
CC has a few mechanisms. Anyone that has a tax treaty with NL (which is 
most of the world). Will be setting up a 501(c) in Delaware in the next 
few months, which will help folks in the US. If entities can’t donate, 
but can receive invoices, have a separate company for that (Commons 
Caretakers). This is called a fiscal fundraising entity, meant 
specifically for charities. This is working well for the Filesender 
project. The idea is to de-couple the keeping the money from the place 
where it is (e.g., keeping the money in Japan to avoid Japanese issues, 
but still accepting donations). There is a universal regime in Europe - 
anything tax deductible in one country is tax deductible in another 
country. If you want to do grants, then that will work as well: NLnet 
can help deal with that. We do want to separate governance from funds 
handling.

Idpy doesn’t know what the funding model will look like exactly, but it 
will probably be a similar model to current projects - a relatively 
small number of international, organizational contributors. We won’t 
have use case in the near future that require multinational stashing of 
funds.

CLA:
CC has no fixed model. The default model is from 
contributorlicenseagreement.org. That is considered a best practice, but 
the can also use the FLA (fiduciary license agreement).
CC has a generic foundation, and bootstrap underneath that a set of VO 
(not confined to traditional foundation model). The VOs can organize 
themselves, and can put their own restrictions on what people can do - 
you can fork the organization, or never. You can dictate where the code 
can go, etc. Conditions enforced at the foundation level; will enforce 
even after the VO evaporates. This will allow you to do things like mix 
licenses (e.g., MIT and GDPL), if needed.

Current use case: we’ve reached consensus on Apache2. Still discussing 
governance models.

Open questions: Handling of the IPR, code ownership, CCLAs. The sample 
license agreements sent to us to review came from 
contributorlicenseagreement.org. The default selection that CC has made 
was drafted by the legal advisor of the Free Software Foundation of 
Europe, so very much vetted towards international usage.

US centric questions: The concern is more about the CCLA than the CLA. 
Need a package that explains what is is, why it’s important, why you 
can’t mark it up. We have such a thing for Apache2, but if we wanted to 
use the defaults from CC we’d need a similar FAQ-style thing. (Michiel 
agrees).

Choice of law: assume we’re staying with Dutch law, but that does make 
another hurdle on the US side. Many institutions in the US may not have 
international law resources available to them. So, having that FAQ thing 
mentioned above that would also include “how does Dutch law differ from 
US law” etc would also be helpful.  (Michiel points out that the FSF 
people primarily worked from US-based CLAs, so this should be easy to 
address as well)

One more edge case: in the US, government agencies cannot sign 
agreements outside their home jurisdiction. This will impact state 
universities and institutions. They can’t accept the jurisdiction of 
another state. Right now, we don’t have that situation, but that’s 
something to think about down the road. Mentioning this in response to 
the 501(c) set up in Delaware.
In Europe, some countries are like that. This should scale to the US 
state-by-state level.

What other things should we be asking about?
CC is a self-service shop. Just try to give a safe home for the code, 
and mechanisms to deal with things. Don’t have much in the way of IT 
infrastructure: you’ll run your own website, lists, etc. Just try to be 
a safe legal home and a decision infrastructure. You should ask “can you 
leave?” For example, if you give your code to the FSF, you can’t get the 
code back. CC wants an easy, low weight to start and which can scale up, 
but there is no mandate to stay. You can copy the entire framework if 
you want to, as all the framework documents are Creative Commons.

The CC is completely free. If you go with one of the payment 
infrastructure, there is no mandatory payment structure. People pay what 
they can contribute. Most intermediaries ask for 10%, which CC thinks is 
high, but they appreciate people donate what they can.

What is the common level of contribution that most projects? Between 
5-8%, but it’s voluntary.
How many projects are in the program? 6 on board, and about 15 that are 
in various stages of onboarding
* Filesender
* eduVPN
* Internet of Coins (cryptocurrency effort)
* Red Wax
* Fashion Freedom Initiative


More information about the Idpy-discuss mailing list