Hello, I finally had some time after Airlfow 2.0 release and I opened discussion about the policy in legal-disc...@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 <w...@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 d...@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 <jarek.pot...@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 <jarek.pot...@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 <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 > >> > > > > > > -- > > > > Jarek Potiuk > > Polidea <https://www.polidea.com/> | Principal Software Engineer > > > > M: +48 660 796 129 <+48660796129> > > [image: Polidea] <https://www.polidea.com/> > >