Really, I don't even know what they are talking about... Has anyone been informed about what they are trying to achieve?
What "significant push back from Legal and the Board" should we expect? Regards, Matthias Am 16.10.20 um 20:59 schrieb Joan Touzet: > Hi Jarek, > > On 16/10/2020 05:45, Jarek Potiuk wrote: > >> Joan - I hope you are back and we can continue the discussion. > Sorry, I just don't have the time or the energy to carry this further. > > I only brought up OO because it was one of the outliers, and the first > "user application" that came to mind when considering Apache projects > that deliver actual end user software vs. e.g. Java libraries. All > deference to Dave Fisher and the OO PMC; they have many concerns that > extend far beyond the terms of this policy. Apologies for pulling that > community into this thread. > > I'm glad my comments have given you some food for thought. I would > expect significant push back from Legal and the Board. That said, good > luck with your efforts. > > Please drop me from this thread. > > -Joan > >> I'd love >> to come up with the proposal that will include the specifics of OOffice >> releases. The proposal is here - >> https://cwiki.apache.org/confluence/display/COMDEV/Updates+of+policies+for+the+convenience+packages >> <https://cwiki.apache.org/confluence/display/COMDEV/Updates+of+policies+for+the+convenience+packages>. >> Happy to hear some responses on my comments/proposal >> Also anyone who is interested - I invite you to comment on the proposal. >> >> My plan is to - possibly - come up with a proposal that we all >> people here will be ok with (hopefully next week) and submit it to the >> legal team of ASF for review/opinions. >> >> J. >> >> >> On Tue, Sep 15, 2020 at 2:06 PM Jarek Potiuk <ja...@potiuk.com >> <mailto:ja...@potiuk.com>> wrote: >> >> 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 <mailto:bdelacre...@apache.org>> wrote: >> >> Hi, >> >> On Mon, Sep 7, 2020 at 10:24 AM Bertrand Delacretaz >> <bdelacre...@apache.org <mailto:bdelacre...@apache.org>> wrote: >> ... >> > ...* https://issues.apache.org/jira/browse/ASFP-23 >> <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 >> >> <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 >> >> <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-270> , >> https://issues.apache.org/jira/browse/LEGAL-427 >> <https://issues.apache.org/jira/browse/LEGAL-427> , >> https://issues.apache.org/jira/browse/LEGAL-323 >> <https://issues.apache.org/jira/browse/LEGAL-323> (linked to a >> number of >> others), more? >> >> - Reproducible builds (https://reproducible-builds.org/ >> <https://reproducible-builds.org/> , >> http://maven.apache.org/guides/mini/guide-reproducible-builds.html >> <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/ <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 >> <mailto:dev-unsubscr...@community.apache.org> >> For additional commands, e-mail: dev-h...@community.apache.org >> <mailto:dev-h...@community.apache.org> >> >> >> >> -- >> +48 660 796 129 >> >> >> >> -- >> +48 660 796 129 > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org >
smime.p7s
Description: S/MIME Cryptographic Signature
