Keep in mind that legal doesn’t set policy. That’s the board. Legal helps inform the board (and whoever else) about the risks of different legal choices. Small nitpick, but keep in mind that legal isn’t here to block us. They’re here to help us understand the risks of which policy we choose to enact.
On Sat, Oct 17, 2020 at 03:04 Jarek Potiuk <ja...@potiuk.com> wrote: > Good. So let me try to contact the legal first and try to see what they > say. I indeed had comments that it will be difficult to get through the > approval process, but I am eager to try this and happy to lead the effort. > I think if I get at least a supportive voice from several projects who also > would like to publish helm charts and images, that would be great - and > make the case stronger. I perfectly understand that any such change is a > serious matter and that there will be some push-back (as it is on any > change that involves some legal consequences). I do expect quite some > scrutiny and long process of getting there, possibly even dropping the idea > altogether if there will be some strong case against my proposal - I am not > a lawyer so I might be very wrong with my licence/legal understanding (and > since ASF is a US-based company, it's not even my native Polish Law system > that is involved here). But I am willing to try anyway. > > Dave says about perfectionism being an enemy. But I think it's important to > understand both the benefits and constraints coming from belonging to ASF > and where there are legal matters involved, I treat it very, very > seriously. > When I became PMC I was informed by ASF that they indemnify me from any > legal consequences of decisions made regarding releasing the software, > PROVIDING that I follow the policies. > > As we are nearing to release Airflow 2.0. Airflow is a very > corporate/enterprise-centric software. It is used by pretty much all > Fortune 100 companies rather heavily and for very serious stuff and > processing really serious amounts of serious data (including a lot of > companies that are processing it for COVID-related data crunching). > > I would love the ASF to both - hold their promise of indemnifying me and > other PMC members, as well as give us the policies that allow us to operate > efficiently, legally for our project as PMC and simply that we are not > afraid to make decisions which might have heavy legal consequences for us. > The current situation where the boundaries are rather blurred, is not very > PMC-friendly. I actually spoke about it at the ApacheCon at my "Welcoming > community strengthen the Apache Way" talk two weeks ago (I hope it will be > released soon) that the community should be welcoming to all the members. > Those members being users, contributors, committers, PMC, companies using > the software, companies that are building their business on the Apache > Software, but also - PMCs who have legal responsibilities. "Community over > code" is the ASF motto and I think it is important to keep it in mind. > > I am not even sure myself if I am the only one who feels the disconnection > between reality and the current policies, that's why I started the thread > here. And I am happy to invest quite some personal time to hash it out and > work together with the Legal, Board or whoever will be involved. The more > PMCs will at least not object or - better - understand and support me in > that, the stronger case we can make to the Legal and Board. > > J. > > > On Fri, Oct 16, 2020 at 9:10 PM Matthias Seidel < > matthias.sei...@hamburg.de> > wrote: > > > 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 > > > > > > > > > -- > +48 660 796 129 > -- Matt Sicker <boa...@gmail.com>
