HI, > Recent posts [1] have accused Apache of being rigid, dogmatic. These > criticisms are, in my opinion, totally valid. And they matter, because we are > losing projects to other foundations. We are no longer the only bar in town > [2].
We don't actively seek out projects, projects that want to join the ASF ask to do so, because they think they are a good fit, that is by design. > This was a teachable moment. We could have said “Hey, this is a minor change, > let’s expedite the vote”. A good top-level project would have done that. > Should do that, out of respect for our contributors’ time. We — the incubator > PMC — did not do that. What the HELL are we thinking?! The 72 hours is a guideline and can be shorter if a (P)PMC has good reasons for doing so. Typically, that is used for security fixes, but I don’t see why it could not be used for minor changes - if the (P)PMC is sure that’s all that went into the new release candidate. > Last thought. Several IPMC members have sophisticated scripts to check > license headers, NOTICE files, keys. Those sophisticated scripts inevitably > catch things. And when they catch something the buzzer goes off and it’s > another 7 days. Two questions. There is nothing sophisticated about the scripts I use, it’s Apache Rat and find plus grep plus human observation. This has been covered in several Incubator talks if you want to look into it. Looking at the output of Apache Rat would have shown these issues. However if we wanted a 100% clean Apache Rat output for all projects that would be a huge amount of work, and often issues are hidden by having Rat exclusions too wide. > 1. Is it possible to automate this — create a .yaml file in each project, > and some standard scripts that can be called by any project, regardless of > its language or build system — to generate LICENSE, NOTICE etc. From experience, it’s not possible to automate all of this. You might be about to do 80%-90% of it, but that may be project dependent. There are many issues that automation will not catch, and/or it will also generate a lot of false positives. e.g. A mention of the GPL license somewhere might mean a) nothing or b) there’s an optional dependency that’s under the GPL license (which is fine) or c) there’s a dependency that is under a GPL license (not fine) or d) GPL-licensed code in the source release (not fine). Or, if a license of an image is not specified, how would automation know it’s OK to include it or not? It could be misisng a license from LICENSE, or something the project is using without permission, or it might not be an issue at all. > 2. If we don’t/can't automate this, what is the harm? I know that top-level > projects don’t do these checks. I know that Apache-licensed projects in other > foundations don’t do these checks. Where are the law-suits? If the harm is > not that great, why do we bother? Top-level projects should be doing these checks; releases do need to comply with ASF policy. Apache license projects outside of the ASF do not need to follow ASF policy on releases. We do this as a release needs to be an act of the foundation to provide legal protection to the PMC members who make the release. Think of it as travel insurance - you hopefully never have to use it, but when the situation comes up, you be glad you have it. And yes, ASF is subpoenaed or needs to respond to lawyers several times a year. Kind Regards, Justin --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
