Re: Controlling the images used for the builds/releases

[Jarek Potiuk <po...@apache.org>]

Hello, 

I finally had some time after Airlfow 2.0 release and I opened discussion about the policy in legal-discuss@apache.org:
 https://lists.apache.org/thread.html/r7c9ceb3d6c764119b14dfedb0e22957993d93cf529792c402aaa05fc%40%3Clegal-discuss.apache.org%3E

I propose we continue the discussion there

J.

On 2020/09/14 18:00:09, Dave Fisher <wa...@apache.org> wrote: 
> Hi Jarek,
> 
> I’ve yet to read your Cwiki, but I am on the OpenOffice PMC.
> 
> (1) If you wish to discuss our build processes for Centos, WIndows, and macOS please email dev@openoffice.apache.org. We are working towards our 4.1.8 release for the 20th Anniversary of Openoffice.org.
> 
> (2) If you wish to understand the many artifacts produced:
> 
> Source - https://dist.apache.org/repos/dist/release/openoffice/4.1.7/source/
> SDK - https://dist.apache.org/repos/dist/release/openoffice/4.1.7/binaries/SDK/
> User installation and language packs - https://dist.apache.org/repos/dist/release/openoffice/4.1.7/binaries/
> 
> There are currently 41 different languages in 4 linux flavors, 1 windows and 1 macOS.
> 
> Total installation and language binaries are 41*2*(1+1+4) = 492 binaries x 4 = 1968 files.
> 
> Note for macOS, we create dmg files, and for Windows Installer exe executables.
> 
> (3) Due to the huge size of all of our binaries OpenOffice is NOT distributed through the Apache Mirrors. Instead we are allowed to distribute through SourceForge.net
> 
> Regards,
> Dave
> 
> > On Sep 14, 2020, at 10:14 AM, Jarek Potiuk <Ja...@polidea.com> wrote:
> > 
> > Joan,
> > 
> > I read your comment and I have a kind request - hopefully you are not yet
> > out - you mentioned in the comment Open Office and artifacts that would not
> > fall into the criteria proposed. Could you please point us to one or two
> > examples of such artifacts and someone that could carry the discussion -
> > while you are away? I think I would like to understand what the problem is
> > but it might be difficult to answer your doubts without having some
> > specific examples that we can base our discussion on and someone who is at
> > least a bit familiar with the matter.
> > 
> > J.
> > 
> > 
> > On Mon, Sep 14, 2020 at 6:30 PM Jarek Potiuk <Ja...@polidea.com>
> > wrote:
> > 
> >> Very true Matt.
> >> 
> >> I think this is really a crucial part of the proposal to define the
> >> boundary between the Apache / Non-Apache artifacts (potentially with a
> >> different, non-ASF compliant license).
> >> 
> >> The "compiled" vs.  "packaged" that I proposed is one way of looking
> >> at it, rather simple and straightforward to understand, verify, and
> >> reason about. But I would love to hear other ideas - maybe some other
> >> communities and OSS organizations approached it already and they came
> >> up with some other ways of classifying it ?
> >> 
> >> One thing that is quite important here - we are not really talking
> >> about "releases" and we should continue avoiding the name. I have no
> >> doubt that proper release is .tar.gz signed and checksummed on
> >> Apache's SVN containing sources and instructions on how to build the
> >> software (including the convenience packages) using platforms and
> >> tools available. There are no other "releases" by ASF, and I think
> >> there should not be.
> >> 
> >> I keep on reminding it to myself when I proposed the changes, that
> >> "convenience packages" are not "official" ASF software releases so I
> >> think the policies there - however legal and "correct" do not have to
> >> be that strict.
> >> 
> >> I am not a lawyer to grasp all the implications - so I am really
> >> looking at the "crowd wisdom here" to understand all the consequences.
> >> I think we will never get a 100% correct and "compilable" policy (so
> >> to speak). My wife is a lawyer by education, so I know very well from
> >> her that "law does not compile" (which was a bit surprising to an
> >> engineer like me initially).
> >> 
> >> I think eventually - we will have to make some interpretations and
> >> assumptions, and eventually, the ASF might have to take some risks
> >> when reviewing and accepting such a proposal. But the risk-taking
> >> should be very well informed in this case so I think we should gather
> >> a lot of inputs and opinions on that.
> >> 
> >> J
> >> 
> >> 
> >> On Mon, Sep 14, 2020 at 6:08 PM Matt Sicker <bo...@gmail.com> wrote:
> >>> 
> >>> From a distribution standpoint, the point of these policies to me has
> >>> been to emphasize that anything we distribute here at Apache can be
> >>> safely used and copied under the terms of the Apache License. As such,
> >>> source releases have always been the target, though over time, Apache
> >>> has accumulated several end-user type projects that may or may not
> >>> have a developer audience that knows what to do with source code. The
> >>> binary distributions become a useful channel for projects so that
> >>> users can actually use the project without technical knowledge of
> >>> development environment setups and such. This raises a conundrum,
> >>> though, that nearly any non-trivial binary software artifact will
> >>> contain or link to code that is not distributed under the Apache
> >>> License, but it may be compatible (e.g., GPLv3 is compatible with
> >>> ALv2, but combining the two results in GPLv3 basically, not
> >>> ALv2+GPLv3; this doesn't change existing licenses of course). For our
> >>> end users downloading Apache artifacts, we've had a history of
> >>> publishing IP-safe source code that is easily used under the ALv2. I
> >>> think the historical problem behind why binary artifacts haven't been
> >>> raised to the same status involves clarifying the line between where
> >>> our artifacts end and a third party's begin. This is especially
> >>> apparent in languages where the reference implementation runtime is
> >>> GPL (e.g., OpenJDK, though that itself has an interesting history due
> >>> to Apache Harmony having been a thing at one point).
> >>> 
> >>> From a security standpoint, distributing binaries requires more
> >>> infrastructural security to respond to potential malware infections,
> >>> CVEs in dependencies, etc.
> >>> 
> >>> 
> >>> On Mon, 14 Sep 2020 at 10:54, Jarek Potiuk <Ja...@polidea.com>
> >> wrote:
> >>>> 
> >>>> Oh yeah. I start realizing now how herculean it is :). No worries, I am
> >>>> afraid when you are back, the discussion will be just warming up :).
> >>>> 
> >>>> Speaking of the "double standard" - the main reason really comes from
> >>>> licensing. When you compile something in that is GPL, your code starts
> >> to
> >>>> be bound by the licence. But when you just bundle it together in a
> >> software
> >>>> package - you are not.
> >>>> 
> >>>> So this is pretty much unavoidable to apply different rules to those
> >>>> situations. No matter what - we have to make this distinction IMHO. But
> >>>> let's see what others say on that.  I'd love to hear your thought on
> >> that,
> >>>> before you head out.
> >>>> 
> >>>> J
> >>>> 
> >>>> 
> >>>> On Mon, Sep 14, 2020 at 5:47 PM Joan Touzet <wo...@apache.org> wrote:
> >>>> 
> >>>>> Hi Jarek,
> >>>>> 
> >>>>> I'm about to head out for 3 weeks, so I'm going to miss most of this
> >>>>> discussion. I've done my best to leave comments in your document, but
> >>>>> just picking out one topic in this thread:
> >>>>> 
> >>>>> On 14/09/2020 02:40, Jarek Potiuk wrote:
> >>>>>> Yeah - I see the point and to be honest, that was exactly my
> >> original
> >>>>>> intention when I wrote the proposal. I modified it slightly to
> >> reflect
> >>>>> that
> >>>>>> - I think now after preparing the proposal that the "gist" of it is
> >>>>> really
> >>>>>> to introduce two kinds of convenience packages - one is the
> >> "compiled"
> >>>>>> package (which should be far more restricted what it contains due
> >> to
> >>>>>> limitations of licences such as GPL) and the other is simply
> >> "packaged"
> >>>>>> software - where we put independent software or binaries in a
> >> single
> >>>>>> "convenience" package but it does not have as far-reaching
> >>>>>> legal/licence consequences as compiled packages.
> >>>>>> 
> >>>>>> The criteria I proposed introduce an interesting concept - the
> >> recursive
> >>>>>> definition of "official" packages - that was the most "difficult"
> >> part
> >>>>>> to come up with. But I believe as long as the criteria we come up
> >> with
> >>>>> can
> >>>>>> be recursively applied to any binaries or reference to those
> >> binaries up
> >>>>> to
> >>>>>> the end of the recursive chain of dependencies and as long as we
> >> provide
> >>>>>> instructions on how to build those binaries by the "power" users, I
> >>>>> believe
> >>>>>> it should be perfectly fine to include such binaries in "packaged"
> >>>>> software
> >>>>>> without explicitly releasing all the sources for them.
> >>>>>> 
> >>>>>> So I tried to put it in the way to make it clear that the original
> >>>>>> limitations remain in place for the "compiled" package
> >> (effectively I am
> >>>>>> not changing any wording in the policy regarding those) but I
> >> (hope) make
> >>>>>> it clear that other limitations and criteria apply to "packaged"
> >> software
> >>>>>> using those modern tools like Docker/Helm but also any form of
> >>>>> installable
> >>>>>> packages (like Windows installers). I've also specifically listed
> >> the
> >>>>>> "windows installers" as an example package.
> >>>>> 
> >>>>> I don't like the double standard of "compiled" vs. "packaged"
> >> software.
> >>>>> It's hard to understand when to apply which, and creates an un-level
> >>>>> playing field. Not every ASF project can create both, and you're
> >> using a
> >>>>> different ruler for each. I realize it was your intent to avoid
> >> clouding
> >>>>> the water, and to apply stricter rules to one vs. the other, but I
> >> feel
> >>>>> this is just continuing the double-standard I previously mentioned,
> >>>>> albeit in a different form.
> >>>>> 
> >>>>> Good luck with the effort, and thanks for taking on this herculean
> >> task.
> >>>>> 
> >>>>> -Joan
> >>>>> 
> >>>>>> 
> >>>>>> J.
> >>>>>> 
> >>>>>> 
> >>>>>> On Mon, Sep 14, 2020 at 2:57 AM Allen Wittenauer
> >>>>>> <aw...@effectivemachines.com.invalid> wrote:
> >>>>>> 
> >>>>>>> 
> >>>>>>> 
> >>>>>>>> On Sep 13, 2020, at 2:55 PM, Joan Touzet <wo...@apache.org>
> >> wrote:
> >>>>>>>>> I think that any release of ASF software must have corresponding
> >>>>> sources
> >>>>>>>>> that can be use to generate those from. Even if there are some
> >> binary
> >>>>>>>>> files, those too should be generated from some kind of sources
> >> or
> >>>>>>>>> "officially released" binaries that come from some sources. I'd
> >> love
> >>>>> to
> >>>>>>> get
> >>>>>>>>> some more concrete examples of where it is not possible.
> >>>>>>>> 
> >>>>>>>> Sure, this is totally possible. I'm just saying that the amount
> >> of
> >>>>>>> source is extreme in the case where you're talking about a
> >> desktop app
> >>>>> that
> >>>>>>> runs in Java or Electron (Chrome as a desktop app), as two
> >> examples.
> >>>>>>> 
> >>>>>>> 
> >>>>>>> ... and mostly impossible when talking about Windows containers.
> >>>>>>> 
> >>>>>>> 
> >>>>>> 
> >>>>> 
> >>>> 
> >>>> 
> >>>> --
> >>>> 
> >>>> Jarek Potiuk
> >>>> Polidea <https://www.polidea.com/> | Principal Software Engineer
> >>>> 
> >>>> M: +48 660 796 129 <+48660796129>
> >>>> [image: Polidea] <https://www.polidea.com/>
> >>> 
> >>> 
> >>> 
> >>> --
> >>> Matt Sicker <bo...@gmail.com>
> >> 
> >> 
> >> 
> >> --
> >> 
> >> Jarek Potiuk
> >> Polidea | Principal Software Engineer
> >> 
> >> M: +48 660 796 129
> >> 
> > 
> > 
> > -- 
> > 
> > Jarek Potiuk
> > Polidea <https://www.polidea.com/> | Principal Software Engineer
> > 
> > M: +48 660 796 129 <+48660796129>
> > [image: Polidea] <https://www.polidea.com/>
> 
>