Re: Rust trademark policy

[Bone Baboon]

Bone Baboon writes:

> After further reading on the topic and after receiving addition
> feedback I have written an update to my understanding of the Rust
> trademark issue.
> 

The Free Software Foundation's licensing team will be taking a serious
look at the Rust trademark policy issue (no time frame was given).

Re: Rust trademark policy

[Bone Baboon]

After further reading on the topic and after receiving addition
feedback I have written an update to my understanding of the Rust
trademark issue.


Bone Baboon writes:

> Sections
> * Rust trademark policy
> * Impact on free software projects
>
> # Rust trademark policy
>
> Is Rust not free software because of the Rust trademark policy?
> 
>
> Information on the four software freedoms is here:
> .
>
> The trademark section of the Rust readme file
>  says:
>
> ```
> The Rust programming language is an open source, community project
> governed by a core team. It is also sponsored by the Mozilla Foundation
> (“Mozilla”), which owns and protects the Rust and Cargo trademarks and
> logos (the “Rust Trademarks”).
>
> If you want to use these names or brands, please read the media guide.
> ```
> Note that it says that the Mozilla Foundation owns the Rust and Cargo
> trademarks.
>
> The is the media guide linked to in the trademark section of the Rust
> readme file: 
> 
>
> The sections of  that
> look relevant to this question at hand are:
>
> * The "Trademark policy" section says "most commercial uses require
>   permission".  This appears to interfere with "The freedom to run the
>   program as you wish, for any purpose (freedom 0).". 
>
> * The "Uses that require explicit approval" section says "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.".  This appears to interfere with
>   "The freedom to distribute copies of your modified versions to others
>   (freedom 3).". 
>
>  says "This document is
> not an official statement of Mozilla trademark policy, but serves to
> clarify Mozilla’s trademark policy as it relates to Rust.". 
>
> Niko said in
> 
> "You are correct that we intended the trademark to apply when
> distributing a package or other binary called "Rust" -- and in
> particular that if modifications are made, then we would expect a
> trademark request". This appears to interfere with: 
> * The freedom to redistribute copies so you can help others (freedom 2).
> * The freedom to distribute copies of your modified versions to others
>   (freedom 3). 
>
> When I asked about this in #hyperbola@Freenode I was referred to
> .  This open
> issue on the Rust repository issue tracker shows that this is a current
> issue.  In the issue nikomatsakis said "The foundation will be reviewing
> the trademark policy, but it will be up to the board to decide the terms
> that are selected."
>
> # Impact on free software projects
>
> If Rust is not free software then that would impact many free software
> project. 
>
> One example is Linux.  Recently there was a RFC for adding support for
> Rust to the Linux kernel .  Linus
> Torvalds's response is here .
> This would also impact Linux forks such as Linux-libre.
>
> Another example is Firefox.  says "Servo is written
> in Rust, and shares code with Mozilla Firefox". This would also impact
> Firefox forks such as LibreWolf, IceCat and Tor browser.

Re: Rust trademark policy

[Bone Baboon]

Walter Landry writes:

> Bone Baboon writes:
>> * The "Uses that require explicit approval" section says "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.".  This appears to interfere with
>>   "The freedom to distribute copies of your modified versions to others
>>   (freedom 3).". 
>
> This is more or less the same exact problem that caused Debian to rename
> Firefox to Iceweasel.  Eventually, Debian convinced Mozilla to allow
> Debian to use Firefox to refer to the modified versions that Debian
> distributes.
>
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815006

Thank you for sharing that link.

> Ideally, Debian would get a similar dispensation for Rust.

A better outcome than getting as Debian specific dispensation would be
for the Rust trademark policy to be modified to resolve this issue or to
rename Rust and Cargo when distributing copies or modified versions.

Getting a Debian specific dispensation for Rust would not appear to meet
The Debian Free Software Guidelines specifically 8 License Must Not Be
Specific to Debian.

The Debian Free Software Guidelines section 8 License Must Not Be
Specific to Debian:

```
The rights attached to the program must not depend on the program's
being part of a Debian system. If the program is extracted from Debian
and used or distributed without Debian but otherwise within the terms of
the program's license, all parties to whom the program is redistributed
should have the same rights as those that are granted in conjunction
with the Debian system.
```

In :

```
Mozilla recognizes that patches applied to Iceweasel/Firefox don't
impact the quality of the product.
Patches which should be reported upstream to improve the product always
have been forward upstream by the Debian packagers. Mozilla agrees about
specific patches to facilitate the support of Iceweasel on architecture
supported by Debian or Debian-specific patches.

More generally, Mozilla trusts the Debian packagers to use their best
judgment to achieve the same quality as the official Firefox binaries.

In case of derivatives of Debian, Firefox branding can be used as long
as the patches applied are in the same category as described above.
Ubuntu having a different packaging, this does not apply to that
distribution.
```

This appears to be in contradiction to "8 License Must Not Be Specific
to Debian".  The key issue is that the Rust trademark policy is trying
to add further distribution restrictions on copies and modified version
that the license does not have.  In this way the trademark is acting
like additional terms to the license with the disadvantage of not being
well documented and being poorly understood as they have not been
reviewed by the Free Software Foundation or the Open Source Initiative.

Re: Bug#974678: ITP: openh264 -- H.264 encoding and decoding

[Sam Hartman]

> "Bastian" == Bastian Germann  writes:

Bastian> There are H.264 patents that are applicable. I do not know
Bastian> how the existing H.264 implementations in Debian handle
Bastian> this, e.g. x264 or ffmpeg. According to the legal FAQ,
Bastian> these seem to be ignored.

I suspect you meant to say that there are H.264 patents that may be
applicable and that Debian should evaluate this risk using its normal
proocesses and policies for looking at software patents.

THOSE PROCESSES DO NOT INVOLVE debian-legal.  Discussing patents in a
public forum may result in speculative communication--like the assertion
above where you said that patents are applicable and where you probably
meant to say that the patents may be applicable--being produced in
response to allegations of patent infringement.
That harms Debian.
Thus, we have a policy that we discuss patents only in privileged
communication.
See https://www.debian.org/legal/patent


and if you are concerned about a specific patent risk, write to
pate...@debian.org.


signature.asc
Description: PGP signature

Re: Bug#974678: ITP: openh264 -- H.264 encoding and decoding

[Walter Landry]

Bastian Germann writes:
> Am 02.06.21 um 17:33 schrieb Tobias Frost:
>> Is this RFS package now a downloader or the library itself?
>
> It's both. The -dev package is created from the source files and
> resides in main. The library package contains the downloader as a
> postinst script, which checks the known SHA256 hashes.
> There are some example userspace tools available in the package which
> could potentially be packaged in an additional package. I left this
> for a later version.
>
> There is also a chance that reproducible build might be implemented:
> https://github.com/cisco/openh264/issues/893
> When that works, the package could build the lib, verify the resulting
> hashes, and throw away the built binary. That way we could be sure not
> to have any additions to the downloaded library that are not available
> as source.
>
> I think, as Cisco provides the patent license, having the downloader
> in contrib (for some architectures) is better than having the built
> library in main (for all compiling architectures). We could also
> provide both. Any thoughts?

As I understand Debian Policy, downloading anything during postinst is
discouraged, if not banned.  So it would be best to avoid it.

In terms of the patent license, I do not think that x264 has any special
dispensation.  So just directly building and packaging openh264 should
not open Debian to any significant additional liability.  But as always,
the FTP masters will be the final arbiter of that.

Cheers,
Walter