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/> >> > >> >
