Living with the Rust trademark
When a free-software project gets a trademark, it is an indication that the name of that project has come to have some sort of value, and somebody (hopefully the people in charge of the project) want to control how it is used. They may want to prevent their project's name being used with versions that have been modified with rent-seeking or malicious features, for example. Other projects might want the exclusive right to market commercial versions of their code under the trademarked name. As a general rule, trademark licenses will restrict the changes to a project's code that can be distributed without changing the name.
As a result of those restrictions, trademark policies can appear to be a violation of free-software principles. But those restrictions apply to the trademarked name, not the code itself; any such restrictions can be avoided just by not using the name. Thus, for some time, Firefox as distributed by Debian was known as "Iceweasel" until 2016; it lacked no functionality and was entirely free software. It is worth noting that version 3 of the GNU General Public License explicitly allows the withholding of trademark rights.
That does not mean, though, that all trademark policies for free-software projects are met with universal acclaim.
Rust in Debian
At the end of June, Luke Leighton filed a Debian bug regarding the trademarks on the Rust and Cargo names:
This is an extremely serious situation that either requires pulling rust and cargo from debian or a rename of both rust and cargo exactly as was done with iceweasel.Failure to do so is also extremely serious because Unlawful Distribution may still be considered grounds for financial compensation as well as a Legal Notice to Cease and Desist, and also to remove all public and private use of the Trademark from all Records. mailing lists, bugtracker, debian archives - everything.
On July 17, he posted a similar report to the GCC developers mailing list. The discussions in both places were tense at times, with Leighton's strident and sometimes threatening tone (which he attributed to Asperger's) making the discussion less pleasant than it should have been. That should not, however, obscure the fact that he does indeed have a point that both projects need to pay attention to.
Leighton was objecting to the Rust and Cargo trademark policies as they existed in late June. Specifically, he called out this rule:
Distributing a modified version of the Rust programming language or the Cargo package manager and calling it Rust or Cargo requires explicit, written permission from the Rust core team. We will usually allow these uses as long as the modifications are (1) relatively small and (2) very clearly communicated to end-users.
Debian distributes a large set of Rust-related packages, including the rustc compiler and cargo package manager/build system. Most distributions apply patches to programs of this size, and Debian is no exception. Thus, by a strict reading, Debian is likely to be in violation of the above terms.
Debian developer (and Rust package maintainer) Sylvestre Ledru responded
that he would "chat with some people on the Rust side about this
"
and suggested that there was little to worry about; since Ledru also was
involved with the resolution of the Iceweasel episode, there was reason to
trust his
judgment on this. That didn't stop an extended discussion on whether these
restrictions made Rust non-free or whether Debian was at risk, of course.
On July 18, Ledru returned with an announcement that a discussion with the Rust Foundation had resulted in some changes to the posted trademark policy. The current version of this policy has a new clause for allowed use of the trademarks:
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, or
- adding patches that have been reported upstream, provided that the patch is removed if it is not accepted upstream
From Ledru's point of view, the issue is resolved, and he closed the bug accordingly. Leighton promptly reopened it, leading to continued discussion about whether the issue has truly been resolved or not. It would appear, though, that the project as a whole feels there is no longer anything to worry about.
GCC and Rust
A solution for Debian is not necessarily a solution for GCC, though. The GCC project is not shipping a modified version of rustc; instead, this project has recently approved a plan to merge an independently implemented compiler front-end for the Rust language. By Leighton's interpretation of the trademark policy, the GCC Rust compiler cannot actually be called a Rust compiler. Should this interpretation hold, GCC could end up claiming to compile a language called something like "Gust" or "Oxide" instead.
Mark Wielaard responded, though, that the concern was overwrought:
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.
He also pointed
out that the one-time GCC Java implementation never ran afoul of the
Java trademark. Unsurprisingly at this point, Leighton disagreed:
"sorry, Mark, you're still misunderstanding, on multiple levels and in
so many ways i am having a hard time tracking them all
". The
conversation did not improve from there until David Edelsohn said (in an
apparently private message quoted
by Leighton) that the issues raised would be given "due
consideration
" and that any problem found would be addressed. That,
evidently, was the wording that Leighton wanted to hear.
In the short term, there is probably little danger of a "Gust" solution; as was pointed out in the discussion, the Rust Foundation has long been aware of the GCC work and has never raised any concerns about it. That could change at some future point, though, especially if the GCC Rust compiler implements a different version of the language, perhaps with extensions that have not been approved for official Rust™. If GCC Rust were to be successful enough to cause the Rust Foundation to fear loss of control over the language, the results could be bad for everybody involved. It will take some time before GCC Rust can catch up to rustc, though, if it ever does, so this is not an immediate concern.
Free-software licenses are about giving rights to others; trademark
licenses, instead, are concerned with restricting rights. So there will
always be a perceived conflict between the two. Most of the time, the
free-software community has found ways to coexist with trademarks. The
outcome in the Rust case will almost certainly be the same as long as the
parties involved pay attention and deal with each other in good faith; thus
far, there is no indication that anything other than that is happening.
Posted Jul 21, 2022 15:01 UTC (Thu)
by epa (subscriber, #39769)
[Link] (55 responses)
I think the key point is whether everyday use and interoperability of a modified version falls foul of trademark law. Can a modified package still be called ‘rust’ and provide that dependency? Can the menu item in the desktop environment still say ‘Firefox’ just as it used to, even though you have made unapproved changes? If you install Tauthon, can it still go in as /usr/bin/python if you want? Does all the documentation have to undergo search and replace?
As long as interoperability cannot be affected by trademark enforcement, the Debian maintainers’ view seems reasonable. But if not, it sounds like they are storing up trouble for the future. In free software we have a basic expectation that you can change a program and install it under the same name. Make changes to grep but still call it grep if you want. Otherwise the GNU project itself would have run into difficulties rewriting and enhancing each of the classic tools.
Unless you can legally create and distribute a Debian variant where /usr/bin/firefox shows porn on startup and rustc starts mining bitcoin in the background, I think it can’t be considered fully free software.
Posted Jul 21, 2022 15:35 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (33 responses)
And if that's the case, I personally would distance myself as far as possible, if not further, from said free software!
I take it then, that it's perfectly okay with you for me to change my account name to "epa", and start posting porn and bitcoin miner trojans on LWN? Or go down to the bank, borrow half a mill or so, and give them your name, address, account details etc instead of mine?
You're basically demanding the right to be an anti-social b*******d. The WHOLE POINT of trademark law is to prevent people pretending to be what they are not. An absolutely perfect example is, in the early days, NCR reputedly made shoddy copies of competitors cash-registers, specifically with the intention of damaging said competitor's reputation and destroying their business.
I don't see any problem with somebody creating and distributing a variant (never mind Debian) of firefox that displays porn and mines bitcoin. The problem arises when they pretend it's the real firefox (or take steps to disguise the fact that it is not).
As for this rust thing, I can understand the rust project being concerned about their official code base being modified and distributed AS RUST. And that's perfectly okay - if it's a modified code base distributed under the original name, they have every reason to be concerned.
But I think Luke Leighton is completely wrong about his worries over gcc. If it's not "original rust", makes no claims to be so, and compiles rust code in a manner that complies with the official specification, then there is precious little the Rust Foundation can do. It is *A* rust compiler, and the use of the word "rust" is absolutely permitted by trademark law. If, however, the Rust Foundation pointed out that gcc-rust was not compiling rust code correctly and breaching the spec, a failure by the gcc guys to do anything about it probably would be a trademark violation. Because they are then claiming to be what they are not - a proper compiler for the rust language.
Cheers,
Posted Jul 21, 2022 16:03 UTC (Thu)
by nim-nim (subscriber, #34454)
[Link] (28 responses)
The past shows that’s quite hard to achieve, the attractiveness of competing implementations varies over time (and the original one is not always at the leading edge, and all architectures are not always best served by the same one).
If the ecosystem is successful no implementation will get a perfect score on new features (because they will be competing to implement them first), there will be a need to separate implementation and language trademarks, and define language implementation levels.
Posted Jul 21, 2022 16:24 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (8 responses)
The problem would arise if the gcc guys knowingly or recklessly violated the rust specification, at which point I would expect sparks to fly. I just don't expect that point ever to be reached.
The guys at the sharp end are usually far more reasonable than the armchair warriors "fighting their battles" would have us believe. Certainly, with Pick/ScarletDME/MV, while I'm passionate about the model, I'd only get into a real fight over it if someone deliberately tried to break it.
Cheers,
Posted Jul 21, 2022 18:10 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link]
There exists at least one bootstrap compiler which doesn't implement borrow checking because you're expected to use it to compile the actual Rust compiler, and then use that to compile itself with borrow checking. But that's not intended as, and nobody advertises it as, an alternative Rust implementation with no borrow checking. This is just scaffolding.
Doing away with borrow checking destroys even more of Rust's intended value than might appear on the surface, a lot of tricks that are not immediately related actually can't work unless you've got the borrowing rules which that checker is enforcing in safe Rust. This is one reason why it's perhaps unfair to say writing correct _unsafe_ Rust is only as difficult as writing correct C++.
So it makes sense that they'd react very badly if you did that. Whether Debian thinks it should be _able_ to do that without explaining what you're getting definitely isn't Rust (even if it has no intent to ever actually do so) is worth at least a moment's thought. I don't believe it should want that.
Posted Jul 22, 2022 5:31 UTC (Fri)
by josh (subscriber, #17465)
[Link] (6 responses)
Many of us are also hopeful that, once gccrs gets to a point where it's considered a viable bootstrap compiler for GCC, the compiler frontend can then start adopting components written in Rust, at which point it could potentially share a lexer, parser, borrow checker, etc. For instance, gccrs has already stated their hopes of sharing the Polonius borrow checker that rustc is working on.
Posted Jul 22, 2022 12:50 UTC (Fri)
by tialaramex (subscriber, #21167)
[Link] (5 responses)
This is a difference of philosophy between Rust and, particularly, C++. Rust says our compiler will transform some correct Rust programs into machine code, and reject ALL incorrect programs. C++ says our compiler will transform ALL correct C++ programs into machine code, and reject some incorrect programs.
You would obviously wish to have a compiler which has both ALLs, but we have no idea how to build such a thing for languages this powerful and it's presumably impossible. Since I'm sure I make mistakes, I will sometimes write incorrect programs and I don't want those incorrect programs to compile. I see Rust as the obvious choice.
Posted Jul 22, 2022 18:19 UTC (Fri)
by NYKevin (subscriber, #129325)
[Link] (3 responses)
Rice's theorem does not apply to any version of correctness that can be described in terms of syntax (source code) rather than semantics (runtime behavior), nor to any kind of correctness that is "trivial" - true of every program you could possibly write. For example, you can't write a Java program that runs off the end of an array, because Java's model of computation requires that all array indexing is bounds-checked at runtime, and so "running off the end of an array" is not a thing that exists in the Java model of computation and Rice's theorem does not apply. Similarly, Rice's theorem does not apply to Rust's safety guarantees or most static type checkers, because those are rules of syntax (Rust does not prevent unsafe code, it just constrains it to be lexically within an unsafe block; static type checkers don't prevent type unsafety, they just force you to use type-cast syntax to express it). If you remove these "escape hatch" syntaxes (unsafe blocks and type-casts), then the static verifiers are overly strict and reject some valid programs.
On the other hand, Rice's theorem does severely constrain the set of things you can do with constexpr, std::static_assert(), and similar constructs. In principle, templates are Turing-complete, so you could write your whole program in templating syntax, and then static_assert would effectively function as a runtime assert, but then you might as well just use runtime asserts in the first place. There's no way to combine the "guaranteed to go off before we run the program" property with the "can check runtime state" property, and that restriction is the essence of Rice's theorem.
Posted Jul 25, 2022 11:49 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (2 responses)
As a side note on Rice's theorem (and Turing completeness, and other subsets of Rice's theorem): you can also avoid Rice's theorem by accepting some degree of inaccuracy from your classifier. It says you can't get perfection, but you can approximate it.
You can, for example, accept all good programs, but also misclassify 0.01% of bad programs as good, and avoid being bitten by Rice's theorem; same applies in the other direction (reject all bad, misclassify some good). One of the things Rust appears to be trying to do is to have it both ways; in the Safe Rust dialect, the compiler will reject all bad programs, but will misclassify some good programs as bad. In the Unsafe Rust dialect, it goes for the opposite error - it will accept all good programs, but will misclassify some bad programs as good.
Posted Aug 15, 2022 11:57 UTC (Mon)
by tialaramex (subscriber, #21167)
[Link] (1 responses)
So, Polonius will take some Rust programs which make sense but defy the current borrow analysis and so don't compile today - even if you were to sprinkle "unsafe" all over them, and make those programs compile fine as written.
The small number of unsafe "super powers" granted by the Rust unsafe keyword can of course introduce Undefined Behaviour, but that's distinct from the situation in C++ where you can in many cases write an invalid C++ program, one which simply doesn't mean anything under the C++ standard, and it will compile anyway, as allowed by the "No diagnostic required" rule.
Posted Aug 15, 2022 12:58 UTC (Mon)
by farnz (subscriber, #17727)
[Link]
To be clear, I'm not claiming that simply bunging "unsafe" into a program will cause the Rust compiler to accept it when it wouldn't otherwise; you do need to rewrite a program that fails to compile in Safe Rust into using the Unsafe Rust equivalents before the compiler will accept it - one of the nice features of Unsafe Rust is that anything that's Safe Rust behaves in exactly the same way whether you're using the Safe dialect or Unsafe dialect of Rust, it's just that in the Unsafe dialect, you have more ways to express the same basic computation. Hence, I'm talking about using unsafe superpowers like converting reference to pointer and then pointer back to reference to get a reference whose lifetime is independent of the original reference. This is unsafe for good reasons, and is rarely the right thing to do (since it's likely to have undefined behaviour), but you can do it if you have a valid program that the borrow checker rejects. Similar with bounds checks (get_unchecked(idx) or get_unchecked_mut(idx) instead of [idx]) and arithmetic on primitive types (unchecked_add(a, b) instead of a + b).
I'd be highly suspicious of any code I saw doing this, since checking it for correctness is deeply manual if you do this, and I'd prefer something compiler checked, but you can do it if you really are smarter than the compiler.
And the borrow checker, like everything in Safe Rust, is conservative - if you're using Safe Rust constructs (references not pointers, for example), the borrow checker should only accept programs that are definitely memory safe.
Posted Jul 23, 2022 4:01 UTC (Sat)
by josh (subscriber, #17465)
[Link]
Posted Jul 21, 2022 20:04 UTC (Thu)
by matthias (subscriber, #94967)
[Link] (17 responses)
Why? gcc-rust will probably document which features work and which do not. And what is wrong with saying we compile rust code up to version 1.x (for some x)? It would actually be quite strange to not announce the version of compatibility.
Posted Jul 21, 2022 22:47 UTC (Thu)
by Sesse (subscriber, #53779)
[Link] (16 responses)
Posted Jul 22, 2022 4:44 UTC (Fri)
by matthias (subscriber, #94967)
[Link] (15 responses)
Posted Jul 22, 2022 5:18 UTC (Fri)
by NYKevin (subscriber, #129325)
[Link] (2 responses)
Posted Jul 22, 2022 5:27 UTC (Fri)
by josh (subscriber, #17465)
[Link] (1 responses)
If you want to limit yourself to the features of a specific older Rust compiler, install that Rust compiler and compile with it; we ensure that rustup can install older versions of Rust. (Our standard recommendation for enforcing an MSRV of Rust 1.xy is to build against Rust 1.xy in CI; anything other than that would just be a proxy for what you're actually trying to do.)
Posted Jul 22, 2022 13:40 UTC (Fri)
by foom (subscriber, #14868)
[Link]
You really just need to test your build with the versions you want to support.
Posted Jul 22, 2022 7:44 UTC (Fri)
by Sesse (subscriber, #53779)
[Link] (11 responses)
Posted Jul 22, 2022 8:17 UTC (Fri)
by matthias (subscriber, #94967)
[Link] (10 responses)
The compiler would need to know that headers from the old codebase have to be treated differently than headers from the current codebase. And of course you would need to include both headers in the same compilation unit as polymorph code (i.e. templates) can only get monomorphized at compile time.
This is what the editions are meant to solve. And they do it quite well. And this is why they cannot protect from using new features in dependent crates. They are effectively designed to allow that different crates use different versions of the language. To protect from new features, you need accurate specifications of a minimal required versions. And yes, the correctness of these minimum version specifications could be checked by the compiler.
Posted Jul 22, 2022 8:37 UTC (Fri)
by Sesse (subscriber, #53779)
[Link] (9 responses)
I regularly write code on very recent GCC and Clang versions with -std=c++14, and that compile on older compilers without a hitch afterwards. That's a standard that's eight years old by now.
Posted Jul 22, 2022 13:14 UTC (Fri)
by tialaramex (subscriber, #21167)
[Link] (8 responses)
C++ cannot easily add nice syntax or deprecate bad old syntax, which is why it got e.g. the ugly co_await and why it *loves* re-using existing keywords like "delete" and "auto" even when that's probably a bad choice. In Rust the await keyword was added to 2018 edition, yet a Rust 2015 library could cheerfully name a variable, or a function, or (though it's bad style) a type 'await' and that will just work because that's not a keyword in their edition, even with a brand new compiler and even though you can use that library from your 2018 edition program.
C++ programmers cannot trivially do language upgrades because both the syntax and semantics of the language change from one version to another. Large C++ organisations may have a multi-year upgrade programme, especially for C++ 11 or C++ 20 while ordinary Rust programmers can expect a new Rust compiler to just deliver new features and not break stuff.
As an extreme example of this, one of the proposals for perhaps C++ 26 would be a Try operator similar to Rust's ? but C++ has the ternary operator ?: and so there's a conflict. The author concedes it will be necessary to name it something else, and suggests ??. So that's less ergonomic, needlessly different (other languages have ?? operators but Try is not what those operators do). The result is that the disfavoured ternary operator gets to hog this useful symbol forever, lest incompatibility be introduced.
[ Rust doesn't have the ternary operator, but if is an expression, so you can write let x = if predicate { this } else { that }; ]
Posted Jul 22, 2022 13:29 UTC (Fri)
by Sesse (subscriber, #53779)
[Link] (3 responses)
As someone who has regularly done language upgrades in C++, both professionally and in FOSS projects, I do beg to differ. :-) The big holdup is actually getting language support on all platforms you care about; after that it's usually one or two cleanup patches, and the rest is updating code to use the new features.
> Large C++ organisations may have a multi-year upgrade programme, especially for C++ 11 or C++ 20 while ordinary Rust programmers can expect a new Rust compiler to just deliver new features and not break stuff.
Do large Rust organizations even _exist_ yet? Do we have any experience with actually deploying it across a multitude of platforms in large projects and organizations (10k+ developers)? Because that's the scale where you're talking about C++ upgrade woes. Firefox has something like… 350k lines of Rust?
Look, there are lots of nice things about Rust. But the backwards compatibility story is not among them. Forwards compatibility, sure, but forward is not the only way to care about. When I search for a compilation issue and every single answer online is “oh, just use rustup to get the latest version”, I cringe.
Posted Jul 22, 2022 14:29 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
> But the backwards compatibility story is not among them.
The backwards compat is far better than C++ IME. Rust isn't going to stomp on my variable names while C++ instead tries to avoid it, but can still trip up code (e.g., some poor sod that named his struct fields `co_X`). The ecosystem has issues, but so does any ecosystem.
FWIW, there is `-Z minimal-versions` dependency resolution. Getting people to care is difficult, but so is getting people to care that you're still using GCC 4.8 today.
Posted Jul 26, 2022 22:39 UTC (Tue)
by Jandar (subscriber, #85683)
[Link]
And the <=> operator is used instead of < in the STL. I had a very subtle error while using a set of pair<> (*). The result was searching a multi MLOC codebase and writing many new <=> operators to be sure to avoid this problem.
The new automatically derived <=> was an unexpected major pain during transition to -std=c++20.
(*) This concrete problem was facilitated thru the indirection of the comparison operator by pair<>. Why the pair<> was needed to trigger the problem I don't fully understand, the convoluted implementation of the g++ STL has left me addleheaded ;-)
Posted Jul 23, 2022 3:17 UTC (Sat)
by tialaramex (subscriber, #21167)
[Link]
It's possible you lost count of the digits? It's about 3.5M lines.
You're probably correct that there aren't 10k+ developer organisations using exclusively or even primarily Rust. I'm not sure what a 10k+ developer organisation does, except flail around ineffectually, but I doubt Rust fixes that.
Posted Jul 22, 2022 17:06 UTC (Fri)
by madscientist (subscriber, #16861)
[Link] (3 responses)
I've never found this to be true. I've worked on multiple large projects that were started back in the 2000's, so were using C++03 (or earlier!), and have since updated to using C++11, C++14, C++17, and even C++20, and no such "multi-year upgrade program" was needed. In fact, much of the code that was used back in C++03 has not been touched at all. Yes, some of it is using old constructs that we would not use if that code were written today because there are better options in newer versions of C++, but it still works so we leave it alone.
Upgrading to a newer C++ compiler may take a few days' effort to see if there are issues, then you deploy it and over time you adjust the code to use newer features (or you don't bother, since in virtually all cases the old code still works).
I personally prefer the C/C++ trinary operator and think the syntax used by Rust and Python for this is gross to read. If you want a better (IMO) example of ugliness introduced due to backward-compatibility requirements in C++, consider "override" and "final": these cannot be added as full keywords so you have "virtual" as a prefix and "override" and "final" as postfix on methods which is yucky.
Posted Jul 22, 2022 17:25 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
That's certainly down to taste. I think the ?: is nice and terse, but it does have some awfully annoying precedence rules when nesting it last I remember. The other issue is the stuttering of `foo ? foo : some_default;` that I heard was proposed as `foo ?: some_default` at one point, but never got anywhere apparently.
However, usually I see Rust using if expressions for longer blocks of code where `?:` doesn't work anyways. Most types one would use `if` with have methods to do what is needed (like `Option::or_else` and the like).
Posted Jul 22, 2022 22:22 UTC (Fri)
by khim (subscriber, #9252)
[Link] (1 responses)
It works just fine and worked for years. I'm just not sure if anyone ever proposed to make it formal part of the C++ standard.
Posted Jul 22, 2022 23:44 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link]
Posted Jul 21, 2022 20:43 UTC (Thu)
by josh (subscriber, #17465)
[Link]
That sounds like a failure to me, not a success.
If the ecosystem is successful, people won't be reinventing the wheel, and will instead be sharing a pile of key components rather than reimplementing them.
Posted Jul 21, 2022 16:28 UTC (Thu)
by SLi (subscriber, #53131)
[Link] (1 responses)
Posted Jul 22, 2022 14:05 UTC (Fri)
by Karellen (subscriber, #67644)
[Link]
I imagine that the solution to this would be to create a generic compiler name equivalent to cc which can be used to refer to either gcc or tcc or clang or icc or whatever. Maybe rsc, which would then be configured to refer to either rustc or gccrs. And, modify the tooling to allow this to be overridden by a RSC environment variable, or on build tool command lines with e.g. make RSC=gccrs. The problem of multiple implementations of a language compiler is not a new one, and good solutions have been thrashed out and evolved to the point where such implementations can coexist on a system and be used interchangeably by a user with very little trouble. There is no need to reinvent the wheel from scratch here; there are good blueprints out there already that should be fairly simple to adapt to a very similar use-case.
Posted Aug 4, 2022 7:10 UTC (Thu)
by ehiggs (subscriber, #90713)
[Link] (1 responses)
Do you have more information on this? It sounds like a crazy story!
Posted Aug 4, 2022 8:59 UTC (Thu)
by farnz (subscriber, #17727)
[Link]
Scroll down to "Knocking out the Competition" in this account of NCR's early sales strategy. Or see if you can find details of the 1912 antitrust lawsuit against NCR, where some executives were found criminally liable for NCR's actions.
Posted Jul 21, 2022 15:49 UTC (Thu)
by dskoll (subscriber, #1630)
[Link] (5 responses)
I think you can legally create such a Debian variant, but you probably wouldn't be allowed to call it "Debian".
Trademark protection is important to protect the reputation of an organization and its software, and I don't think there's any impingement on your freedom if you have to call your derived software something else.
Posted Jul 21, 2022 16:38 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link] (4 responses)
The GNU people endorse this practice, that's why their yacc clone was named bison for example. The idea isn't to fool people who specifically wanted yacc into having bison instead, but to offer this superior product with a different (albeit related) name.
Posted Aug 1, 2022 17:42 UTC (Mon)
by anton (subscriber, #25547)
[Link] (3 responses)
Lots of other GNU programs were just called like their Unix counterparts, so I doubt that GNU Bison is named that way for legal reasons.
Posted Aug 1, 2022 18:24 UTC (Mon)
by farnz (subscriber, #17727)
[Link]
GNU Bison is a reimplementation of traditional UNIX "yacc". As "yacc" is pronounced the same way as "yak", the name GNU Bison is a pun (since yaks and bison are related species of bovine).
Posted Aug 1, 2022 18:27 UTC (Mon)
by mbunkus (subscriber, #87248)
[Link] (1 responses)
Posted Aug 1, 2022 21:14 UTC (Mon)
by anton (subscriber, #25547)
[Link]
Yacc came first, then came Bison, and Bison was a pun on yacc, and it was originally incompatible with yacc. GNU adopted Bison and made it yacc-compatible.
Posted Jul 21, 2022 18:20 UTC (Thu)
by pavon (guest, #142617)
[Link] (8 responses)
I don't think that is a double standard. There are a number of FLOSS licenses that include special requirements when distributing modifications to let recipients know that this is a modified version and not from "official" sources. This is analogous to a trademark license requiring you to use a different name when the software is modified. You are still allowed to make modifications in both cases, there are just rules you have to follow when doing so.
Here are some example licenses all of which are considered Free Software by GNU/FSF and at least some are considered Open Source by OSI, and/or approved for use in the Debian project:
Use of these licenses is discouraged, however it is because of the practical problems they cause, not ideological ones, the same criteria that Debian is applying to the trademark license.
Posted Jul 21, 2022 19:05 UTC (Thu)
by rgmoore (✭ supporter ✭, #75)
[Link] (5 responses)
This is very common. For example, GPL v.3 says:
a) The work must carry prominent notices stating that you modified it, and giving a relevant date. Letting users know they're using a modified version is literally the first requirement for distributing a modified version. It comes before other, more frequently discussed terms, like the requirement to notify the user it is available under the GPL and the requirement to license the entire derived work under the GPL.
Posted Jul 22, 2022 3:43 UTC (Fri)
by NYKevin (subscriber, #129325)
[Link] (4 responses)
Sure, they do for big, complicated forks, but not for "I changed three lines and sent a pull request, can you please take a look at it?" Because, technically, that's a modified version of the original, too.
Posted Jul 22, 2022 12:20 UTC (Fri)
by Sesse (subscriber, #53779)
[Link] (2 responses)
Posted Jul 22, 2022 14:29 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
Cheers,
Posted Jul 23, 2022 2:03 UTC (Sat)
by NYKevin (subscriber, #129325)
[Link]
* AKA "Cathedral-style development."
Posted Jul 22, 2022 22:43 UTC (Fri)
by nhaehnle (subscriber, #114772)
[Link]
Posted Jul 21, 2022 20:02 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (1 responses)
> I don't think that is a double standard. There are a number of FLOSS licenses that include special requirements when distributing modifications to let recipients know that this is a modified version and not from "official" sources. This is analogous to a trademark license requiring you to use a different name when the software is modified. You are still allowed to make modifications in both cases, there are just rules you have to follow when doing so.
The standard is *different*, not "less demanding".
In UK law, the difference must be "obvious to an informed observer". Which is why the legal spat between Apple and Samsung over rounded corners was so stupid - how are you supposed to confuse the two phones?
The requirement in so many Free Software licences to place a prominent notice saying you modified it is, in part, to make it clear you are complying with trademark law. (Although I doubt that's what the drafters had in mind, but that is the effect.)
At the end of the day, Copyright Law is meant to stop you stealing someone else's work, Trademark Law is there to stop you stealing someone else's name and reputation. That's why, if there's a guy called MacDonald selling burgers, the Big D can't muscle in and stop him using his own name. They can, however, stop J. Random Joe from *changing* his name to MacDonald specifically to open a burger joint.
Cheers,
Posted Jul 21, 2022 20:55 UTC (Thu)
by rgmoore (✭ supporter ✭, #75)
[Link]
IIRC, the dispute between Apple and Samsung was about design patents, not about trademarks.
I would put it slightly differently. It isn't about trademark law per se but about trying to achieve essentially the same goal trademarks serve. It's an attempt to make it easy for the public to distinguish between the original and modified versions even as the author of the original authorizes the modified versions. It functions well with trademark law because they're trying to achieve the same goal, but it doesn't depend on trademark law to succeed.
I'm not 100% sure if they can or can't keep someone named MacDonald from naming his burger restaurant after himself. I know, for example, that the Olympic Games have some kind of ridiculously broad trademark on anything called Olympic anything, which they are very aggressive in enforcing in host cities during the time around the games. This is going to be a big pain for businesses located along Olympic Boulevard in Los Angeles around the 2028 Games, since many of those businesses have used the street name as part of their business.
What is completely clear, though, is that trademarks can extend far beyond a name. For example, if that restaurateur named MacDonald was allowed to use his name on his hamburger place, he wouldn't be allowed to call one of his burgers the Big Mac, use the golden arches on his sign, advertise using the tag line "I'm lovin' it", or probably even use the same colors of red and gold for his restaurant's color scheme that the fast food behemoth uses. Similarly, businesses on Olympic Boulevard might be able to continue using their names, but they certainly won't be able to use the five linked rings, images of gold medals, or anything else that suggests an association between them and the Olympic Games. All those things would create confusion in the public, which is what trademark is intended to prevent.
Posted Jul 21, 2022 19:19 UTC (Thu)
by jhhaller (guest, #56103)
[Link] (3 responses)
By the way the conflict over the Java trademark was with Microsoft's implementation which had differences with Sun Java. Microsoft agreed to never use the term "Java compatible" again. I think that lawsuit explored the limits of what can be controlled with a trademark. The limits are more than just the executable name, but also include other marketing material, as "Java compatible" doesn't appear in the executable name. It also shows limitations of a loose definition of compatibility, Sun had an automated test which would demonstrate compatibility.
Posted Jul 21, 2022 19:37 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (2 responses)
Bonus points for anybody who knows who it belongs to :-)
Cheers,
Posted Jul 21, 2022 19:59 UTC (Thu)
by rgmoore (✭ supporter ✭, #75)
[Link]
I believe it's the trademark for Bass Ale.
Posted Jul 21, 2022 20:09 UTC (Thu)
by nedrichards (subscriber, #23295)
[Link]
Posted Jul 22, 2022 2:55 UTC (Fri)
by pabs (subscriber, #43278)
[Link]
4. Integrity of The Author's Source Code
Posted Jul 22, 2022 9:37 UTC (Fri)
by k3ninho (subscriber, #50375)
[Link]
>I think the key point is whether everyday use and interoperability of a modified version falls foul of trademark law.
> Unless you can legally create and distribute a Debian variant where /usr/bin/firefox shows porn on startup and rustc starts mining bitcoin in the background, I think it can’t be considered fully free software.
This expectation of freedom is loose enough it's nearly meaningless. Like Wol says better than I will, that's basically 'freedom from any restrictions'. We might help the discussion by adding modifiers to form 'freedom from' and 'freedom to' in our statements.
Some people might consider those improvements to be gains, and some people will consider them to be harmful to the reputations earned by these names. The trademark law helps me use reputation to follow 'authentic firefox' and not accidentally supply 'porn-faster firefox' to a customer or family member whose kinks don't align with the kind of adult content shown on start-up. The projects have 'freedom from' name confusion causing reputational damage; I have 'freedom from' name confusion causing me to do the wrong thing.
You still have 'freedom to' make those alternate editions of those projects, but you never had 'freedom to' replace the earned reputation of other people's work with yours -- without participating in their community and leading the authentic project to those goals.
Your individual freedoms are lower priority than our collective freedoms that help us come together to continue our civilised social setting. Wol, again, said it better: 'that's the freedom to be a d*ck', note also that the individual overruling the community becomes a power struggle for which individuals are supreme, and that opens avenues toward physical violence -- so let's stay civilised and work within the established normal tolerances of society.
K3n.
Posted Jul 21, 2022 18:38 UTC (Thu)
by atnot (guest, #124910)
[Link] (18 responses)
It does highlight another good reason to register your project's trademark though, to protect yourself from people like him.
Posted Jul 21, 2022 20:07 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
If someone makes a hostile registration, any evidence that he knows (or should have known) that you were using (TM) and his registration will be yanked. Won't save you the legal spat and costs, but makes it much more certain you'll win.
Cheers,
Posted Jul 21, 2022 20:09 UTC (Thu)
by roc (subscriber, #30627)
[Link] (15 responses)
Posted Jul 22, 2022 3:37 UTC (Fri)
by motk (subscriber, #51120)
[Link] (14 responses)
Posted Jul 24, 2022 0:09 UTC (Sun)
by ttuttle (subscriber, #51118)
[Link] (13 responses)
Posted Jul 24, 2022 7:37 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (10 responses)
Unfortunately, it also seems to attract the assholes who foment conflict who claim to have it ...
(Although there's also the OCD angle where people on the spectrum just can't let go ... Aspergers should be able to recognise that and deal with it, though ...)
Cheers,
Posted Jul 25, 2022 5:23 UTC (Mon)
by jezuch (subscriber, #52988)
[Link] (4 responses)
I believe it's just a coping strategy for people who don't want to be assholes but still inadvertently run into conflicts. It's not an inherent trait.
(At least that's *my* coping strategy.)
Posted Jul 25, 2022 13:07 UTC (Mon)
by atnot (guest, #124910)
[Link]
(I shudder to think what CS would look like if being toxic online was actually a common reaction instead, given the amount of us here)
Posted Jul 25, 2022 15:48 UTC (Mon)
by ttuttle (subscriber, #51118)
[Link] (1 responses)
Yeah, this absolutely goes both ways. Thanks in large part to the double empathy problem, conflicts between autistics and non-autistics often go poorly. Some autistics handle this by avoiding conflict, some handle it by consciously learning to navigate conflicts, and some handle it by barreling through conflicts anyway.
Posted Aug 9, 2022 23:59 UTC (Tue)
by sammythesnake (guest, #17693)
[Link]
There have been many times when I've felt I'm doing a much better job of understanding an "NT" than they are at understanding me. I've generally assumed that my advantage in those situations is a massively greater amount of *experience* at dealing with people different from myself, because almost everyone I deal with *is* different from myself...
Posted Jul 29, 2022 2:38 UTC (Fri)
by ssokolow (guest, #94568)
[Link]
Posted Jul 25, 2022 15:45 UTC (Mon)
by ttuttle (subscriber, #51118)
[Link] (4 responses)
Personally, I tend to think systematically, but communities are systems too. Rust's license might forbid using their trademark, but my social 'rules' forbid assuming I'm correct and assuming others' motives/reasoning/etc..
So I might have noticed the same issue that he had, but I would've framed my report more like "Hi, I was looking at A, and it seems like B, which I'm worried would cause big problem C for the project. Is this something that needs fixed, or a risk you're willing to take, or am I missing something? Thanks, me", and I would've framed my follow-ups as "Cool, can you explain why D thinks this is not an issue?".
It's secretly still quite a rigid form of interaction, but on top of the technical issue it layers "we are all humans with different understandings of this problem, and the meta-problem is getting everyone on the same page".
Posted Jul 26, 2022 4:49 UTC (Tue)
by NYKevin (subscriber, #129325)
[Link] (2 responses)
* If I'm wrong, then I've explicitly invited the other person to explain that fact to me, they will hopefully do it in a calm and tactful manner, and neither of us loses face. This also gives me a good excuse to say "hm, should we put a comment here or maybe refactor it somehow?"
Of course, you don't want to just repeat the same phrase over and over again, so I've found that phrasing critiques as questions also works well (e.g. "could this pointer be NULL?")
Posted Jul 26, 2022 5:12 UTC (Tue)
by ttuttle (subscriber, #51118)
[Link]
Posted Jul 28, 2022 6:28 UTC (Thu)
by madhatter (subscriber, #4665)
[Link]
Posted Aug 12, 2022 18:02 UTC (Fri)
by fest3er (guest, #60379)
[Link]
[digression]
This supports my assertion that natural languages (English, German, Swahili, et alia) are, indeed, programming languages in that the speaker/writer attempts to program the listener's/reader's neural net to at least understand the former's thoughts, if not to actually think the same thoughts. Those who take the time and make the effort to speak/write more correct programs are better understood in general.
[/digression]
Posted Jul 26, 2022 2:15 UTC (Tue)
by motk (subscriber, #51120)
[Link] (1 responses)
Posted Jul 29, 2022 2:40 UTC (Fri)
by ssokolow (guest, #94568)
[Link]
Posted Jul 23, 2022 21:35 UTC (Sat)
by flussence (guest, #85566)
[Link]
(Screaming at volunteers over some software using systemd while refusing to lift a finger to contribute a fix, sounds like a stereotypical "Veteran Unix Admin")
Posted Jul 21, 2022 20:42 UTC (Thu)
by josh (subscriber, #17465)
[Link] (4 responses)
There has been some discussion about developing a trademark policy that would allow for other compilers to be described as "Rust compilers", but that policy doesn't exist yet, and in the absence of such a policy, "gccrs" is a name that doesn't have associated expectations about compatibility.
Posted Jul 21, 2022 20:51 UTC (Thu)
by josh (subscriber, #17465)
[Link]
Naming was one thing that came up a few times very early on, and generally speaking, every gccrs developer I've talked to has thought it entirely reasonable to stick with the "gccrs" branding.
Posted Jul 22, 2022 8:54 UTC (Fri)
by philbert (subscriber, #153223)
[Link] (2 responses)
"Some places still say "GCC Rust" or "Rust GCC", but that is a mistake that should be corrected."
I have sent a message to the Rust foundation here asking for clarification here, we have a Twitter https://twitter.com/gcc_rust and our GitHub organisation https://github.com/Rust-GCC I will make any changes as required.
I would very much appreciate it in future if you could contact us directly about things like this.
Posted Jul 22, 2022 9:51 UTC (Fri)
by josh (subscriber, #17465)
[Link] (1 responses)
Posted Jul 22, 2022 12:18 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link]
Even with multiple clarifications, it still isn't clear to me why you are calling it is a mistake. Even in the absence of explicit trademark guidelines, this reads to me more like a functional description ie) A compiler for the Rust language, which should be permissible. mrustc calls itself "Alternative rust compiler" and would you then also object to that? I think the best thing for Rust foundation to do is proactively put out guidelines for this that would cover alternative implementations including whatever safeguards you need to ensure compatibility without blindly enforcing a borrow checker because mrustc doesn't have one.
Posted Jul 22, 2022 2:59 UTC (Fri)
by pabs (subscriber, #43278)
[Link]
Posted Jul 22, 2022 6:32 UTC (Fri)
by rsidd (subscriber, #2582)
[Link] (4 responses)
So a solution could be to relinquish the Rust trademark and turn the name into a specification, and the official implementation could be "Ferric Rust" or whatever (trademarked) while gccrs could be "GCC Rust" (not violative of the trademark). The Rust Foundation could both steward the development of Ferrous Rust, and maintain the Rust specification which can be used to validate/certify other implementations.
Posted Jul 22, 2022 13:39 UTC (Fri)
by tialaramex (subscriber, #21167)
[Link]
It's worth remembering that C++, a language in a similar ballpark, has spent many years writing a ~2000 page standards document which, despite that length:
Gives up responsibility for even describing how to mechanically answer the question "Is this a C++ program?", with the phrase "Ill-formed, no diagnostic required" repeated many times during the document.
Silently ignores actual tricky real world implementation problems, such as pointer provenance, as litigated repeatedly on LWN
Reserves big swathes of stuff you'd need to do as an implementer, as "Undefined Behaviour" so that low level facilities necessarily must be implemented by the compiler vendor who will need to hide an escape hatch where they define some of this behaviour to use it.
Isn't publicly available (ISO wants $$$ for a CD, there are drafts for free, but not the final document)
Yet still is subject to continual bickering about what it means, and why, like a religious text.
Posted Jul 28, 2022 14:06 UTC (Thu)
by tobiasvl (guest, #159949)
[Link]
Posted Jul 28, 2022 14:57 UTC (Thu)
by dvdeug (guest, #10998)
[Link] (1 responses)
Posted Jul 28, 2022 17:57 UTC (Thu)
by atnot (guest, #124910)
[Link]
Posted Jul 24, 2022 20:26 UTC (Sun)
by ballombe (subscriber, #9523)
[Link] (12 responses)
Posted Jul 25, 2022 6:07 UTC (Mon)
by rsidd (subscriber, #2582)
[Link] (11 responses)
Posted Jul 30, 2022 14:13 UTC (Sat)
by flussence (guest, #85566)
[Link]
I count 41 packages in the distro repos that link against webkit-gtk, 75 that use qtwebengine, ~20 distinct binaries built on chromium, one that uses *dillo*. You know what's not in that list? Servo. XULRunner. Firefox. We really need an alternative but Mitchell Baker's $4 million salary sure isn't making that happen.
Posted Jul 30, 2022 17:31 UTC (Sat)
by brunowolff (guest, #71160)
[Link] (9 responses)
Posted Jul 31, 2022 0:52 UTC (Sun)
by rahulsundaram (subscriber, #21946)
[Link] (5 responses)
Source?
Posted Jul 31, 2022 5:18 UTC (Sun)
by brunowolff (guest, #71160)
[Link] (4 responses)
Posted Jul 31, 2022 11:19 UTC (Sun)
by rahulsundaram (subscriber, #21946)
[Link] (3 responses)
Posted Aug 4, 2022 20:48 UTC (Thu)
by brunowolff (guest, #71160)
[Link] (2 responses)
Posted Aug 5, 2022 5:27 UTC (Fri)
by zdzichu (subscriber, #17118)
[Link] (1 responses)
Posted Aug 5, 2022 13:51 UTC (Fri)
by hummassa (subscriber, #307)
[Link]
Posted Jul 31, 2022 1:10 UTC (Sun)
by rsidd (subscriber, #2582)
[Link] (2 responses)
Posted Jul 31, 2022 5:01 UTC (Sun)
by brunowolff (guest, #71160)
[Link] (1 responses)
Posted Jul 31, 2022 15:29 UTC (Sun)
by rahulsundaram (subscriber, #21946)
[Link]
His information is correct, the Fedora maintainer has his own fork because upstream is dead.
https://gitlab.com/anto.trande/icecat
You can find it by looking at the spec repo in
https://src.fedoraproject.org/rpms/icecat
Living with the Rust trademark
Living with the Rust trademark
Wol
Living with the Rust trademark
Living with the Rust trademark
Wol
Living with the Rust trademark
Living with the Rust trademark
Polonius
Polonius
Avoiding Rice's theorem, Turing completeness etc in practice
Avoiding Rice's theorem, Turing completeness etc in practice
Avoiding Rice's theorem, Turing completeness etc in practice
Polonius
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
> The other issue is the stuttering of `foo ? foo : some_default;` that I heard was proposed as `foo ?: some_default` at one point, but never got anywhere apparently.
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
GNU Bison is probably named that way because it is derived from a program called Bison.
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
All the things we three have written is correct:
Living with the Rust trademark
Living with the Rust trademark
* PHP License 3.01 - Derivative works may not use PHP in their name without permission.
* LaTeX Project Public License 1.2 - requires renaming modified files.
* Xinitd - requires version number and license document to be modified to specify who made changes.
* Q Public License - Can only distribute changes as patches
* IPA Font License - Modified works must not use same name as original.
Living with the Rust trademark
There are a number of FLOSS licenses that include special requirements when distributing modifications to let recipients know that this is a modified version and not from "official" sources.
You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Wol
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Wol
Living with the Rust trademark
Which is why the legal spat between Apple and Samsung over rounded corners was so stupid - how are you supposed to confuse the two phones?
The requirement in so many Free Software licences to place a prominent notice saying you modified it is, in part, to make it clear you are complying with trademark law.
That's why, if there's a guy called MacDonald selling burgers, the Big D can't muscle in and stop him using his own name.
Living with the Rust trademark
Living with the Rust trademark
Wol
Living with the Rust trademark
Bonus points for anybody who knows who it belongs to :-)
Living with the Rust trademark
Living with the Rust trademark
...
The license may require derived works to carry a different name or version number from the original software. (This is a compromise. The Debian group encourages all authors not to restrict any files, source or binary, from being modified.)
Living with the Rust trademark
Weird starting point, given that the copyright holder has to give you a licence under the terms of a (the example here is Debian-approved) free copyright licence for ... you to operate under that licence.
The standard is well-understood: does your change cause confusion?
Living with the Rust trademark
Living with the Rust trademark
Wol
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Wol
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Rejection Sensitive Dysphoria can also be involved... though I usually see it brought up in correlation with ADHD.
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
* If I'm right, having to explain something generally tends to engage the other person's critical thinking rather than their social status, and so it is more likely that they will agree with me rather than getting defensive.
* If the issue is more complicated than a simple right/wrong dichotomy, and needs further discussion, then it's easier to do that if we're both thinking in analytical terms rather than "who is right" terms.
* The important thing to keep in mind is that this is *not* a rhetorical strategy, it is a genuine invitation to have an open-ended discussion. I am not assuming that I know what the answer is going to be. I have occasionally noticed people interpret it as condescension, but it must be emphasized that I really do see this as a conversation opener, and not merely as a more gentle way to deliver a criticism. Unfortunately, it can be difficult to communicate this fact over a textual channel.
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
iceweasel
iceweasel
iceweasel
iceweasel
iceweasel
iceweasel
iceweasel
iceweasel
iceweasel
iceweasel
The last release of icecat was in 2019, version 60.7.0. Using icecat means ignoring over three years of security fixes. Security holes are somewhat more of a privacy risk than anything Mozilla does.
iceweasel
iceweasel
Name : icecat
Version : 91.12.0
iceweasel