Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1013920: rust-all: Debian violating Rust Trademark (as serious a situation as "iceweasel")
106 views
Skip to first unread message
lkcl
Jun 27, 2022, 8:00:03 AM6/27/22
to
Package: rust-all
Severity: serious
Tags: upstream
Justification: Policy 2.1
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...@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.
-- System Information:
Severity: serious
Tags: upstream
Justification: Policy 2.1
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...@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.
-- System Information:
Sylvestre Ledru
Jun 27, 2022, 8:10:04 AM6/27/22
to
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)
> _______________________________________________
> Pkg-rust-maintainers mailing list
> Pkg-rust-m...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers
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)
> Pkg-rust-maintainers mailing list
> Pkg-rust-m...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers
Jeremy Bicha
Jun 27, 2022, 8:30:03 AM6/27/22
to
The full paragraph [1] is
"Distributing a modified version of the Rust programming language or
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
"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
lkcl
Jun 27, 2022, 9:10:04 AM6/27/22
to
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.
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.
lkcl
Jun 27, 2022, 10:10:04 AM6/27/22
to
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.
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.
lkcl
Jun 27, 2022, 10:50:04 AM6/27/22
to
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.
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.
lkcl
Jun 28, 2022, 12:30:03 AM6/28/22
to
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...
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...
lkcl
Jul 18, 2022, 4:20:04 AM7/18/22
to
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]
On Mon, Jun 27, 2022 at 3:38 PM lkcl <luke.l...@gmail.com> wrote:
>
> 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.
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.
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]
On Mon, Jun 27, 2022 at 3:38 PM lkcl <luke.l...@gmail.com> wrote:
>
> 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.
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.
Sylvestre Ledru
Jul 18, 2022, 5:30:04 AM7/18/22
to
>
> 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
This is purely Debian documentation. They do not impact Rustc.
> * add a patch to add a debian/copyright file
Same.
> * add a patch to add optimisations
As the initial packager of Rustc (and llvm), I would reject such
changes. Optimisations should
be done upstream and not downstream.
> * add a patch to fix serious security vulnerabilities
Such patches are part of the "adding patches that have been released
upstream"
> 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).
Cheers,
Sylvestre
Sylvestre Ledru
Jul 18, 2022, 5:30:04 AM7/18/22
to
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 :
> _______________________________________________
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 :
Luke Kenneth Casson Leighton
Jul 18, 2022, 5:50:04 AM7/18/22
to
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Mon, Jul 18, 2022 at 10:16 AM Sylvestre Ledru <sylv...@debian.org> wrote:
>
> 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.
ah! we may have just had some cross-over.
> See
> https://foundation.rust-lang.org/policies/logo-policy-and-media-guide/
> for the updated policy.
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.
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Mon, Jul 18, 2022 at 10:16 AM Sylvestre Ledru <sylv...@debian.org> wrote:
>
> 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.
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.
Luke Kenneth Casson Leighton
Jul 18, 2022, 6:30:03 AM7/18/22
to
On Mon, Jul 18, 2022 at 11:06 AM Sylvestre Ledru <sylv...@debian.org> wrote:
>
> This bug is fixed.
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.
>
> This bug is fixed.
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.
Luke Kenneth Casson Leighton
Jul 18, 2022, 10:30:04 AM7/18/22
to
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.
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.
Damian Yerrick
Jul 19, 2022, 8:10:03 AM7/19/22
to
Requiring work to be done upstream fails the desert island test,
as described by Thomas Bushnell in
<https://lists.debian.org/debian-legal/2002/01/msg00010.html>
> A good test case for whether a license is free (for issues like this)
> is whether a disconnected group of people on a desert island could
> distribute the software among themselves. In the vim case, they
> cannot. (For example, if the vim maintainer flies over the island and
> drops down a message saying "you must hereby send me your changes",
> how are the people down below to comply?) The fact that the vim
> maintainer can send the request does not say anything about whether
> the people receiving it could reply.
> Documentation updates should be done upstream.
or fixing security vulnerabilities upstream requires an Internet
connection when the changes are made. It does not allow a relatively
isolated community with no consistent access to the Internet to make
these changes.
as described by Thomas Bushnell in
<https://lists.debian.org/debian-legal/2002/01/msg00010.html>
> A good test case for whether a license is free (for issues like this)
> is whether a disconnected group of people on a desert island could
> distribute the software among themselves. In the vim case, they
> cannot. (For example, if the vim maintainer flies over the island and
> drops down a message saying "you must hereby send me your changes",
> how are the people down below to comply?) The fact that the vim
> maintainer can send the request does not say anything about whether
> the people receiving it could reply.
> Documentation updates should be done upstream.
> Optimisations should be done upstream and not downstream.
> Such patches are part of the "adding patches that have been released
> upstream"
Updating documentation upstream, adding optimizations upstream,
> upstream"
or fixing security vulnerabilities upstream requires an Internet
connection when the changes are made. It does not allow a relatively
isolated community with no consistent access to the Internet to make
these changes.
Sylvestre Ledru
Jul 19, 2022, 8:20:04 AM7/19/22
to
I didn't say "required". I said that it is the usual (and recommended)
practice from packagers.
On the desert island, you can patch rust packages as much as you want
without forwarding anything upstream.
practice from packagers.
On the desert island, you can patch rust packages as much as you want
without forwarding anything upstream.
0 new messages