# Call with Apache on EESSI non-profit

## Things we'd like to know about

### Governance stuff
* EESSI is not large right now and has very few (even no) production users. Our scope for growth is large though, especially once EESSI is used in production by some HPC sites.
* What's a good governance model when you have a lot of users and a much smaller amount of contributors?
* How do we balance the interests of the developer community and the user community
* For HPC sites, if they adopt EESSI it becomes "critical infrastructure". Big sites are likely to look for influence.
* We plan on putting _almost_ everything that defines EESSI under GitHub but at the end of the day, for users, we are more like SaaS rather than software
* Does that complicate things for us?
* There's significant vendor interest in our (free) SaaS, how do we balance that with the fact that our contributors are mostly from academia
* Once stable the key contributions to EESSI are going to be the scientific application recipes, which are actually EasyBuild contributions.
* To measure the level of contribution of someone, you may have to look outside EESSI

### Legal stuff

* Should we worry about trademarking?
* We currently don't have a CLA...how bad is that?
* Licensing - we can licence the stuff on GitHub but are we exposed because we offer SaaS?

# Notes

* Copyright stuff is already prefectly valid _without_ being a true legal entity
* Businesses needing something concrete to talk to
* Patent trolling happens, need to able to deal with this.
* Can still sue an individual developer but would need to go throught the foundation first
* 3 possibilties
* Something like Apache Foundation
* In some EU countries "Foundation" has a very specific meaning
* Community first: Run by natural people who build and work on that code
* Volunteer part is crucial
* Linux Foundation
* Code first
* Run by sponsors
* More like a joint commercial venture
* Would accept targetted money for a specific task
* Software Conservatory Europe
* Sort of in the middle
* Mostly there to give you a safe (legal) space
* Agree collectively to a release (not tied to an individual)
* CLA
* Lots of variations on these
* If any one entity has the power to relicense (allows dual-licencing) greatly changes things
* Can have GPL _and_ a paid licence
* Means you create a legal entity that is **more powerful** than the community
* The second you introduce paid "volunteers", they will have to do all the boring stuff
* Patterns change between developers at that point

* Quick bang for buck is to join one of the above and then decide what to _really_ do in a couple of years
* Need to define our trademarks
* Need to put in place a CLA
* Has to visible, not necessarily signed, this gives you 90% coverage
* CLA bot gives you the other 10%
* Don't sweat about this, at that point you are covered (unless something explicit lands in your lap)
* Wilful damage is the one that is a problem, as long as people are reasonably aware then you should be ok
* CLAs don't put people off any more
* Employers are sometimes not aware that their employees are working on open-source code
* Generally is a win-win for everyone though, so this is (becoming) less of an issue
* What about an SLA?
* If the service is best effort, things are not so involved
* Can experiment with giving a low SLA, but leave room for higher levels
* Voluntary donations
* The moment you exchange money, there is liability.
* That collides with volunteer work
* Once someone starts paying for something, you are selling a product and you have legal obligations
* Would need things like "Error and Omissions Insurance"
* Someone has to "ship" the service
* Legal entity to handle this
* Nothing wrong with in-kind contributions
* Once you pay a volunteer for non-boring work, your other contributors will take a step back
* When companies are bought and sold, they trawl code and do comparisons and send nasty letters to open source projects
* What's not cheap and simple when creating a Foundation is the time you have to spend afterwards creating a processes, documenting them and ensuring they are followed
* Apache has an "incubator" which is worth looking at for information (probably too heavy for now)
* Projects for the incubator come to Apache Foundation and ask to join
* Aiming for a community that is likely to last for 5+ years and is not dominated by one person/company/country
* Linux Foundation works differently and will take "unhealthy" projects and improve them
*