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