Cool. Thanks Bertrand - I am aware of some of those, but this list will be helpful so I can make some of the references to those in my proposal (and I encourage everyone else to do so). I am super-happy to merge yours with mine. I believe the "spirit" of those is rather similar. I am fully aware legal review should be done - I want now to get some initial feedback and see what controversies the proposal raises and polish it a bit, but I 100% understand the policies are binding for the ASF and the risk and legal side of it should be very carefully considered.
Note - I just run through a few of the comments we have there and just for the sake of keeping people informed on what has changed so far here are some "gists" of my changes comparing to the first draft: * there is an open question about the viability of putting all the instructions or scripts to build the binary dependencies into released sources. Giving the example of OpenOffice, CouchDB and Erlang which makes it next to impossible to do. So I proposed to explicitly say that any form of the instructions: scripts, manual instruction or POINTERS to the right instructions is fine. Simple HTTP link where you can find how to build an external OSS library should be perfectly fine. My ultimate goal is that whatever whenever the source .tar.gz package is created - the goal is that the user can get the sources and following the instructions (including the links to instructions) can - potentially rebuild the software legally. It might be a complex and recursive process (build a library to build a library) and at times those instructions might not work (as it is with all the instructions) but at least an attempt should be made to make it possible. * The "official" 3rd-party binary package is not a good name - I replaced it for now with the "maintained OSS" binary package. The idea behind it is that shortly - it should be open-source and it should be maintained. So while the name does not reflect all the subtleties of "maintained" and "OSS" but it reflects the spirit. I tried to make the "recursive" definition as much relaxed as possible (in terms of SHOULD vs. MUST except with the Licencing which is a MUST) * In pretty much all cases where I write about "best practices", they are not absolute requirements - so whenever possible they are SHOULD instead of MUST. I am very far from imposing all the best practices on all ASF projects - that will be impractical and stupid thing to do. I really treat those "best practices" as "beacons" - targets that we can have in mind but might never fully achieve them. And as long as we have good reason, not to follow those practices - by all means we do not have to. But if easy and possible, I see the best practices as a powerful message that improves the "Brand" of ASF in general from the user perspective. There are no "bonus points" for projects that follow it vs. those which decided not to in particular cases. But having those as "targets" for ASF projects is an important message. J, On Tue, Sep 15, 2020 at 12:25 PM Bertrand Delacretaz <bdelacre...@apache.org> wrote: > Hi, > > On Mon, Sep 7, 2020 at 10:24 AM Bertrand Delacretaz > <bdelacre...@apache.org> wrote: > ... > > ...* https://issues.apache.org/jira/browse/ASFP-23 (accessible to ASF > > Members) has links to related discussions... > > For the benefit of people who don't have access to that ticket, here's > a list of links that are public and can help inform this discussion. > > - > https://cwiki.apache.org/confluence/display/INCUBATOR/Distribution+Guidelines > mentions Maven, GitHub, Docker and other similar distribution > channels. The topic was discussed several times in the Incubator, > including > > https://lists.apache.org/thread.html/f614a20f82b010d152ce3871165841810c0db6c4de9d8a27e78b71d6@%3Clegal-discuss.apache.org%3E > > - LEGAL- tickets, https://issues.apache.org/jira/browse/LEGAL-270 , > https://issues.apache.org/jira/browse/LEGAL-427 , > https://issues.apache.org/jira/browse/LEGAL-323 (linked to a number of > others), more? > > - Reproducible builds (https://reproducible-builds.org/ , > http://maven.apache.org/guides/mini/guide-reproducible-builds.html ) > are also a way to improve trust in binaries. > > I also made a proposal a while ago about how we might handle these things: > > *** DRAFT TENTATIVE PROPOSAL ON HOW WE MIGHT EXPLAIN DISTRIBUTIONS **** > -ASF Releases consist of source code only > > -As a convenience, our PMCs often distribute binary packages along > with these releases, as attachments which are not considered part of > the release > > -We recommend that people build their own binaries from released code, > but it's a reality that many of them use the binaries that we > distribute > > -The only things we state about these binaries are that the PMC which > creates them believes they are the correct ones (with no guarantees) > and that the digests that we distribute are correct > > -Those digests are mentioned in the PMC approval votes for these > binaries, to allow people to look them up if desired > > -We strongly encourage our PMCs to produce reproducible builds as per > https://reproducible-builds.org/ > *** DRAFT TENTATIVE PROPOSAL ON HOW WE MIGHT EXPLAIN DISTRIBUTIONS **** > > I haven't found time to pursue it so far, and it might not be > implementable as is but hopefully it helps this discussion. > > If a draft policy is created based on that and/or Jarek's current > proposal, legal review will be needed before the ASF can activate it. > > -Bertrand > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > > -- +48 660 796 129
