https://internals.rust-lang.org/t/rust-s-freedom-flaws/11533 https://lists.debian.org/debian-legal/2021/05/msg00006.html https://foundation.rust-lang.org/policies/logo-policy-and-media-guide/ this is an extremely serious situation that exposes debian to a greater level of risk that was undergone for the last Mozilla-Foundation Trademark fiasco, iceweasel Rust's Trademark requirements are that "you must seek our explicit permission before distributing patches". Uses that require explicit approval 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. there are dozens of such patches and every single one of them, unless explicit permission has been sought, is a DIRECT Trademark violation https://sources.debian.org/patches/rustc/1.36.0+dfsg1-2/ the over-ride of the Trademark on "Free" software is Lawful and in this case makes rust (and cargo) non-free software. unlike the Iceweasel debacle, the linux kernel is upstream merging rust, potentially making the entire linux kernel critically dependent on a non-free compiler. there is the additional issue that although Debian might seek and be granted explicit permission for a Trademark License Grant to Distribute, that does not cover Derivatives, which would also need to explicitly seek their own permission https://www.debian.org/derivatives/ https://devuan.org this has been discussed that DFSG Guideline 8 is violated by even attempting to seek a License specific to Debian https://www.mail-archive.com/debian-legal@lists.debian.org/msg45464.html 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. this one cannot be ignored.
Hello I don't think it is a big deal but I will chat with some people on the Rust side about this. Cheers, Sylvestre (who managed the iceweasel/firefox thing) Le 27/06/2022 à 13:52, lkcl a écrit :
The full paragraph [1] is "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." By only providing half of that quote in your bug report, I think you're missing important context. I think that would probably be easy enough to comply with. I also think that is fairly in line with trademark policies in general. If someone significantly modifies Debian, I believe the Debian Project would insist that they use a different name for their product despite the DFSG and despite that Debian is free and open source. For instance, here is an excerpt without context from Debian's policy: "You cannot use Debian trademarks in a company or organization name or as the name of a product or service." [1] https://foundation.rust-lang.org/policies/logo-policy-and-media-guide/ [2] https://www.debian.org/trademark Thank you, Jeremy Bicha
everything is "fine" as long as: 1) the Mozilla Foundation acts reasonably and non-discriminatorily (FRAND applies to Trademarks just as it applies to patent Licensing) 2) the Mozilla Foundation does not appreciate quite how much power it actually has under Trademark Law. given that this is between Free Software Groups i would expect the discussion to remain civil and reasonable, and for them to drop or modify the unachievable nonfree constraint, but please for goodness sake do not let the civility of the interaction lull you into a sense of false safety. under the Trademark as they have defined it, the Mozilla Foundation is perfectly permitted to issue Debian a Legal Notice to Cease and Desist distribution of the Unlawfully patched rustc binaries. l.
Hi Luke,
Hi all others,
Let's continue thinking several steps ahead.
* Allow all room to move forward
* Accept there is NO "request pending" documentation,
trust https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013920#10
that it is "work in progress"
* Ask over six weeks how much you should worry about this
* Meanwhile team-up with other Linux distributions
* Meanwhile create a concept letter you want to have, like
We, Mozilla Foundation grant these Linux distributions
* foo
* bar
* debian
* baz
to distribute our Rust and our Cargo that we still
can recognice as our Rust and as our Cargo.
* Continue enjoying Rust and Cargo
Regards
Geert Stappers
P.S.
a Trade Mark is a request for respect, not a demand for respect.
And yes, respect is something like trust, it has to be earnt.
hi Geert, sorry i have an odd mailer which can only toppost. as in the initial post, i found a link that indicates that such explicit requests are in direct violation of DFSG Section 8, namely that others (including Derivatives) may take the source that goes through Debian and continue to use and distribute it without limit or restriction. the message to the Mozilla Foundation needs to be more along the lines, "please remove the restriction from the Trademark License so that we may comply with DFSG Section 8, otherwise we have to do an iceweasel". l.
;-) Acknowledge on "odd mailer" and thanks for NOT poluting the Bug Tracking System with topposts (thanks for preventing needless scrolling) Ah, I missed that. Yeah, avoiding another iceweasel is a good thing. Groeten Geert Stappers
the alternative is to work with the Mozilla Foundation to rewrite their Trademark License.
the *intent* is clear, they do not trust Licensees (distributors) to "damage" the rust API, which is perfectly reasonable.
therefore, why don't they just say that?
"if a distributor performs source code modifications to a
published revision that cause security holes, cause API or
language incompatibilities or cause other end-user
complaints, then this a Trademark Violation"
something along these lines is waaay more sensible than pissing about trying to completely unreasonably "lock down" the source code.
normally i would suggest that they convert the Trademark to a Certification Mark because the rust API is a Standard, and its unit tests the Compliance Suite, but the fact that they sell T-Shirts and merchandise prohibits that from being accepted (sale of products including merchandise is commercial competition with Licensees, and is prohibited under Certification Mark Law but *not* Trademark Law ).
l.
jeremy i didn't see your reply until i checked online. you spotted the second half:
We will usually allow these uses as long as the modifications
are (1) relatively small and (2) very clearly communicated to
end-users.
i did not include this because DFSG 8 is already violated by the first
half. the *very fact* of needing to ask is an unreasonable burden
that is directly in conflict with the entire Libre/Open Concept.
imagine a Copyright License that said, "you MUST come to us to
ask permission to distribute modified versions oh but otherwise this License is a Free/Open One, No Really"
absolutely everyone would freak out and agree that is non-free, and the package either moved to nonfree or pulled entirely.
this unfortunately is exactly what the Rust Trademark has done:
added *additional* Lawfully-enforceable requirements that must
legally be complied with or suffer the consequences.
* It's Free because Copyright License BSD (whatever)
* Oh But under the Trademark We Don't Grant Distribution
Rights for Derivative Works
and no, the existence of the Copyright License does *not* invalidate or override the Legal requirement to also comply with Trademark Law. it is astonishing the number of FOSS developers who genuinely believe that they can blatantly disregard Trademark Law "Because Open Source"
this is standard fare as part of Trademark Law. it causes "confusion".
l.
https://www.debian.org/doc/debian-policy/ch-archive.html#the-debian-free-software-guidelines urrr.... 50% of the clauses of DFSG 2.1 are violated section 2.1 3 is violated 3. Derived Works The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software. the additional conditions remove the redistribution rights normally associated with Free Software Licenses, requiring explicit consent should "modifications and derived works" be made. section 2.1.5 is violated 5 No Discrimination Against Persons or Groups The license must not discriminate against any person or group of persons. distribibutors constitute a "group of persons" and consequently they are discriminated against by the imposition of the restriction requiring explicit permission to modify. section 2.1 4 is also violated 4 Integrity of The Author’s Source Code The license may restrict source-code from being distributed in modified form only if the license allows the distribution of “patch files” with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. with the Trademark License creating an additional (Aggregate) License that overrides and nullifies the "normal" expected Copyright Licenses, section 4 is violated. section 2.1 7 is violated 7 Distribution of License The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties. the imposition of the additional License Conditions from the Trademark *are themselves* a violation of this condition section 2.1 7 is violated as already discussed section 2.1 9 is violated 9 License Must Not Contaminate Other Software The license must not place restrictions on other software that is distributed along with the licensed software. given that the linux kernel will soon be critically dependent on having a rust compiler...
https://developers.slashdot.org/story/22/07/17/0110250/gcc-rust-approved-by-steering-committee-beta-likely-next-april and now it becomes Unlawful for Debian to distribute gcc with patches, as well [without the explicit consent of the Mozilla Foundation, an action which is in direct violation of DFSG] l.
https://developers.slashdot.org/story/22/07/17/0110250/gcc-rust-approved-by-steering-committee-beta-likely-next-april and now it becomes Unlawful for Debian to distribute gcc with patches, as well [without the explicit consent of the Mozilla Foundation, an action which is in direct violation of DFSG] this appears to have been added recently (or i missed it): 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 note that this excludes the right to: * add a patch to add documentation * add a patch to add a Debian README * add a patch to add a debian/copyright file * add a patch to add optimisations * add a patch to fix serious security vulnerabilities * convey to others the right to modify [GPL Copyright License requirement] all of the limitations whilst looking perfectly reasonable are unfortunately in direct conflict with not only 50% of the DFSG but also in direct violation of the GPL (under which gcc is released). l.
Thanks for bringing it to our attention, I have consulted with the Rust foundation, we have agreed a change, we think this change solves it. See https://foundation.rust-lang.org/policies/logo-policy-and-media-guide/ for the updated policy. Cheers, Sylvestre Le 27/06/2022 à 13:52, lkcl a écrit :
Documentation updates should be done upstream. This is purely Debian documentation. They do not impact Rustc. Same. As the initial packager of Rustc (and llvm), I would reject such changes. Optimisations should be done upstream and not downstream. Such patches are part of the "adding patches that have been released upstream" gcc specific issues should be on the gcc side, not rustc. Cheers, Sylvestre
fixed 1013920 thanks Le 27/06/2022 à 13:52, lkcl a écrit :
i've opened up a second bug for gcc because it is also about to become affected, not in the same way, but in a worse way. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015242 whilst 50% of DFSG 2 is violated by the Rust Trademark (as it stands, with the new clauses), gcc is in an even worse situation because the Rust Trademark conficts directly with the GPL as well. this is a complex multi-faceted issue: please do not close the bugreport until all facets of the conflict brought to your attention have been resolved. or... you can... but that will force me into the position of re-raising another report, and i am too busy to do that, and you risk me giving up and not caring. l.
reopen 1013920 sorry, Sylvestre, if you could possibly wait, on something this serious, for a response as to whether the fix is valid, that will avoid me having to spend my time reopening the issue or creating a second bugreport.
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 ah! we may have just had some cross-over. did you mean the sections "fixing local paths" (etc)? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013920#60 no, that would not be sufficient. it still violates DFSG (most of it). there is also the issue that even placing a public copy of source code on a git repository also constitutes "Distribution". i gave some suggestions which would be much more reasonable (and general) already, they may have been missed: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013920#40 those much more general statements basically say "we trust you not to do any damage under our name" the new additions basically say: "you're clearly too stupid to be trusted so we're going to lock out your rights" it should therefore come as no surprise that trying to go in that direction would directly conflict with everything that DFSG strives towards. l.
This bug is fixed. Please don't reopen it. We are both now compliant with the DFSG and the Rust trademark. I do understand that you feel differently but this worked well for years for Firefox and Thunderbird and Debian derivatives. This isn't a different situation. Regards, Sylvestre / / Le 18/07/2022 à 11:29, Luke Kenneth Casson Leighton a écrit :
i can see that you believe that to be true, otherwise you would not have closed it. what i am upset by is that you did not consider my opinion or insight to be worth consulting. i am deeply offended by that. l.
ah! some fascinating news (from another discussion) pulled up the fact that ADA converted to a Certification Mark, back in 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. *that* is what the Rust Foundation *should* be doing. messing about prohibiting patching is going to end in tears. if they instead state, "You must run the Test Suite (unmodified, as provided by us), and it the results are a 100% pass then you're free and clear to distribute without limitation [and use the word "rust"] in the distributed package" then *that* would solve all of the problems. unfortunately, as i said in comment #40 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013920#40 if the Rust Foundation tries right now to convert the Trademark into a Certification Mark it will be DENIED because they are selling product (hats, T-shirts) and a Certification Mark Holder cannot compete with its Licensees. if they stop selling T-shirts and Merchandise and give assurances to the Trademark Office that they will not do so then they should be ok to convert to a Certification Mark. l.