I have yet to see a legal reason why including binaries in packages is a bad thing. I’ve read the thread and the documents linked. In fact, it looks like it’s done specifically to avoid legal issues with copy left licenses. It’s very common for Apache to hold on to past policies at the expense of its projects’ users (see the slow transition to Git) all while claiming to do it for their benefit. It’s a decade later, the landscape has changed. We should absolutely protect the project legally but trying to guess the spirit of open source at the cost of users is of little benefit to all stakeholders.
In the end this discussion has moved to a list most of us don’t have access to and when asked to contribute the original reporter basically said “Your problem. You fix it” despite having a significant amount of experience in making builds “comply”. It’s also causing the delay of the projects first major release in 5 years, that many of this list have contributed large portions of their life too. That’s not very in the spirit of open source and I am disappointed again by the ASFs role in this — which continues to be ambiguous and at the cost of its users and developers. All that said, if we fix this great. If we don’t, eh. As long as we are legally compliant with the licenses of the dependencies we use we should value convenience for users over pedanticsm and statements that are a decade old. If there is a legal reason to change this it’s been explained poorly by the ASF and needs clarification. It also can only be so important if we are only catching it now after so many releases with the project. Jordan On Tue, Mar 30, 2021 at 7:19 AM Joshua McKenzie <jmcken...@apache.org> wrote: > FWIW I don't have access to what's being raised with the board so > effectively can't participate in this discussion beyond +1'ing Jirsa: > > Based on this point, I personally won't vote to approve a future release > > with binary packages, but I also strongly disagree with the assertion in > > that same past thread that it's worth nuking a 10+year history of > releases. > > That's the type of action that would severely diminish trust in the > > foundation. > > > We SHOULD look at what's required to rebuild PAST releases. > > > We should keep in mind what's best for our users. While avoiding including > compiled binaries that can't be verified as open source makes complete > sense from a "maximize safety to our users" perspective and can be done on > forward-going releases with minimal lift, we also have to consider how we > get There from Here on past releases. Pulling the rug out from our entire > user-base and releases after over a decade based on a conversation that > happened off-list (i.e. not on the C* dev list) 9 years ago is, hopefully > we can agree, not in our users' best interests nor the best interests of > this project's longevity. > > ~Josh > > On Tue, Mar 30, 2021 at 9:38 AM Mick Semb Wever <m...@apache.org> wrote: > > > > > > > It good to see you are taking action, but I think the situation is a > > > little more seriously that you may realise, I suggest you look at what > > > actions the board has taken in similar situations in the past. I'll > > update > > > the board agenda item to reflect the current situation. > > > > > > > > > The current board agenda item is still not accurate. The PMC members and > > the project are not ignoring the issue. > > > > Also, it would be nice if you could reference this thread, in both the > > board's agenda item and ML post, to allow people to have a complete view > of > > the discussion. > > > > I am happy to add information to the agenda item if you agree to it. > > Better yet, I suggest that we work together in public to word it. Most > > people on this list do not have access to the message. There is a > community > > here, and the way we work together to solve problems matters. > > >
