Hi,
> One point that seems to be a big concern for most people is that the
> discussion is now happening on some mailing list where people do not have
> access.
There are people in this community that do have access so I would not be
concerned. Most of the conversation is on the legal discuss li
Hi Justin,
One point that seems to be a big concern for most people is that the
discussion is now happening on some mailing list where people do not have
access.
Will it be possible to have that discussion here rather than behind some
closed doors?
I believe that it will help to reduce some of th
Hi,
> I have yet to see a legal reason why including binaries in packages is a
> bad thing.
How do you review the release? How do you know there's not something that
incompatible with the ALv2 in it? With reproducible builds you might be able to
do this but I assuming that's not the case here.
Hi,
> The current board agenda item is still not accurate. The PMC members and
> the project are not ignoring the issue.
Voting +1 on a release with that issue IMO says otherwise, but others may have
differing opinions on that.
> Also, it would be nice if you could reference this thread, in bot
> That’s not very in the spirit of open source
> and I am disappointed again by the ASFs role in this — which continues to
> be ambiguous and at the cost of its users and developers.
>
Jordan, we share the same concerns and frustrations.
But, do please be careful not to divide the room. We are a
There is no legal reason; this was disavowed on LEGAL-288. The ostensible
reason is that Roy Fielding, who filed the papers of incorporation, interprets
the charter to require this. I don't think, however, anybody has challenged
this interpretation of the charter. I certainly do not interpret it
I have yet to see a legal reason why including binaries in packages is a
bad thing. I’ve read the thread and the documents linked. In fact, it looks
like it’s done specifically to avoid legal issues with copy left licenses.
It’s very common for Apache to hold on to past policies at the expense of
i
FWIW I don't have access to what's being raised with the board so
effectively can't participate in this discussion beyond +1'ing Jirsa:
Based on this point, I personally won't vote to approve a future release
> with binary packages, but I also strongly disagree with the assertion in
> that same pa
>
> It good to see you are taking action, but I think the situation is a
> little more seriously that you may realise, I suggest you look at what
> actions the board has taken in similar situations in the past. I'll update
> the board agenda item to reflect the current situation.
>
The current bo
As I'm sure you're aware, only a couple of people in the community are able to
follow or participate in board discussions without being expressly included.
On 30/03/2021, 09:51, "Justin Mclean" wrote:
Hi,
JFYI I've started a discussion about this on the board list [1]. Note that
that
I agree with Jeff. The inclusion of binary dependencies to assist developers
building from a source release doesn't seem like a deal breaker to me
personally as long as these are purely a convenience and not a requirement.
That said, the stance of the ASF as recorded in the incubator thread is
Hi,
JFYI I've started a discussion about this on the board list [1]. Note that that
list is for the board to conduct business on, so please take care in what you
post there.
Thanks,
Justin
1.
https://lists.apache.org/thread.html/rda27b6bc832d7e36eb12cc93343a358f5848bd10198e0165110ed4fc%40%3Cb
On Mon, Mar 29, 2021 at 3:45 PM Justin Mclean wrote:
>
> It good to see you are taking action, but I think the situation is a
> little more seriously that you may realise, I suggest you look at what
> actions the board has taken in similar situations in the past. I'll update
> the board agenda it
bject: Re: Download source release / binary files in source release
Hi,
> To the PMC: the next boarding meeting is on 21st April, so we have time to
> get this release out and probably more as well (hopefully with the fix
> for CASSANDRA-16391) before that date.
If I was a PMC me
Hi,
> To the PMC: the next boarding meeting is on 21st April, so we have time to
> get this release out and probably more as well (hopefully with the fix
> for CASSANDRA-16391) before that date.
If I was a PMC member here, I would reconsider making that release without
fixing this issue. I would
>
> I've also added a discussion item to the next board meeting.
>
Thanks.
To the PMC: the next boarding meeting is on 21st April, so we have time to
get this release out and probably more as well (hopefully with the fix
for CASSANDRA-16391) before that date.
To Justin: the board agenda item¹ a
> This is not a retrospective change just a clarification on what should be
> self evident.
This is a non-sequitur surely? Can something that is self-evident need
clarifying? Or do you suppose it is self-evident to all besides the feeble
intellects of this community?
I think a self-evident pol
Hi,
> Given the same agreement there that the ASF's docs are unclear on the
> topic, and having to rely upon a post from Roy in *some thread, I think it
> is safe to say we can (if need be) continue until those docs are made up to
> date. Also, I cannot see how the ASF can enforce anything retroac
>
> I thought you had indicated you were anyway raising this with the board?
>
> Either way, I don't personally see any issue with delaying the vote by a
> week or so if it will bring some official clarity to this issue, now it has
> been raised. How quickly can we expect to see changes reflected i
I thought you had indicated you were anyway raising this with the board?
Either way, I don't personally see any issue with delaying the vote by a week
or so if it will bring some official clarity to this issue, now it has been
raised. How quickly can we expect to see changes reflected in the off
HI,
> I recommend that the PMC continues its vote on 4.0-rc1.
In that case I'll need to raise this issue with theASF board.
Justin
-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail:
> I can only speak for myself, but I am happy to ensure future releases
> follow this policy once it is clearly stated as an official ASF policy by
> the official policy documentation.
>
+1
I recommend that the PMC continues its vote on 4.0-rc1.
With the understanding that the ASF updates the p
> I guess you are asking for something official from VP Legal Affairs or the
> ASF board? If so I can make that happen.
I would prefer the official policy pages to be updated to have a clear
statement on this, so this problem can be solved in perpetuity.
> IMO it does, the project can choose to
Hi,
> You are probably right, but as far as I am aware you are not an official
> source of ASF policy on this matter.
I am currently assistant VP legal affairs and have made changes to ASF policy
before, in particular to the release and distribution policy. I guess you are
asking for something
Hi Justin,
You are probably right, but as far as I am aware you are not an official source
of ASF policy on this matter. The official policy pages do not stipulate this,
so I would appreciate if you could get them updated to accord more clearly your
beliefs before the project makes the necessar
Hi,
I can say with 100% certainty that:
- ASF source releases cannot contain compiled code (jars, dlls or the like)
- ASF source releases cannot include Category B code compiled or not compiled
- ASF convenience binaries can contain Category B compiled code
In various roles at the ASF including P
> Including Category B binaries in a source release is mentioned in ASF policy
> here [1].
Sorry to keep banging the same drum, but I read this before our earlier emails,
and if this is the intended meaning it needs to be rewritten. I also doubt this
was the intended meaning of the original aut
Hi,
> This is a known problem. Please help out.
That is the reason of having those jars in the source release? Could it just be
replaced by a series of curl commands in a shell script?
I can help fix up the LICENSE and NOTICE files, but the inclusion of compiled
code in a source release is the
This is a known problem. Please help out.
It has been made mention of on most of the recent vote release threads, and
we have a ticket CASSANDRA-16391 open to deal with it (eta is immediately
after 4.0).
https://lists.apache.org/list.html?dev@cassandra.apache.org:lte=5y:VOTE%20lib
Hi,
> Again, I don't see this stated explicitly. Perhaps the guidance should be
> clarified if this is the intention?
Out documentation can be improved, PRs welcome. :-) It was thought that
something like this didn't need to be documented, but obviously it does. I'll
start a conversation on le
On Sat 27 Mar, 2021, 1:41 PM Benedict Elliott Smith,
wrote:
> > Because a source release could not contain compiled code
>
> Again, I don't see this stated explicitly. Perhaps the guidance should be
> clarified if this is the intention?
>
> On 27/03/2021, 01:59, "Justin Mclean" wrote:
>
> H
> Because a source release could not contain compiled code
Again, I don't see this stated explicitly. Perhaps the guidance should be
clarified if this is the intention?
On 27/03/2021, 01:59, "Justin Mclean" wrote:
Hi,
> Could you clarify why you think this is incompatible with ASF po
> I suggest you read the whole thread. The outcome was that it's OK to put jars
> in version control but not in a source release.
There was no outcome AFAICT? There was a suggestion that was explicitly
caveated as only a suggestion that required formal approval by VP Legal, which
does not seem
HI,
> The notion that these jars are "not open source" and must therefor not be
> used in the way they are intended is a preposterous stance
I suggest you read the whole thread. The outcome was that it's OK to put jars
in version control but not in a source release.
This has been discussed sev
To quote Niclas in the legal thread:
The notion that these jars are "not open source" and must therefor not be used
in the way they are intended is a preposterous stance
This seems to genuinely be against policy in a way that is profoundly
frustrating: the source of the project is available, th
Hi,
> Could you clarify why you think this is incompatible with ASF policy?
Because a source release could not contain compiled code (category A or
otherwise), if it does then it not open source. See for instance [1]. This is
why tools like Apache Rat look for certain types of binary files in r
> When I did download the the 3.11.10 release [2], I can see that it contained
> compiled binary files (jars), which I don't think is in line with ASF release
> policy.
Could you clarify why you think this is incompatible with ASF policy? AFAICT
the policy only stipulates that binary releases _
Hi,
I noticed the download page [1] contains links to convenience binaries but not
to the actual release. I can see that the source is in the place on the mirrors
but there's not an obvious link to it.
When I did download the the 3.11.10 release [2], I can see that it contained
compiled binary
38 matches
Mail list logo
