Thanks for the explanation, Roman. I had no idea that policies for hosted 
binaries were stricter than for source code (other than the obvious effect on 
licensing when you bundle in dependencies).

Julian

> On Jun 5, 2017, at 7:47 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> 
> On Mon, Jun 5, 2017 at 7:34 PM, Julian Hyde <jh...@apache.org> wrote:
>> If the binaries are built from the released source code I don’t think we 
>> should restrict what the binaries do.
> 
> Well, but that's not how we treat licensing for example. For example
> -- there's plenty of ASF project that
> allow GPL licensed extension to be pulled into the build. That
> mechanics is part of the source code. However,
> as per our policy, we will not allow this kind of a convenience binary
> (containing GPL bits) to be hosted by
> ASF infrastructure.
> 
> Now, there's nothing wrong with those kinds of binaries -- and 3d
> parties host them all the time -- its just that
> WE at ASF decided that it wouldn't be aligned with what we do.
> 
> What I'm concerned about is that a combination of binaries hosted by
> ASF and a lack of opt-in AND an unsecure
> nature of the communication AND unclear data handling policies can
> potential make ASF liable if this kind of
> data ends up containing sensitive information and gets exploited.
> 
> IANAL, but I could see EU being especially strict here.
> 
>> The question is whether the community is aware of what the code is doing, 
>> and considers it to be in the best interests of the project.
>> 
>> The answer seems to be yes, and yes. I saw that the issue was discussed on 
>> dev@ignite[1], and had a corresponding JIRA case[2],
> 
> As for the discussion on JIRA, I expected the podling to listen to the
> advice given by one of the mentors:
>   
> https://issues.apache.org/jira/browse/IGNITE-775?focusedCommentId=14512075&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14512075
> but apparently that never happened.
> 
> Thanks,
> Roman.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Reply via email to