Hi all,
We're cancelling the call for this week. I encourage you to use the time
to work on making sure the use cases are clear and the tests are
available and run for any PRs you've submitted.
Our next call is scheduled for 1 May 2018.
-Heather
Hi all,
The email went out giving code contributors a heads' up re: the need for
a CLA or CCLA for code committed to Identity Python projects. As
expected, we have some bounces, and some addresses were never valid to
begin with.
Bounces:
<Andy.Richter at brige-way.com>
<hans.horberg at umu.se>
<hossain at newscred.com>
<ikakavas at noc.grnet.gr>
<matt at netki.com>
<rebecka.gulliksson at umu.se>
<yo at launchkey.com>
Invalid addresses:
<DasAllFolks at users.noreply.github.com>
<haho0032 at its-admins-MacBook-Pro.local>
<ludwigkraatz at users.noreply.github.com>
<rebeckag at users.noreply.github.com>
<rhoerbe at users.noreply.github.com>
<z38 at z38.invalid>
I'm not too worried about the uma.se ones, as we we have other contacts
there. I'm also not worried about rhoerbe - we know where to find Rainer.
Thoughts on how to contact or verify what code was submitted for those
people and/or organizations I can't reach?
-Heather
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
Hello all,
As mentioned on the developers call this morning, I'm setting up a call
with Michiel Leenaars at Commons Conservancy to discuss the possibility
of working with them as an IPR home for the idpy projects.
I've set up a doodle poll (link below). Please fill out the poll by this
Friday. I know not everyone will be ready, willing, and/or able to
attend the call, so if I don't see your response by this Friday, I'll
assume you are willing to catch up via the notes from the call.
https://doodle.com/poll/dugz5cadrd9r2q23
Thanks for your time,
Heather
Attendees:
Jonas, Ivan, Roland, Heather, Rainer
0. Agenda bash
1. pySAML2 PRs - https://github.com/IdentityPython/pysaml2/pulls
Ivan spoke with Leif yesterday; may be coming up to Sweden soon for a
meeting (and maybe more).
Ivan has 493 and 495 assigned; 493 is still being examined. 495 will be
resolved soon. Will start looking at 499; Ivan has an idea on how to
simplify. When that’s done, it can be merged as well. 498 will be
assigned to Ivan; it can be merged, but he has some ideas on how to make
it better.
485 and 483 are waiting on Scott to add tests.
468 to the bottom of the list - haven’t looked at those in detail yet.
468 will be rejected.
Team is considering adding labels. Ivan will look into what might be
appropriate; he has used these in previous repositories.
2. Satosa PRs - https://github.com/IdentityPython/SATOSA/pulls
Ivan is currently looking at 137 and 160, and expects to close those
tomorrow. They won’t be accepted, but he will take parts of them. When
that’s done, he’ll go to 166 (related to issue 165). He has downloaded a
Windows virtual machine to try and reproduce.
171 is a fairly big one.
172 can be merge, but waiting on Scott adding some tests.
176 has some fixes, but one of the fixes changes the behavior of Satosa.
Ivan would like to go over that with them.
Ivan will look at the issues after the PRs. Note that Martin opened an
issue in the micro services repository today; will need to review that
as well. The question is how to handle the split repo. This has been
discussed a bit on the mailing list, but Ivan will ping the list to
remind people that input is needed so we can bring this a conclusion.
3. Governance update
Heather will be sending a note to committers re: (C)CLA.
Expect a set of doodle polls for calls with Commons Conservancy and
Apereo so we can discuss their organizations as possible IPR homes for
idpy. The call with CC will happen first (Heather hasn't heard back from
Apereo yet).
4. AOB
pyFF - not sure if Leif has a more permanent workaround for the segfault
issue. Also not sure if this has been refactored to be a flask project.
Attendees: Heather, Scott, Benn, Ivan, Leif
https://docs.google.com/spreadsheets/d/1dNR8clA_wKouhwonD8bIiyA5N2wMsorS8Uz…
A few notes re: the spreadsheet:
* Items in yellow are things we should think about, but may not be
blockers in our particular circumstances.
* The phrase “more application than integration” applies to the idea
that a good home has a process for ensuring projects are sustainable,
and that the organization will not just become a dumping ground for
random projects. The process of vetting an inbound project (and bringing
it into conformance as needed) is generally referred to as incubation.
The incubation process is usually fairly complicated, and involves
active engagement with the potential home organization. An application
process is simpler, and basically consists of a few questions for the
potential home's board to consider in deciding whether or not to accept
the project.
* Organizations may want to have their lawyers look at the application
process.
Leif: the project has to feel “at home” with the other projects in the
IPR home; we can’t be too different from what else is happening in that
organization. That makes Apereo perhaps a bit of a stretch. We want to
have a home where we can have a certain amount of self-governance.
* Apache Foundation has a lot of structure, and each project is
reasonably independent but expected to follow Apache Foundation’s rules.
Leif: a poor fit because of the focus on what their projects are about
(i.e., they don’t have much in the way of identity-related projects).
* SPI, SFC - Benn is not seeing a lot of support in SPI or any level of
community in SPI or SFC. Heather: if these were the last options
available, that would be something we would pursue further, but we have
other options so these aren’t worth pursuing
* Apereo - Leif is concerned about Apereo’s long term viability, though
Benn points out if we own the IPR we can always move the project.
* Commons Conservancy - GEANT already has something of an agreement that
would make this easier, and NLNet Foundation (the parent organization
for CC) has long term viability via their established DNS software (see
https://nlnet.nl/project/current.html for list of NLNet Foundation projects)
Channeling of funding
* some organizations want ability to collect money; Commons Conservancy
is not set up to route funds (that’s what they use NLNet Foundation or
GEANT for). Apereo is set up for that.
* This was by design for Commons Conservancy - indirect IPR
protection; it would be pointless to a takeover because the project does
not control its funds. If someone sues you for IPR infringement, there
is no money to be taken.
* There is definitely a possibility of future cash donations (not
just the current in-kind funding via FTE that we see today)
Action item:
* Heather to set up calls with both Apereo and Commons Conservancy to
have them talk to us, introduce ourselves, etc.
* 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?
* Heather to reach out to the code authors to see if they have a hard
“no” (which include non-responses) re: signing a CCLA to turn over their
code to the project
Hello all,
This is a reminder that there is a call about idpy governance tomorrow,
27 March @ 16:00 UTC (9am PT | 12noon ET | 18:00 in Sweden). The goal of
the call is to settle on an IPR home for idpy; once we've done that, I
can start creating the necessary policies and procedures in accordance
with the requirements for $IPRHOME.
A comparison chart of possible IPR homes is available in a Google doc:
https://docs.google.com/spreadsheets/d/1dNR8clA_wKouhwonD8bIiyA5N2wMsorS8Uz…
If you have not received an invitation and want to be on the call,
please reach out to skoranda at sphericalcowgroup.com and he'll get you
added to the BlueJeans meeting invitation.
Thanks!
Hi all,
There was no good time for folks with the first attempt at a call to
discuss finding an IPR home for idpy. I've put together another doodle
poll - hopefully there will be a time that works more easily for mst!
https://doodle.com/poll/33gu594nmn4q7p85
If you would, please fill out the poll by Wednesday, 21 March 2018.
Thanks!
Heather
