[this announcement is available online at https://s.apache.org/tmi6 ]
by Bertrand Delacretaz I became active in the ASF in 2001 via Gianugo Rabellino -- he was the one who started the discussions with Apache Fop about me donating the jfor XLS-FO to RTF converter that I had developed earlier. It was already too late to uninvent RTF which is a terrible format, but I digress. I am currently a member of the Board of Directors of the ASF and have been doing a lot of thinking (and presentations) about what makes the ASF tick in terms of collaboration and Shared Neurons. Section 12.1 of the Apache Bylaws https://www.apache.org/foundation/bylaws describes the legal protection that the Apache Software Foundation provides to our directors, officers and members. I'm not a lawyer by far, however, and that language is a bit hard for me to parse, so I thought I'd try to clarify what this means for our contributors and learn more about it in the process. If you go into detail there's certainly more to it but I think the items below are the absolute basics that every PMC member https://www.apache.org/foundation/how-it-works.html should understand in order to benefit from the legal shield that the Foundation provides. What is a "Legal Shield" ? An important goal of the Apache Bylaws and policies is to isolate our contributors from any legal action that might be taken against the Foundation, if they act as specified in those policies. That's what we mean by "legal shield": a way for our individual volunters to be sheltered from legal suits directed at the Foundation's projects, as mentioned in our "How the ASF works" document https://www.apache.org/foundation/how-it-works.html . Acts of the Foundation The first thing is to make sure our software releases are "Acts of the Foundation" as opposed to something that people do in their own name. This is natural if we follow our release policy https://www.apache.org/legal/release-policy.html , which defines a simple release approval process for releasing source code that makes the project's PMC https://www.apache.org/foundation/how-it-works.html responsible for the release, as opposed to our individual contributors and release managers. This means that if the released software is ever involved in legal action and someone has to testify or produce information as part of a subpoena, or worse, it's the Foundation which is in charge of that and not our individual contributors. These things happen from time to time, not very often but they can represent a lot of work and aggravation that none of us are looking for. The 2011 subpoena to Apache around Java and Android http://www.groklaw.net/articlebasic.php?story=20110509221136468 is just one example of that. Produce documents reflecting all communications between someone and Apache, how fun is that? The goal of our release process is to make it very clear what an Apache Release is, and also clarify that anyone using our software in other ways, by getting it directly from our code repositories for example, does so at their own risk. If it's not an Apache Release we didn't give it to them, they grabbed it on their own initiative and have to accept the consequences of that. The Rest is for Contributors This leads to a second and related item: developer builds, which happen much more often than releases, often daily, and that people can easily download and use. Those builds are meant for contributors to our projects, to use in development and testing as part of their contribution activities. To avoid any confusion, it is important to clearly label them as such, and to draw a clear line between them and official Apache Releases. They should only be advertised in places where developers who are part of our communities (as opposed to the general public) can see them, and with suitable disclaimers. In our world of continuous deployment and automated builds, the lines between what's a release and what's just tagged code that works for someone are often blurred. That's totally fine from a technical point of view, and often desirable when one wants to move fast, but we shouldn't forget about the possible legal implications ot distributing software. Let's make sure we take advantage of the well-designed Apache Legal Shield that the Foundation provides to us, by strictly following our release policy and clearly specifying what is what in terms of downloadable software. I never thought I'd write a blog post on a legal topic, so here's the FUN DISCLAIMER: As mentioned, I am not a lawyer by far, and the above should not be considered legal advice - just a pragmatic view that can hopefully help our contributors better understand the related issues. For legal advice, consult your own legal advisor! And if you're thirsty after reading all this, get a drink and give a toast to the ASF and its founders! Many thanks to the fellow Apache members who provided feedback and additional ideas for this post. . . . Bertrand Delacretaz works as a Principal Scientist with the Adobe Research team in Basel, Switzerland. He spends a good portion of his time advocating and implementing Open Development as a way to make geographically dispersed teams more efficient and more fun for his coworkers. Bertrand is also an active Member of the Apache Software Foundation, currently on his tenth term on the Foundation's Board of Directors (Fiscal Year 2018-2019). = = = "Success at Apache" is a monthly blog series that focuses on the processes behind why the ASF "just works" https://blogs.apache.org/foundation/category/SuccessAtApache = = = NOTE: you are receiving this message because you are subscribed to the [email protected] distribution list. To unsubscribe, send email from the recipient account to [email protected] with the word "Unsubscribe" in the subject line.
