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 <boa...@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 <jarek.pot...@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 <woh...@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 > > > > <a...@effectivemachines.com.invalid> wrote: > > > > > > > >> > > > >> > > > >>> On Sep 13, 2020, at 2:55 PM, Joan Touzet <woh...@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 <boa...@gmail.com> -- Jarek Potiuk Polidea | Principal Software Engineer M: +48 660 796 129
