* rust non-free-compatible trademark @ 2022-07-17 15:28 lkcl 2022-07-17 16:25 ` Richard Biener ` (2 more replies) 0 siblings, 3 replies; 31+ messages in thread From: lkcl @ 2022-07-17 15:28 UTC (permalink / raw) To: GCC developers with the recent announcement that rust is supported by gcc has it been taken into consideration that the draconian (non-free-compatible) requirements of the rust Trademark make the distribution of the gcc compiler Unlawful? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013920 if the word "rust" is entirely removed from the gcc source code then there is no problem whatsoever (recall: "iceweasel"). l. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: rust non-free-compatible trademark 2022-07-17 15:28 rust non-free-compatible trademark lkcl @ 2022-07-17 16:25 ` Richard Biener 2022-07-17 16:47 ` lkcl 2022-07-17 18:57 ` Alexandre Oliva 2022-07-17 16:31 ` Mark Wielaard 2022-07-18 14:30 ` lkcl 2 siblings, 2 replies; 31+ messages in thread From: Richard Biener @ 2022-07-17 16:25 UTC (permalink / raw) To: lkcl; +Cc: GCC developers > Am 17.07.2022 um 17:29 schrieb lkcl via Gcc <gcc@gcc.gnu.org>: > > with the recent announcement that rust is supported by gcc > has it been taken into consideration that the draconian (non-free-compatible) > requirements of the rust Trademark make the distribution of the gcc > compiler Unlawful? > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013920 > > if the word "rust" is entirely removed from the gcc source code then > there is no problem whatsoever (recall: "iceweasel"). We’ll call it gust. Richard > > l. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: rust non-free-compatible trademark 2022-07-17 16:25 ` Richard Biener @ 2022-07-17 16:47 ` lkcl 2022-07-17 18:24 ` Richard Kenner 2022-07-17 18:57 ` Alexandre Oliva 1 sibling, 1 reply; 31+ messages in thread From: lkcl @ 2022-07-17 16:47 UTC (permalink / raw) To: Richard Biener; +Cc: GCC developers On Sun, Jul 17, 2022 at 5:25 PM Richard Biener <richard.guenther@gmail.com> wrote: > > if the word "rust" is entirely removed from the gcc source code then > > there is no problem whatsoever (recall: "iceweasel"). > > We’ll call it gust. love it! the puns i would have recommended would have been based on "iron oxide". please bear in mind: under Trademark Law, as developers, you *must* not make "announcements" saying "we *are* changing the name from rust to gust". this creates "Confusion" for which you become directly and legally liable and responsible. *users* are permitted to go, "oh look, errr there's this thing called gust and the source code compiles for rust". just as with the Java Trademark, you as developers can say "gust is compatible with the rust language" but you *cannot* say "gust is compatible with rust". Trademarks are a bitch. get legal advice. l. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: rust non-free-compatible trademark 2022-07-17 16:47 ` lkcl @ 2022-07-17 18:24 ` Richard Kenner 0 siblings, 0 replies; 31+ messages in thread From: Richard Kenner @ 2022-07-17 18:24 UTC (permalink / raw) To: luke.leighton; +Cc: gcc, richard.guenther > just as with the Java Trademark, you as developers can say "gust is > compatible with the rust language" but you *cannot* say "gust is > compatible with rust". Note that trademarks are adjectives, not nouns (and only apply to specific nouns, so I'm not sure what you mean here. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: rust non-free-compatible trademark 2022-07-17 16:25 ` Richard Biener 2022-07-17 16:47 ` lkcl @ 2022-07-17 18:57 ` Alexandre Oliva 1 sibling, 0 replies; 31+ messages in thread From: Alexandre Oliva @ 2022-07-17 18:57 UTC (permalink / raw) To: Richard Biener via Gcc; +Cc: lkcl, Richard Biener On Jul 17, 2022, Richard Biener via Gcc <gcc@gcc.gnu.org> wrote: > We’ll call it gust. How about "giust"? (GNU Implementation of...) so that it sounds like https://just-lang.org/ -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org> ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: rust non-free-compatible trademark 2022-07-17 15:28 rust non-free-compatible trademark lkcl 2022-07-17 16:25 ` Richard Biener @ 2022-07-17 16:31 ` Mark Wielaard 2022-07-17 17:06 ` lkcl 2022-07-18 7:09 ` David Brown 2022-07-18 14:30 ` lkcl 2 siblings, 2 replies; 31+ messages in thread From: Mark Wielaard @ 2022-07-17 16:31 UTC (permalink / raw) To: lkcl; +Cc: GCC developers Hi Luke, On Sun, Jul 17, 2022 at 04:28:10PM +0100, lkcl via Gcc wrote: > with the recent announcement that rust is supported by gcc There is just a discussion about whether and how to integrate (portions) of the gccrs frontend into the main gcc repository. Nobody claims that means the rust programming language is supported by gcc yet. There is a lot of work to be done to be able to claim that. > has it been taken into consideration that the draconian (non-free-compatible) > requirements of the rust Trademark make the distribution of the gcc > compiler Unlawful? > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013920 That looks to me as an overreaching interpretation of how to interpret a trademark. I notice you are the bug reporter. It would only apply if a product based on gcc with the gccrs frontend integrated would claim to be endorsed by the Rust Foundation by using the Rust wordmark. Just using the word rust doesn't trigger confusion about that. And trademarks don't apply when using common words to implement an interface or command line tool for compatibility with a programming language. If you are afraid your usage of gcc with the gccrs frontend integrated does cause confusion around the Rust word mark then I would suggest contacting the Rust Foundation to discuss how you can remove such confusion. Probably adding a README explicitly saying "this product isn't endorsed by and doesn't claim to be endoresed by the Rust Foundation" will be enough. Good luck, Mark ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: rust non-free-compatible trademark 2022-07-17 16:31 ` Mark Wielaard @ 2022-07-17 17:06 ` lkcl 2022-07-17 17:41 ` Mark Wielaard 2022-07-18 7:09 ` David Brown 1 sibling, 1 reply; 31+ messages in thread From: lkcl @ 2022-07-17 17:06 UTC (permalink / raw) To: Mark Wielaard; +Cc: GCC developers On Sun, Jul 17, 2022 at 5:31 PM Mark Wielaard <mark@klomp.org> wrote: > > Hi Luke, > > On Sun, Jul 17, 2022 at 04:28:10PM +0100, lkcl via Gcc wrote: > > with the recent announcement that rust is supported by gcc > > There is just a discussion about whether and how to integrate > (portions) of the gccrs frontend into the main gcc repository. Nobody > claims that means the rust programming language is supported by gcc > yet. There is a lot of work to be done to be able to claim that. as i just replied to Richard, my understanding is that your careful usage of wording there is Lawful ("the rust programming language is supported by gcc" rather than "*rust* is supported by gcc"). > > has it been taken into consideration that the draconian (non-free-compatible) > > requirements of the rust Trademark make the distribution of the gcc > > compiler Unlawful? > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013920 > > That looks to me as an overreaching interpretation of how to interpret > a trademark. Trademarks are a bitch. if no explicit License is given, then "default" Trademark Law applies, where you must seek permission for all and any distribution. if the License *does* exist and does not explicitly grant a Permission, then, exactly like Copyright Law, you must explicitly seek it. you have to be *really* careful here, particularly given that the Mozilla Foundation is attempting a poor-man's "Certification Mark". they have defined the Trademark as requiring "language compatibility". which is perfectly reasonable given that they don't want end-users to be complaining "i can't compile my program" or worse, "my program broke, rust is supposed to be secure, whom do i sue". Uses that require explicit approval # Distributing a modified version of the Rust programming language [or the Cargo package manager] with modifications other than those permitted above and calling it Rust or Cargo requires explicit, written permission from the Rust Foundation. given that gcc is *entirely implementing* the rust programming language (from scratch) and given that that implementation is not in fact implemented by the Rust Foundation (the Trademark Holders themselves) but by the gcc developers, then by definition *every* single line of source code constitutes "a patch", and according to the Trademark License they (the Rust Foundation) require that you seek explicit approval for its distribution. (i.e. the *entire* gccrs source code is "a modified version of the rust programming language") distribution in this particular case would be: * all tarballs under the gcc.org domain name * all git repositories under the same * all git repositories created by all gcc developers so, yes, you've enacted distribution, and enabled and empowered others to engage in distribution - sorry to have to inform you of this (i trust you won't engage in "Shooting-Messenger-Syndrome") but, how can i put this... if you check with a good - and i do mean good - Trademark Lawyer, you'll likely be advised that you're legally liable, here. checking that is of course your responsibility, not mine. > If you are afraid your usage of gcc with the gccrs frontend integrated > does cause confusion around the Rust word mark then I would suggest > contacting the Rust Foundation to discuss how you can remove such > confusion. that would not be my responsibility, but yours [i'm assuming you're a gcc developer?] only if *i* were to engage in *distribution* of gcc with gccrs frontend integration would *i* become concerned, and i appreciate the reminder/prompting from you that, at some point in the near future, this will actually occur. sigh. to that end i would strongly recommend and advocate that the gccrs frontend be a dynamic-loadable plugin into gcc, so that it can be optionally excluded. or, as Richard suggested, begin calling it "gust". gccgust frontend. (but don't for goodness sake put anywhere "we ARE renaming all uses of rust to gust in gcc".) l. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: rust non-free-compatible trademark 2022-07-17 17:06 ` lkcl @ 2022-07-17 17:41 ` Mark Wielaard 2022-07-17 18:11 ` lkcl ` (2 more replies) 0 siblings, 3 replies; 31+ messages in thread From: Mark Wielaard @ 2022-07-17 17:41 UTC (permalink / raw) To: lkcl; +Cc: GCC developers Hi Luke, On Sun, Jul 17, 2022 at 06:06:45PM +0100, lkcl via Gcc wrote: > given that gcc is *entirely implementing* the rust programming > language (from scratch) and given that that implementation is not in > fact implemented by the Rust Foundation (the Trademark Holders > themselves) but by the gcc developers, then by definition *every* > single line of source code constitutes "a patch", and according to > the Trademark License they (the Rust Foundation) require that you > seek explicit approval for its distribution. I think you are misinterpreting when you need a trademark license for usage a word mark in an implementation of a compiler for a programming language. Note that gcc used to come with a full implementation of the Java programming language, compiler, runtime and core library implementation (for which I was the GNU maintainer). None of that required a trademark license because the usage of the word java was just for compatibility with the java programming language. And since there was no claim of being or distributing Java(tm). The same is true for Rust(tm) and the gccrs frontend. Also note that the Rust Foundation is aware of the work and has already integraeted parts of gcc through another alternative implementation (based on libgccjit). As far as we know thy have no problem with either alternative implementation of the Rust programming language. Cheers, Mark ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: rust non-free-compatible trademark 2022-07-17 17:41 ` Mark Wielaard @ 2022-07-17 18:11 ` lkcl 2022-07-17 18:29 ` lkcl 2022-07-17 18:28 ` Richard Kenner 2022-07-17 18:54 ` Alexandre Oliva 2 siblings, 1 reply; 31+ messages in thread From: lkcl @ 2022-07-17 18:11 UTC (permalink / raw) To: Mark Wielaard; +Cc: GCC developers On Sun, Jul 17, 2022 at 6:41 PM Mark Wielaard <mark@klomp.org> wrote: > I think you are misinterpreting when you need a trademark license for > usage a word mark in an implementation of a compiler for a programming > language. i'm aware of the difference. i mentioned this in my first reply to Richard (and covered it briefly in my reply to you as well) > Note that gcc used to come with a full implementation of the > Java programming language, compiler, runtime and core library > implementation (for which I was the GNU maintainer). None of that > required a trademark license because the usage of the word java was > just for compatibility with the java programming language. yes. i mentioned that example in my reply to you and in my separate reply to Richard: you may have missed it. that would likely be down to the difference in the Java Trademark License and the Rust Trademark License. with the wording the Rust Trademark License has attempted to create a poor-man's Certification Mark. Certification Mark Law is an advanced variant of Trademark Law covering Standards Compliance. > And since > there was no claim of being or distributing Java(tm). The same is true > for Rust(tm) and the gccrs frontend. this would be perfectly fine if the Rust Foundation had not explicitly worded the Trademark License in terms of a poor-man's Certification Mark. i gave the relevant section that you can pass over to appropriate Legal Counsel. i leave it with you as i am just a "reasonably well-informed non-lawyer messenger" here. > Also note that the Rust Foundation is aware of the work and has > already integraeted parts of gcc through another alternative > implementation (based on libgccjit). As far as we know thy have no > problem with either alternative implementation of the Rust programming > language. then that needs to be put into writing and made public. only the Trademark Holder may do that - not you. otherwise if you claim something and it turns out not to be true, you can be sued for misrepresentation. did i say Trademarks are a pig already? l. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: rust non-free-compatible trademark 2022-07-17 18:11 ` lkcl @ 2022-07-17 18:29 ` lkcl 2022-07-17 22:59 ` Mark Wielaard 0 siblings, 1 reply; 31+ messages in thread From: lkcl @ 2022-07-17 18:29 UTC (permalink / raw) To: Mark Wielaard; +Cc: GCC developers ah. right. sorry Mark i missed something. whilst you *as developers* have been in contact with the Rust Foundation and presumably have private assurances that your use of the Trademarked word "rust" is Authorised under License (through either implication or by actual explicit approval) absolutely nobody else does. all *new* gcc developers for example who have *not* been party to those private conversations may not safely assume that they are part of any such explicit or implicit consent. and given that literally anyone in the world may pick up the gcc source code and consider themselves to become a developer (as permitted by the GPL) that's a serious concern. in addition to that, even if you as developers have indeed been explicitly or implicitly granted a Trademark License that does *not* extend to *Distributors* of gcc and i again refer you to the wording that i copied here, and to the debian bugreport. i appreciate that this is a bloody nuisance. i do however expect the Rust Foundation to get their act together and act Reasonably and Fairly to sort out the mess they've accidentally created. after all, Trademarks do have value in FOSS Projects, to protect them from harm in ways that Copyright Licenses cannot touch. it's just rather unfortunate that they're really not well-understood, not even by Lawyers! l. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: rust non-free-compatible trademark 2022-07-17 18:29 ` lkcl @ 2022-07-17 22:59 ` Mark Wielaard 2022-07-17 23:07 ` lkcl 2022-07-17 23:55 ` Richard Kenner 0 siblings, 2 replies; 31+ messages in thread From: Mark Wielaard @ 2022-07-17 22:59 UTC (permalink / raw) To: lkcl; +Cc: GCC developers Hi Luke, On Sun, Jul 17, 2022 at 07:29:22PM +0100, lkcl wrote: > whilst you *as developers* have been in contact with the Rust Foundation > and presumably have private assurances that your use of the Trademarked > word "rust" is Authorised under License (through either implication or by > actual explicit approval) absolutely nobody else does. As far as I know all discussions have been in public. The Rust Foundation is aware of the gccrs frontend and other "unofficial" implementations. Using the word "rust" in the implementation of the gccrs frontend doesn't need any "Authorization under License". Normal use of a word isn't something that Trademarks prevent. > i appreciate that this is a bloody nuisance. i do however expect the > Rust Foundation to get their act together and act Reasonably and > Fairly to sort out the mess they've accidentally created. I believe the Rust Foundation is reasonable. We aren't using the word mark "Rust" in a way that needs any trademark license. And even if we did the Rust Foundation allows all usage of the word mark as long as you don't deliberately try to confuse about (commercially) shipping a product called "Rust" that is officially endorsed by the Rust Foundation. If the Rust Foundation really believed that some of the marketing we do around the gccrs frontend is confusing they would contact us and if they are reasonable we can adjust the messaging (we can be reasonable too). The best advice I can give you is to listen to what the Rust Foundation itself says about their trademark: Please do not approach users of the trademarks with a complaint. That should be left to the Rust Foundation and its representatives. Thanks! If you have a specific question or concern about promoting Rust or using its trademarks, please contact the Rust Foundation: contact@rustfoundation.org. Cheers, Mark ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: rust non-free-compatible trademark 2022-07-17 22:59 ` Mark Wielaard @ 2022-07-17 23:07 ` lkcl 2022-07-17 23:55 ` Richard Kenner 1 sibling, 0 replies; 31+ messages in thread From: lkcl @ 2022-07-17 23:07 UTC (permalink / raw) To: Mark Wielaard; +Cc: GCC developers sorry, Mark, you're still misunderstanding, on multiple levels and in so many ways i am having a hard time tracking them all. i don't feel that i've been heard, and consequently do not feel comfortable continuing the conversation, especially given that i have other priorities. if you had asked questions "so let me make sure that i understand you correctly" i would feel much more comfortable to continue the conversation. i have raised the topic: it is your responsibility and duty to consider. l. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: rust non-free-compatible trademark 2022-07-17 22:59 ` Mark Wielaard 2022-07-17 23:07 ` lkcl @ 2022-07-17 23:55 ` Richard Kenner 1 sibling, 0 replies; 31+ messages in thread From: Richard Kenner @ 2022-07-17 23:55 UTC (permalink / raw) To: mark; +Cc: gcc, luke.leighton > Normal use of a word isn't something that Trademarks prevent. In general, no, but what it prevents is using the word in a way that would produce confusion with an "official" use of that mark. If the word that constitutes the mark is too general, then the trademark shouldn't have been granted. But let's assume that somebody has trademarked a common adjective, which we'll call "adjective", when applied to noun "noun". If I write "I have an adjective noun", that's supposed to refer to the trademarked it. If it instead refers to some other item (e.g., in our case a compiler with patches), that's a trademark violatio. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: rust non-free-compatible trademark 2022-07-17 17:41 ` Mark Wielaard 2022-07-17 18:11 ` lkcl @ 2022-07-17 18:28 ` Richard Kenner 2022-07-17 18:54 ` Alexandre Oliva 2 siblings, 0 replies; 31+ messages in thread From: Richard Kenner @ 2022-07-17 18:28 UTC (permalink / raw) To: mark; +Cc: gcc, luke.leighton > I think you are misinterpreting when you need a trademark license for > usage a word mark in an implementation of a compiler for a programming > language. Note that gcc used to come with a full implementation of the > Java programming language, compiler, runtime and core library > implementation (for which I was the GNU maintainer). None of that > required a trademark license because the usage of the word java was > just for compatibility with the java programming language. Was "Java" a trademark for both the language and compiler or just the language? What about "rust"? That would seem to make a difference. If the trademark is just for the language, then when you say you have a "compiler for the XYZ language", you're refering to the trademarked entity (the language) and you can always use a trademark to refer to the trademark owner's product. But if the trademark is also for the compiler and you have a different compiler (even if it differs just by patches), you need the permission of the trademark owner to call you compiler by the trademarked name. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: rust non-free-compatible trademark 2022-07-17 17:41 ` Mark Wielaard 2022-07-17 18:11 ` lkcl 2022-07-17 18:28 ` Richard Kenner @ 2022-07-17 18:54 ` Alexandre Oliva 2 siblings, 0 replies; 31+ messages in thread From: Alexandre Oliva @ 2022-07-17 18:54 UTC (permalink / raw) To: Mark Wielaard; +Cc: lkcl, GCC developers On Jul 17, 2022, Mark Wielaard <mark@klomp.org> wrote: > None of that required a trademark license because the usage of the > word java was just for compatibility with the java programming > language. "just for compatibility" is an defense that applies to copyrights, but AFAIK it doesn't apply to trademarks. indeed, one can probably still find records suggesting that gcj got its name, "GNU Compiler for Java", that way rather than the more natural phrasing "Java Compiler", because the Java trademark was liberally licensed for use in the form "for Java", whereas other uses were not. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org> ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: rust non-free-compatible trademark 2022-07-17 16:31 ` Mark Wielaard 2022-07-17 17:06 ` lkcl @ 2022-07-18 7:09 ` David Brown 2022-07-18 8:07 ` lkcl 1 sibling, 1 reply; 31+ messages in thread From: David Brown @ 2022-07-18 7:09 UTC (permalink / raw) To: Mark Wielaard, lkcl; +Cc: GCC developers On 17/07/2022 18:31, Mark Wielaard wrote: > Hi Luke, > > On Sun, Jul 17, 2022 at 04:28:10PM +0100, lkcl via Gcc wrote: >> with the recent announcement that rust is supported by gcc > > There is just a discussion about whether and how to integrate > (portions) of the gccrs frontend into the main gcc repository. Nobody > claims that means the rust programming language is supported by gcc > yet. There is a lot of work to be done to be able to claim that. > >> has it been taken into consideration that the draconian (non-free-compatible) >> requirements of the rust Trademark make the distribution of the gcc >> compiler Unlawful? >> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013920 > > That looks to me as an overreaching interpretation of how to interpret > a trademark. I notice you are the bug reporter. It would only apply if > a product based on gcc with the gccrs frontend integrated would claim > to be endorsed by the Rust Foundation by using the Rust wordmark. Just > using the word rust doesn't trigger confusion about that. And > trademarks don't apply when using common words to implement an > interface or command line tool for compatibility with a programming > language. > > If you are afraid your usage of gcc with the gccrs frontend integrated > does cause confusion around the Rust word mark then I would suggest > contacting the Rust Foundation to discuss how you can remove such > confusion. Probably adding a README explicitly saying "this product > isn't endorsed by and doesn't claim to be endoresed by the Rust > Foundation" will be enough. > > Good luck, > > Mark > Speaking as someone who is neither a lawyer, nor a GCC developer, nor even (as yet) a Rust user, it seems to me that step 1 would be to hear what the Rust Foundation has to say on the matter: <https://foundation.rust-lang.org/policies/logo-policy-and-media-guide/> As far as I can tell, if they have been happy with the current gccrs project, they should in principle be happy with its integration in gcc mainline. And they are also happy to talk to people, happy to promote rust, and happy to work with all kinds of free and open source projects. The key thing they want to avoid would be for GCC to produce a compiler that is mostly like rust, but different - leading to fragmentation, incompatibilities, confusion, bugs in user code. /No one/ wants that. I am sure that if the Rust Foundation foresaw a big problem here, they'd already have contacted the gccrs and/or GCC folks - the project is not a secret. I would think that the long term aim here is that the gcc implementation of rust (may I suggest "grust" as a name, rather than "gust"?) be considered "official" by the Rust Foundation - with links and information on their website, their logo on the GCC website, and coordination between GCC and the Rust Foundation on future changes. That may be ambitious, or far off, but it should be the goal. In the meantime, as far as I can see it is just a matter of writing "rust" without capital letters, and a documentation disclaimer that grust is not (yet) endorsed by the Rust Foundation. David ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: rust non-free-compatible trademark 2022-07-18 7:09 ` David Brown @ 2022-07-18 8:07 ` lkcl 2022-07-18 8:50 ` Jonathan Wakely 0 siblings, 1 reply; 31+ messages in thread From: lkcl @ 2022-07-18 8:07 UTC (permalink / raw) To: David Brown; +Cc: Mark Wielaard, GCC developers On Mon, Jul 18, 2022 at 8:09 AM David Brown <david.brown@hesbynett.no> wrote: > Speaking as someone who is neither a lawyer, nor a GCC developer, nor > even (as yet) a Rust user, it seems to me that step 1 would be to hear > what the Rust Foundation has to say on the matter: > > <https://foundation.rust-lang.org/policies/logo-policy-and-media-guide/> this is their Trademark License. like a Patent License or a Copyright License it comprises *additional* terms and conditions with which You *must* Comply. [you *can* attempt to ignore it but exactly like ignoring a Copyright License you risk operating Unlawfully and place yourself at risk of being sued at best in a Civil Court, and there are some circumstances in Trademark Law where you can end up in a Criminal Court as well]. the objectionable section of that Trademark License is: Uses that do not require explicit approval # Distributing a modified version of the Rust programming language or the Cargo package manager, provided that the modifications are limited to: - porting the software to a different architecture - fixing local paths - adding patches that have been released upstream - adding patches that have been reported upstream, provided that the patch is removed if it is not accepted upstream Uses that require explicit approval # Distributing a modified version of the Rust programming language [or the Cargo package manager] with modifications other than those permitted above and calling it Rust or Cargo requires explicit, written permission from the Rust Foundation. so any optimisations made by anyone are Unlawful. any additional documentation is Unlawful. any addition of Copyright notice files (debian/copyright) is Unlawful. why? because none of those "patches" are "permitted" by the Rust Foundation under their Trademark License. > As far as I can tell, if they have been happy with the current gccrs > project, they should in principle be happy with its integration in gcc > mainline. And they are also happy to talk to people, happy to promote > rust, and happy to work with all kinds of free and open source projects. > The key thing they want to avoid would be for GCC to produce a > compiler that is mostly like rust, but different - leading to > fragmentation, incompatibilities, confusion, bugs in user code. /No > one/ wants that. yes, absolutely. it's quite obvious that that was the intent of the clause that they added, which explicitly prohibits patching without consent [and still having the right to use the word "rust']. however that prohibition is - as i have said many times and been ignored as many times - is in *direct* violation of the GPL, and of Debian's DFSG (on multiple counts), and is also completely Un-Reason-Able. in addition - and this was not acknowledged either - any developer *not* considered to be "part of the gcc team" - i.e. anyone who wants to modify and then further distribute - patched versions of gcc containing gccrs - also does so at the risk of violating the Rust Trademark. > I would think that the long term aim here is that the gcc implementation > of rust (may I suggest "grust" as a name, rather than "gust"?) be > considered "official" by the Rust Foundation - with links and > information on their website, their logo on the GCC website, and > coordination between GCC and the Rust Foundation on future changes. > That may be ambitious, or far off, but it should be the goal. at which point although the gcc team is fine, the ongoing distribution of gcc by anyone and everyone still is not. actually, it occurs to me that under the terms and conditions of the GPL, even the gcc developers may not be able to comply with the GPL *and* those above Trademark Conditions, because the restriction on what can and cannot be patched is in direct conflict with *granting the right to modify*. if this is in fact the case then the only choice left for the gcc developers would be to cease and desist distribution of gcc, because they cannot comply with both Licenses simultaneously. which is why i said - and have been ignored - that the gcc developers need rather urgently to seek proper legal counsel and get a proper legal opinion. l. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: rust non-free-compatible trademark 2022-07-18 8:07 ` lkcl @ 2022-07-18 8:50 ` Jonathan Wakely 2022-07-18 9:06 ` lkcl 0 siblings, 1 reply; 31+ messages in thread From: Jonathan Wakely @ 2022-07-18 8:50 UTC (permalink / raw) To: lkcl; +Cc: David Brown, GCC developers, Mark Wielaard On Mon, 18 Jul 2022 at 09:07, lkcl via Gcc <gcc@gcc.gnu.org> wrote: > which is why i said - and have been ignored - that the gcc developers > need rather urgently to seek proper legal counsel and get a proper > legal opinion. You haven't been ignored. People have expressed reasonable disagreements with your interpretation. Just because every line of your email hasn't been explicitly responded to with positive acknowledgement of receipt doesn't mean you've been ignored.To keep insisting that sounds silly, and IMHO will increase the chance of being ignored in future. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: rust non-free-compatible trademark 2022-07-18 8:50 ` Jonathan Wakely @ 2022-07-18 9:06 ` lkcl 0 siblings, 0 replies; 31+ messages in thread From: lkcl @ 2022-07-18 9:06 UTC (permalink / raw) To: Jonathan Wakely; +Cc: David Brown, GCC developers, Mark Wielaard On Mon, Jul 18, 2022 at 9:50 AM Jonathan Wakely <jwakely.gcc@gmail.com> wrote: > You haven't been ignored. People have expressed reasonable > disagreements with your interpretation. > > Just because every line of your email hasn't been explicitly responded > to with positive acknowledgement of receipt doesn't mean you've been > ignored. if i feel that i've been ignored, and it makes me upset and frustrated i have every right to say so, and whilst i know that you are trying to help you are unfortunately at risk from telling me that my feelings are invalid, which is a line that i trust you understand is completely and utterly inappropriate that you cannot cross. bottom line is that you're giving a perfectly reasonable justification for Mark's lack of empathy. [sadly this is extremely common in Technical discussions] i know exactly what Mark's doing: he's only superficially skim-reading reading (citing the Java case without even acknowledging that i'd raised it already - twice), wants to take control of the conversation and wants it shut down as quickly as possible (telling me to "go contact the Rust Foundation directly"). i'd very much like to see Mark read - and follow - this https://www.crnhq.org/cr-kit/#empathy i'm already at this: https://www.crnhq.org/cr-kit/#assertiveness l. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: rust non-free-compatible trademark 2022-07-17 15:28 rust non-free-compatible trademark lkcl 2022-07-17 16:25 ` Richard Biener 2022-07-17 16:31 ` Mark Wielaard @ 2022-07-18 14:30 ` lkcl 2022-07-18 17:11 ` Richard Kenner ` (2 more replies) 2 siblings, 3 replies; 31+ messages in thread From: lkcl @ 2022-07-18 14:30 UTC (permalink / raw) To: GCC developers a (private) discussion has, fascinatingly, uncovered this, from 1987: http://archive.adaic.com/pol-hist/policy/trademrk.txt In order to be a validated Ada compiler, a compiler must pass an extensive suite of programs called the Ada Compiler Validation Capability (ACVC). The AJPO has adopted a certification mark to show that a compiler has passed the ACVC and is a validated compiler or a compiler derived from a validated base compiler as defined in the Ada Compiler Validations Procedures and Guidelines (version 1.1 of which was issued in January 1987). The certification mark may also be used on certain literature accompanying or documenting a validated compiler. Information concerning the proper use of the certification mark was distributed to interested parties during the summer of 1987. what that tells us is that there is precedent for a Computer Language to apply for and be granted a *Certification Mark* which was enforced through the extremely simple process of running an Authorised Certification Suite. the modern name for such is "test suite". if the Rust Foundation were to add an extremely simple phrase "to be able to use the word rust in a distributed compiler your modifications must 100% pass the test suite without modifying the test suite" then all the problems and pain goes away. as i said: the Rust Foundation is the world's first FOSS Project attempting to create a Certification Mark (and doing a poor-man's job of it). a thorough investigation of how it was done for ADA should reveal how it can be properly done for gccrs and rustc. i feel reasonably confident in saying that if i had the time to look up discussions on this topic, there would almost certainly be requests from the Rust Foundation that gccrs pass the exact same test suites as provided with rustc. A Certification Mark is the proper way to formally and legally enforce such requirements. telling people they cannot patch the source code without permission is a troublesome and tiresome and non-trusting way to attempt the same objective. l. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: rust non-free-compatible trademark 2022-07-18 14:30 ` lkcl @ 2022-07-18 17:11 ` Richard Kenner 2022-07-18 17:12 ` Richard Kenner 2022-07-18 18:32 ` Florian Weimer 2 siblings, 0 replies; 31+ messages in thread From: Richard Kenner @ 2022-07-18 17:11 UTC (permalink / raw) To: luke.leighton; +Cc: gcc > In order to be a validated Ada compiler, a compiler must pass > an extensive suite of programs called the Ada Compiler Validation > Capability (ACVC). FYI: the current name for this is ACATS: Ada Conformity Assessment Test Suite. > "to be able to use the word rust in a distributed compiler your > modifications must 100% pass the test suite without modifying > the test suite" What does "in" mean here? Is "rust" modifying "language" or "compiler" in this case? As was stated, that's a significant difference. > a thorough investigation of how it was done for ADA should reveal > how it can be properly done for gccrs and rustc. It's a very different situation. Ada was a standardized language via a very formal process. And it was a very different time. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: rust non-free-compatible trademark 2022-07-18 14:30 ` lkcl 2022-07-18 17:11 ` Richard Kenner @ 2022-07-18 17:12 ` Richard Kenner 2022-07-18 18:32 ` Florian Weimer 2 siblings, 0 replies; 31+ messages in thread From: Richard Kenner @ 2022-07-18 17:12 UTC (permalink / raw) To: luke.leighton; +Cc: gcc > A Certification Mark is the proper way to formally and legally enforce such > requirements. BTW, nobody is or was at all confident that the Ada mark was legally enforcable. I'm in the camp that it isn't. > telling people they cannot patch the source code without permission Nobody is telling people that. What they're saying is the same thing as the GPL does: it you distribute modified code, you need to be clear that what you're distributing is a modification. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: rust non-free-compatible trademark 2022-07-18 14:30 ` lkcl 2022-07-18 17:11 ` Richard Kenner 2022-07-18 17:12 ` Richard Kenner @ 2022-07-18 18:32 ` Florian Weimer 2022-07-18 18:43 ` Arthur Cohen 2022-07-18 19:35 ` lkcl 2 siblings, 2 replies; 31+ messages in thread From: Florian Weimer @ 2022-07-18 18:32 UTC (permalink / raw) To: lkcl via Gcc; +Cc: lkcl * lkcl via Gcc: > if the Rust Foundation were to add an extremely simple phrase > > "to be able to use the word rust in a distributed compiler your > modifications must 100% pass the test suite without modifying > the test suite" > > then all the problems and pain goes away. No. It would actually make matters worse for GCC in this case because the stated intent is to ship without a borrow checker (“There are no immediate plans for a borrow checker as this is not required to compile rust code”, <https://rust-gcc.github.io/>, retrieved 2022-07-18). There are of course tests for the borrow checker in the Rust test suite, and those that check for expected compiler errors will fail with GCC. Thanks, Florian ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: rust non-free-compatible trademark 2022-07-18 18:32 ` Florian Weimer @ 2022-07-18 18:43 ` Arthur Cohen 2022-07-19 9:43 ` Florian Weimer 2022-07-18 19:35 ` lkcl 1 sibling, 1 reply; 31+ messages in thread From: Arthur Cohen @ 2022-07-18 18:43 UTC (permalink / raw) To: Florian Weimer; +Cc: lkcl via Gcc, lkcl Hi Florian, On Mon, Jul 18, 2022, 20:33 Florian Weimer via Gcc <gcc@gcc.gnu.org> wrote: > * lkcl via Gcc: > > > if the Rust Foundation were to add an extremely simple phrase > > > > "to be able to use the word rust in a distributed compiler your > > modifications must 100% pass the test suite without modifying > > the test suite" > > > > then all the problems and pain goes away. > > No. It would actually make matters worse for GCC in this case because > the stated intent is to ship without a borrow checker (“There are no > immediate plans for a borrow checker as this is not required to compile > rust code”, <https://rust-gcc.github.io/>, retrieved 2022-07-18). The website is not up to date and we do have to change that. We do have plans for borrow-checking, which revolve around using and contributing to the Polonius project. There > are of course tests for the borrow checker in the Rust test suite, and > those that check for expected compiler errors will fail with GCC. > > Thanks, > Florian Thanks, -- Arthur Cohen ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: rust non-free-compatible trademark 2022-07-18 18:43 ` Arthur Cohen @ 2022-07-19 9:43 ` Florian Weimer 0 siblings, 0 replies; 31+ messages in thread From: Florian Weimer @ 2022-07-19 9:43 UTC (permalink / raw) To: Arthur Cohen; +Cc: gcc * Arthur Cohen: > Hi Florian, > > On Mon, Jul 18, 2022, 20:33 Florian Weimer via Gcc <gcc@gcc.gnu.org> wrote: > No. It would actually make matters worse for GCC in this case because > the stated intent is to ship without a borrow checker (“There are no > immediate plans for a borrow checker as this is not required to compile > rust code”, <https://rust-gcc.github.io/>, retrieved 2022-07-18). > > The website is not up to date and we do have to change that. We do > have plans for borrow-checking, which revolve around using and > contributing to the Polonius project. Ahh, I was wondering about that, but I couldn't find a clear indicator that Polonius is still being developed in upstream Rust. Thanks, Florian ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: rust non-free-compatible trademark 2022-07-18 18:32 ` Florian Weimer 2022-07-18 18:43 ` Arthur Cohen @ 2022-07-18 19:35 ` lkcl 2022-07-18 21:01 ` David Malcolm 1 sibling, 1 reply; 31+ messages in thread From: lkcl @ 2022-07-18 19:35 UTC (permalink / raw) To: Florian Weimer, lkcl via Gcc (apologies top-posting, strange mobile mailer). i would expect in that case that the Rust Foundation to work closely with Certification Mark Licensees, and to come to an accommodation, defining a subset if necessary. if the gcc developers can clearly enunciate why shipping a "borrow checker" (whatever that is) is unreasonable, the Certification Mark Holder has to take that into consideration. without knowing full details i would expect it to be a third party library of some kind (rather than libgcc.a) Certification Mark Holders *have* to act FRAND otherwise they lose the Certification Mark aside: it is reasonable for a Certification Mark Holder to require full compliance, they are after all the Custodians of the Language, and one would not expect a broken (non-compliant) compiler to actually be distributed, regardless of a Certification Mark. thus i think you'll find that the usual "pre-alpha alpha beta" release cycles which would and would not naturally be released for distribution fit directly and one-to-one with what a Certification Mark Holder would and would not authorise. regarding missing tests: well, tough titty on the Certification Mark Holder. if they cannot define the Compliance Test Suite they cannot tell people they are non-compliant, can they! thus although quirky it all works out. (whereas telling people what patches they can and cannot apply just pisses them off). l. On July 18, 2022 7:32:25 PM GMT+01:00, Florian Weimer <fweimer@redhat.com> wrote: >* lkcl via Gcc: > >> if the Rust Foundation were to add an extremely simple phrase >> >> "to be able to use the word rust in a distributed compiler your >> modifications must 100% pass the test suite without modifying >> the test suite" >> >> then all the problems and pain goes away. > >No. It would actually make matters worse for GCC in this case because >the stated intent is to ship without a borrow checker (“There are no >immediate plans for a borrow checker as this is not required to compile >rust code”, <https://rust-gcc.github.io/>, retrieved 2022-07-18). >There >are of course tests for the borrow checker in the Rust test suite, and >those that check for expected compiler errors will fail with GCC. > >Thanks, >Florian ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: rust non-free-compatible trademark 2022-07-18 19:35 ` lkcl @ 2022-07-18 21:01 ` David Malcolm 2022-07-18 23:09 ` lkcl 0 siblings, 1 reply; 31+ messages in thread From: David Malcolm @ 2022-07-18 21:01 UTC (permalink / raw) To: lkcl, Florian Weimer, lkcl via Gcc On Mon, 2022-07-18 at 20:35 +0100, lkcl via Gcc wrote: > (apologies top-posting, strange mobile mailer). i would expect in that > case that the Rust Foundation to work closely with Certification Mark > Licensees, and to come to an accommodation, defining a subset if > necessary. > > if the gcc developers can clearly enunciate why shipping a "borrow > checker" (whatever that is) is unreasonable, the Certification Mark > Holder has to take that into consideration. without knowing full > details i would expect it to be a third party library of some kind > (rather than libgcc.a) > > Certification Mark Holders *have* to act FRAND otherwise they lose the > Certification Mark > > aside: it is reasonable for a Certification Mark Holder to require full > compliance, they are after all the Custodians of the Language, and one > would not expect a broken (non-compliant) compiler to actually be > distributed, regardless of a Certification Mark. > > thus i think you'll find that the usual "pre-alpha alpha beta" release > cycles which would and would not naturally be released for distribution > fit directly and one-to-one with what a Certification Mark Holder would > and would not authorise. > > regarding missing tests: well, tough titty on the Certification Mark > Holder. if they cannot define the Compliance Test Suite they cannot > tell people they are non-compliant, can they! > > thus although quirky it all works out. > > (whereas telling people what patches they can and cannot apply just > pisses them off). I've been trying to ignore this thread, but unfortunately it seems to still be going on. Luke: you appear to me to be the one who is telling people what patches they can and cannot apply, and it's pissing me off. You seem to me to be constructing elaborate arguments for why there's some kind of legal problem here, and elaborate purported workarounds, when it isn't at all clear to me that there are any problems. Are you a lawyer? If so please consider volunteering your time to the GCC Steering Committee *privately*. If not, it seems to me to be a terrible idea to try to get the developers to pontificate in public about alleged legal issues with the project, their implications, and supposed workarounds. The GCC Steering Committee has approved merging the rust frontend into GCC. It's a big project, so I fully expect that the frontend that we ship in GCC 13.1 will have bugs, missing functionality, and slight differences compared to rustc. I'm guessing we'll need to have some kind of in the release notes for GCC 13 to set people's expectations - perhaps the GCC 13 release of the rust frontend will be considered just of "alpha" quality, for people to "kick the tyres" - but I leave that judgement call to Philip and the other gcc rust developers. There are no doubt "unknown unknowns" (to misquote Donald Rumsfeld), and shaking these out will make help both the GCC and Rust communities - but please can we leave the technical issues to the developers doing the work (I'm a gcc developer, but merely a rust "fanboy"). The gcc rust frontend is an ambitious one with lots of technical challenges, but which has the potential to make the GCC and Rust development communities stronger; this discussion seems to me to be a pointless attempt to pick a fight between the two. These opinions are my own, and not those of my employer, etc etc Dave > > l. > > > > On July 18, 2022 7:32:25 PM GMT+01:00, Florian Weimer < > fweimer@redhat.com> wrote: > > * lkcl via Gcc: > > > > > if the Rust Foundation were to add an extremely simple phrase > > > > > > "to be able to use the word rust in a distributed compiler your > > > modifications must 100% pass the test suite without modifying > > > the test suite" > > > > > > then all the problems and pain goes away. > > > > No. It would actually make matters worse for GCC in this case > > because > > the stated intent is to ship without a borrow checker (“There are no > > immediate plans for a borrow checker as this is not required to > > compile > > rust code”, <https://rust-gcc.github.io/>, retrieved 2022-07-18). > > There > > are of course tests for the borrow checker in the Rust test suite, > > and > > those that check for expected compiler errors will fail with GCC. > > > > Thanks, > > Florian > ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: rust non-free-compatible trademark 2022-07-18 21:01 ` David Malcolm @ 2022-07-18 23:09 ` lkcl 2022-07-19 9:27 ` Gabriel Ravier 0 siblings, 1 reply; 31+ messages in thread From: lkcl @ 2022-07-18 23:09 UTC (permalink / raw) To: David Malcolm; +Cc: Florian Weimer, lkcl via Gcc On Mon, Jul 18, 2022 at 10:01 PM David Malcolm <dmalcolm@redhat.com> wrote: > Luke: you appear to me to be the one who is telling people what patches > they can and cannot apply, and it's pissing me off. 1) please don't you dare put words into my mouth that i did not state. first and only warning. 2) i'm sorry you're annoyed. Asperger's interactions with neuro-typical individuals who are not used to the same typically do not go well: this conversation has all the hallmarks i'm used to being subjected to (and, frankly, shouldn't have to put up with). as you can probably imagine in 25 years it's pretty tiresome for me to be constantly subjected to abuse based solely on misunderstandings that, with the tiniest bit of tolerance, could easily have been avoided. 3) as you work for redhat, you should be able to speak to HR and request Diversity training for how to interact with people with Asperger's. [or, at least, how to recognise them and not get pissed off by how they speak]. given that it was "neurodiversity month" only a few weeks ago you should be able to find references on linkedin. > Are you a lawyer? If so please consider volunteering your time to the > GCC Steering Committee *privately*. If not, it seems to me to be a > terrible idea to try to get the developers to pontificate in public > about alleged legal issues with the project, their implications, and > supposed workarounds. i'm a Libre Ethical Technology Specialist. i expect a project such as gcc to be held accountable publicly for its decisions and actions, and to act responsibly. this conversation will be watched by a hell of a lot of people and if there are private conversations on this topic being held behind closed doors then how the hell can anyone have any confidence and trust in gcc? i'm publicly and fully accountable in the FOSS projects that *i* manage, including the full financial records, and given how massively high-profile gcc is, i expect it to be held publicly accountable to a far greater degree. > The gcc rust frontend is an ambitious one with lots of technical > challenges, but which has the potential to make the GCC and Rust > development communities stronger; or, if done incorrectly, screw absolutely everyone who ever tries to distribute gcc or attempt to contribute to it. > this discussion seems to me to be a > pointless attempt to pick a fight between the two. wrong, sorry. read again the parts where i recommend a workable solution that is based on a past real-world case: the ADA Certification Mark. here is the link again: http://archive.adaic.com/pol-hist/policy/trademrk.txt what you *might* be referring to is that i have absolutely no qualms at all about calling out the Mozilla Foundation's Rust Trademark as, frankly, "bloody stupid". given their past handling of iceweasel this should be no surprise to anyone familiar with that fiasco. i have absolutely no problem with the Python Software Foundation Trademark because the PSF Trademark does not attempt such a kak-handed, heavy-handed and draconian imposition. i mean, for god's sake, the attempt to hide the efforts to demand that people contact them if they perform any kind of "unauthorised" patches is hidden in a document entitled "Logo and Media Policy Guide". this in no way should inspire confidence! please understand: if they *actually* did a decent job and *actually* listened by converting the Trademark to a proper Certification Mark (just as ADA did in 1987), i would be the first person to very loudly praise them for such an astoundingly forward-thinking strategic move to protect the Rust Language from harm in a very natural and logical way. from me you will always get the blunt truth as i see it. no gloves, no sugar-coating. no diplomacy, no lying by omission. it's... not popular, but serves an extremely valuable purpose: cuts through a lot of crap on topics that people were either not aware of or were deeply uncomfortable bringing up, often for years. you might not feel comfortable *admitting* that (certainly not publicly) but after some [considerable] time and calm and considered investigation, and once your feathers have de-ruffled, you'll appreciate what i've done. l. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: rust non-free-compatible trademark 2022-07-18 23:09 ` lkcl @ 2022-07-19 9:27 ` Gabriel Ravier 2022-07-19 10:26 ` lkcl 0 siblings, 1 reply; 31+ messages in thread From: Gabriel Ravier @ 2022-07-19 9:27 UTC (permalink / raw) To: lkcl, David Malcolm; +Cc: Florian Weimer, lkcl via Gcc On 7/19/22 01:09, lkcl via Gcc wrote: > On Mon, Jul 18, 2022 at 10:01 PM David Malcolm <dmalcolm@redhat.com> wrote: > >> Luke: you appear to me to be the one who is telling people what patches >> they can and cannot apply, and it's pissing me off. > 1) please don't you dare put words into my mouth that i did not state. > first and only warning. > 2) i'm sorry you're annoyed. Asperger's interactions with neuro-typical > individuals who are not used to the same typically do not go well: > this conversation has all the hallmarks i'm used to being subjected > to (and, frankly, shouldn't have to put up with). > as you can probably imagine in 25 years it's pretty tiresome > for me to be constantly subjected to abuse based solely on > misunderstandings that, with the tiniest bit of tolerance, could > easily have been avoided. > 3) as you work for redhat, you should be able to speak to HR and > request Diversity training for how to interact with people with > Asperger's. [or, at least, how to recognise them and not get > pissed off by how they speak]. given that it was "neurodiversity month" > only a few weeks ago you should be able to find references on linkedin. Hello there. For a while I've been watching this conversation and seeing how inflammatory it has become, and this seems like the right place to intervene, as I myself have Asperger. I would like to say that from my perspective it is you, not everyone else, who is subjecting people to abuse based on a misunderstanding with what seems to me like a constant stream of "OMGWTF THE RUST TRADEMARK WILL DESTROY ALL GCC DEVELOPERS, REMOVE RUST NOW" (note: this is hyperbole, and I am not claiming it is literally what you have said, it is simply the general feeling that I have been left off with after reading your messages throughout this thread). David is simply telling you one of the most basic implications of what you have been claiming, i.e. that if the GCC Rust frontend was to be added to GCC then it would apparently expose everyone involved in distribution of GCC (which as we know is a very wide definition) to trademark infringement lawsuits and even potential criminal liability as you have claimed in a previous message. The hopefully obvious implication is that the patches to add the Rust frontend should thus not be applied. You have answered to this by telling him that this simple statement is somehow abuse, which seems ridiculously confrontational to me and almost like you are accusing him of deliberately acting in bad faith, even though I have been doing my best to assume the assumption of good faith so far. Just as you have cited the Conflict Resolution Kit in one of your previous messages, I too know of similar sources. Here is one that might help you with this: https://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith >> Are you a lawyer? If so please consider volunteering your time to the >> GCC Steering Committee *privately*. If not, it seems to me to be a >> terrible idea to try to get the developers to pontificate in public >> about alleged legal issues with the project, their implications, and >> supposed workarounds. > i'm a Libre Ethical Technology Specialist. i expect a project such as > gcc to be held accountable publicly for its decisions and actions, > and to act responsibly. this conversation will be watched by a hell > of a lot of people and if there are private conversations on this topic > being held behind closed doors then how the hell can anyone have > any confidence and trust in gcc? > > i'm publicly and fully accountable in the FOSS projects that *i* manage, > including the full financial records, and given how massively high-profile > gcc is, i expect it to be held publicly accountable to a far greater degree. While public accountability is a very good thing, I would hope you understand that some topics are best kept private to some degree, at least for a short duration so as to discourage impulsive or defensive reactions. Security vulnerabilities should be a rather obvious example of this, but sensible issues such as legal ones (as the one you are raising here) are also the kind of things that seem to me like they should be kept private in the very short term. Coming on the GCC mailing list, which hundreds of people regularly read, and making such a statement as "has it been taken into consideration that the draconian (non-free-compatible) requirements of the rust Trademark make the distribution of the gcc compiler Unlawful?" will instinctively put essentially everyone directly involved with the project on the defensive for hopefully obvious reasons. By being publicly confrontational on this issue, you make it much, much more likely, regardless of the accuracy of your statements, that the people involved will not want to admit any potential mistake they might have made, and will encourage them to be equally confrontational in responding to you. Making private contact instead is very useful for establishing good faith and makes it easy for those that have been contacted to talk honestly about the matter, and in my view, public confrontation on things like this is only useful if those involved are using the privacy of the initial contact to cover up inaction. Note that this is also essentially the policy of the FSF on GPL violations (see the "Confidentiality can increase receptiveness and responsiveness" section in https://www.fsf.org/licensing/enforcement-principles), which seems quite reasonable to me. >> The gcc rust frontend is an ambitious one with lots of technical >> challenges, but which has the potential to make the GCC and Rust >> development communities stronger; > or, if done incorrectly, screw absolutely everyone who ever tries > to distribute gcc or attempt to contribute to it. Yes, because the Mozilla Foundation is obviously an evil cabal aiming to destroy all that dare to touch GCC. Well, I suppose saying this will probably get me accusations of putting words into your mouth, but I can't really see any other way to get to this conclusion other than this kind of conspiratorial thinking, unless you're assuming egregriously bad faith on their part. >> this discussion seems to me to be a >> pointless attempt to pick a fight between the two. > wrong, sorry. read again the parts where i recommend a workable > solution that is based on a past real-world case: the ADA Certification > Mark. here is the link again: > > http://archive.adaic.com/pol-hist/policy/trademrk.txt > > what you *might* be referring to is that i have absolutely no qualms > at all about calling out the Mozilla Foundation's Rust Trademark as, > frankly, "bloody stupid". given their past handling of iceweasel this > should be no surprise to anyone familiar with that fiasco. > > i have absolutely no problem with the Python Software Foundation > Trademark because the PSF Trademark does not attempt such a > kak-handed, heavy-handed and draconian imposition. > > i mean, for god's sake, the attempt to hide the efforts to demand > that people contact them if they perform any kind of "unauthorised" > patches is hidden in a document entitled "Logo and Media Policy Guide". > this in no way should inspire confidence! > > please understand: if they *actually* did a decent job and *actually* > listened by converting the Trademark to a proper Certification Mark > (just as ADA did in 1987), i would be the first person to very loudly > praise them for such an astoundingly forward-thinking strategic > move to protect the Rust Language from harm in a very natural > and logical way. > > from me you will always get the blunt truth as i see it. no gloves, > no sugar-coating. no diplomacy, no lying by omission. it's... not > popular, but serves an extremely valuable purpose: cuts through > a lot of crap on topics that people were either not aware of or > were deeply uncomfortable bringing up, often for years. > > you might not feel comfortable *admitting* that (certainly not publicly) > but after some [considerable] time and calm and considered > investigation, and once your feathers have de-ruffled, you'll > appreciate what i've done. It also encourages them to actively do nothing about it, as any related action could easily be tied back to this conversation without explicit admission, and could itself be seen as a public admission of guilt, regardless of how guilty of anything they actually are. > l. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: rust non-free-compatible trademark 2022-07-19 9:27 ` Gabriel Ravier @ 2022-07-19 10:26 ` lkcl 2022-07-19 10:55 ` Jonathan Wakely 0 siblings, 1 reply; 31+ messages in thread From: lkcl @ 2022-07-19 10:26 UTC (permalink / raw) To: Gabriel Ravier; +Cc: David Malcolm, Florian Weimer, lkcl via Gcc On Tue, Jul 19, 2022 at 12:41 AM David Edelsohn <dje.gcc@gmail.com> wrote: > > Luke, > > The GCC Community will give the issues that you raised due > consideration and resolve any problems through appropriate channels. David: although this was a private reply I am assuming that is in error, and i feel it is appropriate to make public, and wrap up this thread. thank you for being literally the first person to very kindly give an explicit indication that i've been heard. that's all that any of you had to do, and now that i feel i've been heard i am no longer deeply frustrated and angry. https://www.crnhq.org/cr-kit/#empathy Gabriel i very much appreciate your efforts to tell me that "i am the problem" (see #empathy above) and i acknowledge those efforts. let's not reduce the S/N ratio any further, eh? perhaps everyone can learn from this experience, and some point down the line appreciate that, as an outsider with no vested interest, i was the only member in this community that could safely raise that "The Rust Foundation Emperor has no Clothes" without damage to their tenure, client base, or career, in what is one of the highest-paying most strategically critical FOSS Projects in the world. in summary i look forward to seeing the public results of the consideration of conversion of the Rust Trademark to a Certification Mark and the clear benefits and natural fit with existing FOSS development practices that entails. http://archive.adaic.com/pol-hist/policy/trademrk.txt l. l. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: rust non-free-compatible trademark 2022-07-19 10:26 ` lkcl @ 2022-07-19 10:55 ` Jonathan Wakely 0 siblings, 0 replies; 31+ messages in thread From: Jonathan Wakely @ 2022-07-19 10:55 UTC (permalink / raw) To: lkcl; +Cc: Gabriel Ravier, Florian Weimer, lkcl via Gcc On Tue, 19 Jul 2022 at 11:27, lkcl via Gcc <gcc@gcc.gnu.org> wrote: > > On Tue, Jul 19, 2022 at 12:41 AM David Edelsohn <dje.gcc@gmail.com> wrote: > > > > Luke, > > > > The GCC Community will give the issues that you raised due > > consideration and resolve any problems through appropriate channels. > > David: although this was a private reply I am assuming that is in > error, and i feel it is appropriate to make public, and wrap up this > thread. > > thank you for being literally the first person to very kindly give an explicit > indication that i've been heard. that's all that any of you had to do, and > now that i feel i've been heard i am no longer deeply frustrated and angry. I already said you were not being ignored, but you chose to interpret it as a dismissal of your feelings. Telling people to have more empathy and then reacting negatively when people have responses you don't like comes across as hypocritical. Your communication affects others too. > > https://www.crnhq.org/cr-kit/#empathy This should apply to all parties, not just the ones that aren't you. "Empathy is about building rapport, openness and trust between people. When it is absent, people are less likely to consider your needs and feelings." You started this thread with strong words like "draconian", "Unlawful" and immediately insisted on absolutes like "completely removed". No attempt to build rapport, or consider the feelings of the gccrs developers. It's no wonder it went downhill! > > Gabriel i very much appreciate your efforts to tell me that "i am > the problem" (see #empathy above) and i acknowledge those efforts. > let's not reduce the S/N ratio any further, eh? > > perhaps everyone can learn from this experience, and some point > down the line appreciate that, as an outsider with no vested interest, > i was the only member in this community that could safely raise that > "The Rust Foundation Emperor has no Clothes" without damage to > their tenure, client base, or career, in what is one of the highest-paying > most strategically critical FOSS Projects in the world. Nobody who has replied to you was trying to preserve their career or tenure, they just didn't agree with you. That's allowed. > in summary i look forward to seeing the public results of the consideration of > conversion of the Rust Trademark to a Certification Mark and the clear benefits > and natural fit with existing FOSS development practices that entails. > > http://archive.adaic.com/pol-hist/policy/trademrk.txt > > l. > > > l. ^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2022-07-19 10:55 UTC | newest] Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-07-17 15:28 rust non-free-compatible trademark lkcl 2022-07-17 16:25 ` Richard Biener 2022-07-17 16:47 ` lkcl 2022-07-17 18:24 ` Richard Kenner 2022-07-17 18:57 ` Alexandre Oliva 2022-07-17 16:31 ` Mark Wielaard 2022-07-17 17:06 ` lkcl 2022-07-17 17:41 ` Mark Wielaard 2022-07-17 18:11 ` lkcl 2022-07-17 18:29 ` lkcl 2022-07-17 22:59 ` Mark Wielaard 2022-07-17 23:07 ` lkcl 2022-07-17 23:55 ` Richard Kenner 2022-07-17 18:28 ` Richard Kenner 2022-07-17 18:54 ` Alexandre Oliva 2022-07-18 7:09 ` David Brown 2022-07-18 8:07 ` lkcl 2022-07-18 8:50 ` Jonathan Wakely 2022-07-18 9:06 ` lkcl 2022-07-18 14:30 ` lkcl 2022-07-18 17:11 ` Richard Kenner 2022-07-18 17:12 ` Richard Kenner 2022-07-18 18:32 ` Florian Weimer 2022-07-18 18:43 ` Arthur Cohen 2022-07-19 9:43 ` Florian Weimer 2022-07-18 19:35 ` lkcl 2022-07-18 21:01 ` David Malcolm 2022-07-18 23:09 ` lkcl 2022-07-19 9:27 ` Gabriel Ravier 2022-07-19 10:26 ` lkcl 2022-07-19 10:55 ` Jonathan Wakely
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).