Re: Controlling the images used for the builds/releases

[Joan Touzet]

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
 wrote:





On Sep 13, 2020, at 2:55 PM, Joan Touzet  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.

Re: Controlling the images used for the builds/releases

[Jarek Potiuk]

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  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
> >  wrote:
> >
> >>
> >>
> >>> On Sep 13, 2020, at 2:55 PM, Joan Touzet  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  | Principal Software Engineer

M: +48 660 796 129 <+48660796129>
[image: Polidea] 

Re: Controlling the images used for the builds/releases

[Joan Touzet]

On 14/09/2020 11:54, Jarek Potiuk 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.


Taking CouchDB, shipping *just* the compiled .beam files is possible but 
helps no one because they require the functional Erlang interpreter 
alongside them. In other words, it is not a runnable asset.


I believe you can compile Erlang against 100% non-GPL assets, but this 
is not common. How many people don't use gnulibc on Linux?


Thus, double standard, allowing access to "binary packages" only for 
those languages where the compiled asset is, on its own, sufficient to 
run the program. This is not even true for e.g. Node.JS or Python, any 
time there would be (potentially GNU) libc bindings.



J


On Mon, Sep 14, 2020 at 5:47 PM Joan Touzet  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
 wrote:





On Sep 13, 2020, at 2:55 PM, Joan Touzet  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.

Re: Controlling the images used for the builds/releases

[Matt Sicker]

>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  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  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.
> >
> > G

Re: Controlling the images used for the builds/releases

[Jarek Potiuk]

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

Re: Controlling the images used for the builds/releases

[Jarek Potiuk]

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

Re: Controlling the images used for the builds/releases

[Dave Fisher]

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

Re: Controlling the images used for the builds/releases

[Dave Fisher]

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  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  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  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  wrote:
>>> 
 Hi Jarek,
 
 I'm about to head out for 3 weeks, so

Re: Controlling the images used for the builds/releases

[Jarek Potiuk]

Yep. I have maybe not intimate knowledge of all the licensing details but I
am really interested in licenses in general and I am rather familiar with
the doc (I put it also as reference in my proposal). I literally wanted the
proposal to use everything that is already there and come up with an
absolute minimum set of changes/
I think I am into getting feedback and comments. And the proposal is - I
think - still far from what we might eventually end up with.

To the point of Class B and Helm Charts - I tried to approach it in a more
general way than just Helm Charts but to figure out if we can actually come
up with some policy that will cover the wider set of "packaging" mechanisms
than just Helm Chart.
For example, the Container images (which actually are dependencies of the
Helm Charts) are the ones that are much more "problematic".

As I explained in the "context" of the proposal
https://cwiki.apache.org/confluence/display/COMDEV/Updates+of+policies+for+the+convenience+packages
pretty much any container contains GPL code. And there is no easy solution
with limiting those to Class B. Not with Python, not with Java, not with
most of the other language containers, no matter how hard we all try.

Also - if I understand correctly the worries of OOffice project. I think
the current proposal addresses pretty well the "size" of the packages. In
the proposal - I do not even propose to publish those all sources etc. It's
just that we give the users clear instructions on how they could (if they
are determined enough) build them all (from the legal and technical point
of view). And it could be "recursive" - as long as we know that
the dependency we point to, can be build and has instructions - we can
simply point to those instructions when we release the sources.

I know that there are many dependencies, but trying to understand what is
the whole OOffice build process is truly a Herculean effort. But I would
love to get to the bottom of the issue raised by Joan and try to adapt it.

So I'd really appreciate some help here. Would it be possible that you
point me to one or few particular dependencies/artifacts that you think
might have a problem with those assumptions:

- we can point the user to the sources of those artifacts
- we can tell them how they can build them
- they can do it legally and technically on their own using available tools
and platforms

I understand there might be some limitations like signing the .dmg images
for MacOS for example (Where you technically need an Apple-approved
certificate to distribute). But I think we are talking about power users,
who can disable any distribution limitations and work in "developer" mode.
If those needs some clarifications, we can add them.

J.


On Mon, Sep 14, 2020 at 8:23 PM Dave Fisher  wrote:

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