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 t
Just cross-posting the discussion at
https://lists.apache.org/thread.html/r8ff55d638c2efa1251636556881ef2e8a6305d19fddf184fcea96099%40%3Cdev.community.apache.org%3E
Would it be possible that move any discussion there? I have a feeling
dev@communty is a better place to discuss the subject and I th
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
abso
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
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
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 discussio
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 straightf
>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 sev
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 tha
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 t
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 m
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
> 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" bi
On 2020-09-13 5:19 p.m., Jarek Potiuk wrote:
Can you please make an inline comment in the document? the Cwiki allows
inline comments, just select a paragraph and comment it there. This is the
easiest way to keep it focused in the document. I am not sure if
understand the Open-Office specific th
Can you please make an inline comment in the document? the Cwiki allows
inline comments, just select a paragraph and comment it there. This is the
easiest way to keep it focused in the document. I am not sure if
understand the Open-Office specific things, i'd love to understand that
though (I use
HI Jarek,
Can you comment on one specific thing? In Proposal 1 you still leave the
text "...MUST only add binary/bytecode files". This is not possible for
convenience packages in many situations - for instance OpenOffice or
other languages - where providing a full release of a product requires
Just for your information - after a discussion in the ComDev mailing list.
I created a proposal for Apache Software Foundation to introduce changes to
the "ASF release policies", to make it clear and straightforward to release
"convenience packages" in the form of "software packaging" (such as Helm
Just to revive this thread and let you know what we've done in Airflow.
We merged changes to our repository that allow our users to rebuild all
images if they need to -using official sources. It's not very involved and
not a lot of code to maintain:
https://github.com/apache/airflow/pull/9650/
Nex
On Tue, Jun 23, 2020 at 2:26 AM Jarek Potiuk wrote:
>
> >
> > My understanding the bigger problem is the license of the dependency (and
> > their dependencies) rather than the official/unofficial status. For Apache
> > Yetus' test-patch functionality, we defaulted all of our plugins to off
> > be
>
> My understanding the bigger problem is the license of the dependency (and
> their dependencies) rather than the official/unofficial status. For Apache
> Yetus' test-patch functionality, we defaulted all of our plugins to off
> because we couldn't depend upon GPL'd binaries being available or g
> On Jun 22, 2020, at 6:52 AM, Jarek Potiuk wrote:
> 1) Is this acceptable to have a non-officially released image as a
> dependency in released code for the ASF project?
My understanding the bigger problem is the license of the dependency (and their
dependencies) rather than the official/unof
> Sure. Build tools can even be GPL, and something like a linter isn't a
> hard dependency for Airflow anyway. +1
>
Indeed.
> But we are just about to start releasing Production Image and Helm Chart
> > for Apache Airflow and I started to wonder if this is still acceptable
> > practice when - by
Hey Jarek, thanks for starting this thread. It's a thorny issue, for
sure, especially because binary releases are not "official" from an ASF
perspective.
(Of course, this is a technicality; the fact that your PMC is building
these and linking them from project pages, and/or publishing them out
Hello Everyone,
I have a kind question and request for your opinions about using external
Docker images and downloaded binaries in the official releases for Apache
Airflow.
The question is: How much can we rely on those images being available in
those particular cases:
A) during static checks
B)
24 matches
Mail list logo
