Hi Jarek, I’m sure that you have reviewed https://www.apache.org/legal/resolved.html
I think that you might want to focus on Class B licenses in these discussions. It might help you to keep in a more limited scope and determine how to make compliant Helm Charts. The legal committee and VP are the ones making decisions about what is compliant. Regards, Dave > On Sep 14, 2020, at 9:30 AM, 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
