IMO something real is missing from this whole conversation. Does the ASF want to have successful projects? Honest question time. Would Tomcat have been successful if there had been source only downloads with no “official" runnable software? Were all those users for all those years compiling their own? No. They downloaded clearly official binaries. Does this page tomcat.apache.org tell an internet wonderer BEWARE…the binaries are not official? What about this one https://tomcat.apache.org/download-90.cgi … pretty sure the sources are the last thing on the page.
Was Maven successful because everyone built it? No. They downloaded what is clearly considered “official” binaries. This site http://maven.apache.org … what does it point out…unofficial binaries? No…download, install, run. NetBeans…not going to make it here on “unofficial" binary releases funny business. What company wants someone installing that on their system? Security policies anyone? Sorry, just the truth. httpd benefited from Linux distros binary distribution in this sense of releases as source, but if everyone had to “build” their httpd servers, it would not have been the success it has been; I think it is irrefutable. It’s success was not based on a bunch of admins who are not software engineers building it, nor was it built on web developers building C binaries; some of us maybe building ISAPI and NSAPI modules; that’s been a bit. This whole conversation is missing a crucial point, and it is does Apache want to continue to be successful? And, do folks really understand how it has been successful to date? It wasn’t just those of us who contribute code. It was also people using that code, and most of those folks did not compile it. Read this whole thread to this point. Does it even make sense? Is there a clear answer? It is just as confusing to this point as when the question was asked. It is still a bunch of indirect dancing around of how the users need binaries, but some language needs to be there to make sure they (users) understand it is unofficial, and not really from Apache like the source code, but some how “convenience” from “some magic place". It leaves off the one point that really matters in the end; users using software makes successful projects and brings and retains donations; simple calculation. Do people use untrusted software? Not in commercial settings. I think this is exactly why “binary releases are NOT endorsed by ASF” will not fly very far. There is a lot of time and resources wrapped up in these type conversations as well as Apache projects. Real clear guidance seems a must, and it has to be “real” and honest about what the decision means for successful projects. Thank you, Wade > On Nov 13, 2018, at 3:49 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote: > > Personally, given the amount of binary releases that are distributed off of > our very own infrastructure (and I'm not even counting our namespace > on things like Docker hub -- I'm just talking about the INFRA we run) I don't > think that the argument "binary releases are NOT endorsed by ASF" will > fly very far. > > I think the best defense for us is to, perhaps, position them as UGC, but > given the practices around existing PMC I don't think that would be easy to > do. > > So the question really boils down to -- how much of a liability this could > potentially be for us? > > > Thanks, > Roman. > On Tue, Nov 6, 2018 at 4:55 PM Daniel Shahaf <d...@daniel.shahaf.name > <mailto:d...@daniel.shahaf.name>> wrote: >> >> CC += legal-discuss@ since this really isn't an incubator-specific topic any >> more. The context is precompiled binary artifacts on >> https://www.apache.org/dist/. >> >> David Nalley wrote on Tue, Nov 06, 2018 at 17:06:50 -0500: >>> So let's assume a PMC (or PPMC) goes through the same process with >>> binaries in terms of reviewing, voting on, promoting, and publishing >>> to the world a binary release on behalf of the PMC and Foundation. >>> Binaries are published to the same location that source tar balls are >>> - are featured on download pages provided by the ASF. Perhaps even >>> with the situation being that people download the binary artifacts >>> from ASF resources tens of thousands, or maybe even millions of times >>> more frequently than the source tarballs. >>> >>> From that scenario I have some questions: >>> >>> 1. Would a reasonable person (or jury) suspend disbelief long enough >>> to consider our protestations that our 'releases' are source only, and >>> that as a Foundation we didn't release, propagate, promote, or >>> distribute the binaries in question? A rose by any other name..... >>> 2. Should the Board be taking an active interest in projects (release >>> managers?) who promote and publish their binaries in this manner on >>> our hardware? >>> 3. Is lack of Board action tantamount to tacit approval of this >>> behavior? Can we really claim ignorance? >>> 4. Should Infrastructure be actively monitoring and removing binaries >>> which find their way to dist.a.o/archive.a.o - especially since our >>> header for dist.a.o says that the directories contain releases of >>> Apache software? >>> 5. Should we be alerting individual release managers that publishing >>> convenience binaries exposes them individually to liability? >> >> 6. What alternative can we offer to projects that want to distribute >> binaries? >> Can the RM upload precompiled binaries to his https://home.a.o/~availid/ >> space? >> Can the project's download page link to them as the >> primary/canonical/recommended binaries? Can the project's download page link >> to the RM's binaries as one alternative among many (compare >> https://subversion.apache.org/packages#windows)? >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> <mailto:general-unsubscr...@incubator.apache.org> >> For additional commands, e-mail: general-h...@incubator.apache.org >> <mailto:general-h...@incubator.apache.org> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: legal-discuss-unsubscr...@apache.org > <mailto:legal-discuss-unsubscr...@apache.org> > For additional commands, e-mail: legal-discuss-h...@apache.org > <mailto:legal-discuss-h...@apache.org>
