Thanks for your thoughtful reply. It clarifies few things but we will also definitely wait until the lines/rules are more clearer and we (Airflow PMC) would be very happy to help shape the rules if needed.
On Wed, Sep 9, 2020, 13:26 Niclas Hedhman <[email protected]> wrote: > No changes have been decided on recently. > > If you have external dependencies that can be viewed as System > Requirements, then you don't need to provide your own build instructions. > Think; "Windows is a (optional) System Requirement" and what is reasonable > in that case. > > So Docker itself could be a System Requirement for some deployment > scenarios, but it is not unreasonable to say that some other external > system is required to be present. I am ignorant of what Helm is and can't > provide a definite answer. > > The licensing issue itself; for projects that are well established, you > can assume that they have their licensing in order. So if they say "MIT" > you should assume that their project complies and doesn't have GPL as a > dependency. For "private persons" the situation is quite often very > different. Most people don't care, and mix-n-match in incompatible ways. So > some extra digging should be done when depending on such projects. > > You should check sources, provide links to how those are built to binaries > and then assume the built binaries (docker images) correspond to the > sources. > > Not answers on specific questions, because I don't have enough insight in > details. > > HTH > Niclas > > On Wed, Sep 9, 2020, 12:57 Kaxil Naik <[email protected]> wrote: > >> Hi Niclas, >> >> I am glad to hear that the term "Convenience Binaries" is under review. >> >> Few things we were not clear >> or have some difference of opinion are: >> >> 1) Licensing >> >> a) Should we check all the binaries used in Dockerfiles for >> license-compliance? >> >> b) For Dockerfiles used in Helm Chart, is checking License for >> Dockerfiles enough, or should we also check the licenses of the binaries >> used by the Dockerfiles, how deep should we go? >> >> i.e Is checking the license of the Dockerfile enough or not >> >> c) If the answer for (b) is Yes, should we also then start thinking about >> checking license for the dependencies of our python dependencies that we >> use in our main project or trust the direct >> >> dependency? >> >> >> 2) Re-buildability (Sources) >> >> a) If a binary used in our Dockerfile or the external Dokcerfile used in >> our Helm Chart is built of another Open Source project that has their >> source code open with correct licenses and if >> instructions to rebuild are provided on their project, is that >> sufficient? Or do we need to provide helper scripts to our user to rebuild >> it the dependency of our dependency? >> >> >> >> >> Some of the points I mentioned above are still discussed in one of the >> threads in [email protected] but please let us know if something >> has already been decided on ASF level or else >> like Jarek said we would happy to discuss in-depth to sort this out on >> the org level. >> >> Regards, >> Kaxil >> >> On Wed, Sep 9, 2020 at 11:40 AM Ash Berlin-Taylor <[email protected]> wrote: >> >>> Jarek, you might want to check out https://reproducible-builds.org/ -- >>> it's come out of Debian with the aim to try and make binary builds of >>> .deb/software installed via .deb binary reproducible. >>> >>> I think you have less strict goals in mind than bit-for-bit identical >>> rebuilds of docker images? If so probably worth highlighting that as a >>> "non-goal" of your propsal (assuming it is a non-goal?) >>> >>> -a >>> >>> On Sep 9 2020, at 11:35 am, Jarek Potiuk <[email protected]> >>> wrote: >>> >>> > Hello Niclas, >>> > >>> > Thanks for that. >>> > >>> > I feel that this guidance already answers most of my questions. >>> > >>> > I volunteered to lead proposal discussion and preparation for the ASF >>> Board >>> > on this subject (and I am sure other PMCs from Airflow will also be >>> engaged >>> > a lot, so I hope we can work out some reasonable policies on that. I >>> hope >>> > to have the first draft proposal for discussion this week. I also >>> invited >>> > Apache Security team members who are already commenting on that >>> > thread, as >>> > I think those policies should at least provide guidance on all those >>> > topics: licensing, security, stability, and "rebuildability" (for the >>> lack >>> > of a better term). Those are IMHO super important if we want to >>> > address the >>> > needs of corporate users especially (looking at the requirements of the >>> > corporates we are working with). >>> > >>> > J >>> > >>> > >>> > On Wed, Sep 9, 2020 at 8:38 AM Niclas Hedhman <[email protected]> >>> wrote: >>> > >>> >> Hi everyone, >>> >> >>> >> The report submitted to the September Board meeting is requesting >>> guidance >>> >> on binary releases, such as Docker and Helm. I act as the board's >>> shepherd >>> >> of Airflow, and here to help if needed. >>> >> >>> >> First of all, Apache Software Foundation releases Open SOURCE >>> >> software, and >>> >> the source release is always the primary one. There are many reasons >>> for >>> >> this, such as security (one can know for sure what it contains), >>> >> jurisprudence (trace origin,++) and usability on platforms that the >>> >> community may not provide binaries for. >>> >> >>> >> Many communities provides additional binary releases, that has been >>> called >>> >> "Convenience Binaries", but the term is under review/reconsideration >>> as >>> >> they are for some communities (say, OpenOffice) the primary >>> >> artifacts for >>> >> the majority of users (OpenOffice users are typically not >>> >> developers). The >>> >> exact policies around this are being reviewed and worked on at the >>> moment. >>> >> Things like credentials to DockerHub or npm are for instance of >>> >> concern, as >>> >> well as the long-term stability of some of these distribution systems. >>> >> >>> >> That said; in general, as long as the binaries are buildable (with >>> >> instructions) and the product can be built and used without reliance >>> on >>> >> such external systems, then it is mostly OK and it is up to each >>> community >>> >> to decide if binaries are provided and how. If there are specific >>> questions >>> >> on release policy or special requests, then contact the >>> >> Infrastructure team >>> >> and ask if it is Ok with them. If there are more general >>> >> thoughts/feedback/discussion items in this space, ComDev is the place >>> to >>> >> approach. >>> >> >>> >> I will also try to do my best to answer questions here... >>> >> >>> >> Niclas Hedhman >>> >> >>> > >>> > >>> > -- >>> > >>> > Jarek Potiuk >>> > Polidea <https://www.polidea.com/> | Principal Software Engineer >>> > >>> > M: +48 660 796 129 <+48660796129> >>> > [image: Polidea] <https://www.polidea.com/> >>> > >>> >>
