While my experience with the ASF is limited, I think that the word "incubator" carries some meaning: it suggests a comfortable and inviting place for accelerated growth and maturation. In practice, the licensing aspects, while important, have consumed much of our bandwidth and slowed our actual progress. While I’m proud of the alternatives we initially found and/or developed to replace code and files with incompatible licenses, the last mile feels a bit like a moving target. I sincerely hope we will soon reach a point where a release takes weeks (which is still considerable) rather than months.
Best, Bertil > On 4 Dec 2024, at 21:18, Julian Hyde <jh...@apache.org> wrote: > > Thanks for the response, Justin. > > It's a topic for another thread, but I think the ASF and the Incubator is > facing an existential problem. Times have changed. We can't carry on doing > what we're doing. Good projects that would have been in the ASF five or ten > years ago are choosing to go elsewhere. We are driving at top speed towards a > wall. I don't have the energy to grab the steering wheel but let's not > pretend that everything is fine. > > On 2024/12/03 05:54:20 Justin Mclean wrote: >> 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 >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
