+0A PMC member raised a justified concern regarding the Apache Spark trademark usage. Based on the linked discussion on @legal, that opinion seems to be weakly supported by the ASF Legal Affairs Assistant V.P.
As such, it shouldn't just be rejected, especially not because of our preference for discussion to be held in private or because it doesn't address a general case. In fact, given the special role that the alleged violator has in the project community (and a low potential for harm), we might prefer it to be public to avoid accusations of bias and conflicts of interest, although it is worth pointing out that it goes against an explicit ASF policy (https://www.apache.org/foundation/marks/reporting.html):
"It is a best practice to use the private@/projectname/.apache.org mailing list to discuss any reports of potential infringement first"
However, in the case of any trademark, license, or contract violation, it is important not only to establish that there is a legal basis for action but also to document the actual harm that it causes. For trademark violations, we're cornered primarily with customer (user) harm, and it hasn't been shown here or in the other thread that such a risk exists.
That being said, PMC asking a company to clearly indicate a modified version of the software is a soft action considering the alternative (passing the case to the ASF branding), which we are required to use in case a polite request fails.
On 6/19/23 06:59, Hyukjin Kwon wrote:
With the spirit of open source, -1. At least there have been other cases mentioned in the discussion thread, and solely doing it for one specific vendor would not solve the problem, and I wouldn't also expect to cast a vote for each case publicly. I would prefer to start this in the narrower scope, for example, contacting the vendor first and/or starting from a private mailing list instead of publicly raising this in the dev mailing list.On Sat, 17 Jun 2023 at 07:22, Dongjoon Hyun <dongjoon.h...@gmail.com> wrote:Here are my replies, Sean. > Since we're here, fine: I vote -1, simply because this states no reason for the action at all. Thank you for your explicit vote because this vote was explicitly triggered by this controversial comment, "I do not see some police action from the PMC must follow". > I would again ask we not simply repeat the same thread again. We are in the next stage from the previous discussion which identified our diverse perspective. The vote is the only official way to make a conclusion, isn't it? > - Relevant ASF policy seems to say this is fine, > as argued at https://lists.apache.org/thread/p15tc772j9qwyvn852sh8ksmzrol9cof I already disagreed with the above point, "this is fine", at https://lists.apache.org/thread/crp01jg4wr27w10mc9dsbsogxm1qj6co . > - There is no argument any of this has caused a problem > for the community anyway Shall we focus on legal scope on this vote because we are talking about ASF branding policy? For the record, the above perspective implies Apache Spark PMC should ignore ASF branding policy. > Given that this has stopped being about ASF policy, ... I want to emphasize that this statement vote is only about Apache Spark PMC's stance ("Ask or not Ask"). If the vote decides not to ask, that's it. Dongjoon. On Fri, Jun 16, 2023 at 2:23 PM Sean Owen <sro...@gmail.com> wrote: On Fri, Jun 16, 2023 at 3:58 PM Dongjoon Hyun <dongjoon.h...@gmail.com> wrote: I started the thread about already publicly visible version issues according to the ASF PMC communication guideline. It's no confidential, personal, or security-related stuff. Are you insisting this is confidential? Discussion about a particular company should be on private@ - this is IMHO like "personnel matters", in the doc you link. The principle is that discussing whether an entity is doing something right or wrong is better in private, because, hey, if the conclusion is "nothing's wrong here" then you avoid disseminating any implication to the contrary. I agreed with you, there's some value in discussing the general issue on dev@. (I even said who the company was, though, it was I think clear before) But, your thread title here is: "Apache Spark PMC asks Databricks to differentiate its Spark version string" (You separately claim this vote is about whether the PMC has a role here, but, that's plainly not how this thread begins.) Given that this has stopped being about ASF policy, and seems to be about taking some action related to a company, I find it inappropriate again for dev@, for exactly the reason I gave above. We have a PMC member repeating this claim over and over, without support. This is why we don't do this in public. May I ask which relevant context you are insisting not to receive specifically? I gave the specific examples (UI/logs/screenshot), and got the specific legal advice from `legal-discuss@` and replied why the version should be different. It is the thread I linked in my reply: https://lists.apache.org/thread/k7gr65wt0fwtldc7hp7bd0vkg1k93rrb This has already been discussed at length, and you're aware of it, but, didn't mention it. I think that's critical; your text contains no problem statement at all by itself. Since we're here, fine: I vote -1, simply because this states no reason for the action at all. If we assume the thread ^^^ above is the extent of the logic, then, -1 for the following reasons: - Relevant ASF policy seems to say this is fine, as argued at https://lists.apache.org/thread/p15tc772j9qwyvn852sh8ksmzrol9cof - There is no argument any of this has caused a problem for the community anyway; there is just nothing to 'fix' I would again ask we not simply repeat the same thread again.
-- Best regards, Maciej Szymkiewicz Web:https://zero323.net PGP: A30CEF0C31A501EC
OpenPGP_signature
Description: OpenPGP digital signature
