Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to enable enableOfficialBranding on Firefox? #31843

Closed
chris-martin opened this issue Nov 20, 2017 · 35 comments
Closed

How to enable enableOfficialBranding on Firefox? #31843

chris-martin opened this issue Nov 20, 2017 · 35 comments
Assignees

Comments

@chris-martin
Copy link
Contributor

I saw the option in the source code and was expecting to be able to install something like

firefox.override { enableOfficialBranding = true; }

but this package doesn't seem to have an override attribute like most.

@jtojnar
Copy link
Contributor

jtojnar commented Nov 20, 2017

Maybe overriding firefox-unwrapped in your packageOverrides will work.

On a side note, it might be fine to enable it by default since the policies now seem to be more open: https://lwn.net/Articles/676799/

@vcunat
Copy link
Member

vcunat commented Nov 20, 2017

I don't think this allows to distribute our branded Firefox (at least without explicit permission from Mozilla), but I'm no lawyer.

@chris-martin
Copy link
Contributor Author

Yes thanks @jtojnar, that does work.

It sure would be nice to have a binary distribution; it seems very silly right now that we have to go through a huge compile just to change an icon.

@jtojnar
Copy link
Contributor

jtojnar commented Nov 20, 2017

@chris-martin Well, the problem is, distributing the branded binary might be illegal. It might no longer be an issue, see the article I linked above, but if we want to be sure, we need to contact Mozilla.

@7c6f434c
Copy link
Member

7c6f434c commented Nov 20, 2017 via email

@chris-martin
Copy link
Contributor Author

What I'm wondering is, could we distribute the unofficially-branded binary, and then have a disavowed derivation that just patches it to swap in the illegal logo?

@vcunat
Copy link
Member

vcunat commented Nov 20, 2017

Yes, I suppose that would be OK from legal point of view.

@jtojnar
Copy link
Contributor

jtojnar commented Nov 20, 2017

the idea is that getting that icon is either costly (so you know you did it the unofficial way), or goes via Mozilla-approved channel

I would not say the option is there for you. It is there for packagersʼ convenience, so that they do not have to patch the branding out. Only Mozilla or people following the terms are supposed to use it.

have a disavowed derivation that just patches it to swap in the illegal logo

I am not sure using copyrighted/trademarked material that way is permissible any more than using it directly.

We can either follow Debianʼs precedent and use the official branding, or, if we want to be 100% sure, contact Mozilla.

@7c6f434c
Copy link
Member

7c6f434c commented Nov 20, 2017 via email

@chris-martin
Copy link
Contributor Author

why not use firefox-bin which is produced by patching the library paths into the official Mozilla binary releases?

What's the downside to this?

@7c6f434c
Copy link
Member

7c6f434c commented Nov 21, 2017 via email

@chris-martin
Copy link
Contributor Author

Why is the official Firefox not the one that nixpkgs offers under the package name "firefox"?

@7c6f434c
Copy link
Member

7c6f434c commented Nov 21, 2017 via email

@chris-martin
Copy link
Contributor Author

Is it fair to say that firefox-bin is probably what the average desktop user wants to use, not firefox?

@jtojnar
Copy link
Contributor

jtojnar commented Nov 21, 2017

Building from source allows us to apply NixOS specific patches. For example, I want to create a NixOS module which requires https://bugzilla.mozilla.org/show_bug.cgi?id=1170092 I cannot apply that to the binary derivation.

@vcunat
Copy link
Member

vcunat commented Nov 21, 2017

I'm not sure how much the average user cares about the logo of the browser. There's not much else to gain from branding. EDIT: if you dislike their unbranded design, it should be perfectly OK (law-wise) to design our own (nix-themed) logo like Debian and GNU used to; snowflake is actually a nice replacement for fire ;-)

@chris-martin
Copy link
Contributor Author

I'm not sure how much the average user cares about the logo of the browser.

The average user of NixOS right now can tolerate a lot, because NixOS has selected for a weird crowd of nerds, no offense y'all. To the average user in general, yes, familiar logos are an important aspect of usability.

@ttuegel
Copy link
Member

ttuegel commented Nov 21, 2017

Copyright-wise you can get the logos from Mozilla website under a CC license, which allows private modifications. Trademark-wise, Mozilla has requirements about the public display and distribution of material with these logos. Well, I guess misleading users into accidentally locally recombining the official logos with something is at least impolite to your users, and probably would lead to well-founded protests from Mozilla.

The trademark issue is paramount. If you do anything with their logo, including any modification that could conceivably be confused with the original logo, they MUST take action. If they do not take action, then they lose their trademark rights by default under U.S. law. There was a lot of backlash over Debian, but Mozilla's hands are bound very, very tightly. ☹️

@7c6f434c
Copy link
Member

@chris-martin I agree with you re: selection; but I do not think that right now the biggest problem for an «average GNU/Linux desktop user» will be the icon mismatch. If anything, understanding the Nix model of the world and understanding when you do want and do not want to run GC is already a larger thing to learn.

@ttuegel if you do anything with their logo in public (my scenario is very careful about the actual logo being only touched in private), they must take some action (which can be publically demanding that you apply for a trademark license for your use case and granting this license as soon as you send them a detailed description of what you do and don't do).

In the Debian case both sides had their hands tied: Mozilla had their public offer policy (Debian backporting of the patches did violate the letter of this policy at the time of the story, and as you correctly point out ignoring the voilation was not an option), and Debian had their policy of not accepting special favours. And of course Debian did want to distribute the packages. At some point Mozilla did offer that Debian would publiush their specific Firefox patching and testing policy, and Mozilla would give the Debian project a project-specific license to use trademark as long as they follow their written policy (trusting Debian developers to apply the policy honestly). This grant would be non-transferrable (one can verify that a few large distributions do things as they claim to do, but not with unspecified number of downstream forks). Debian said that their policy forbids them to accept this, Mozilla correctly pointed out that they cannot rewrite their public offer quickly and they cannot ignore, so Iceweasel got shipped.

But, I do agree that if we want typical users to get Firefox logo out of the box (and not manually and deliberately tell a script that the logo they happen to want is just by chance Firefox logo), this would probably be trademark abuse, and Mozilla will react.

@globin
Copy link
Member

globin commented Nov 21, 2017

@nbp @garbas, do you think we are in a state where we can enable the official branding, if no, what would be necessary to get us there?

@chris-martin
Copy link
Contributor Author

At the very least I think it would be a win if we could document how to easily customize launcher icons. For example, in my local config I've changed the Pithos desktop entry's icon to be the Pandora logo, without too much trouble, even though I assume that's also a trademark violation.

@jtojnar
Copy link
Contributor

jtojnar commented Nov 21, 2017

At the very least I think it would be a win if we could document how to easily customize launcher icons.

I do not think that this falls within the scope NixOS manual – it is not Nix-specific and it is too niche to warrant inclusion. Edit: If one really wants to customize the icon, a solution can be found quickly by a cursory web search.

@vcunat
Copy link
Member

vcunat commented Nov 21, 2017

Well, we could mention the makeDesktopItem function somewhere in docs.

@ttuegel
Copy link
Member

ttuegel commented Nov 22, 2017

if you do anything with their logo in public (my scenario is very careful about the actual logo being only touched in private), they must take some action (which can be publically demanding that you apply for a trademark license for your use case and granting this license as soon as you send them a detailed description of what you do and don't do).

If we distribute an expression that enables official branding by default, even if the only binary we distribute disables official branding, that is sufficiently public to demand a response. It's the equivalent of selling an unbranded laptop with an Apple (tm) sticker loose in the box (not on the laptop itself) and saying, "Well, I didn't sell it with the sticker attached, so it's not trademark infringement!" A court will probably not see it that way, and more importantly, Apple (Mozilla) will fear that a court will not see it that way.

@7c6f434c
Copy link
Member

@ttuegel My scenario did not do anything by default and required effort from the user and was generic enough w.r.t. logo replacement. I agree with you about the default case.

@garbas garbas self-assigned this Nov 22, 2017
@garbas
Copy link
Member

garbas commented Nov 22, 2017

I asked on internal channels what would be the criteria to have this enabled by default. I hope to have answer soon, but you never know how long this takes. If it is ok with you I'm going to assign this ticket to me and make sure we get a definite answer.

@sylvestre
Copy link

As the person who did part of the work described in the LWN article and release manager working for Mozilla, I can confirm the statement that I made in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815006
@garbas shared with me the list of patches applied for the Nix package. As they are just for portability and tiny modifications, they don't alter the experience of the product. In parallel, Rok also shared the build options. They seem good (even if I cannot judge the quality of the packaging of the underlying dependencies like sqlite, png, etc).
Therefor, as long as you keep the patch queue sane and you don't alter the experience of Firefox users, you won't have any issues using the official branding.

@garbas
Copy link
Member

garbas commented Nov 22, 2017

I'd add to @sylvestre 's comment also that we should probably enable sanboxing and then we would be not diverging from official firefox linux binaries.

@globin
Copy link
Member

globin commented Nov 22, 2017

Thanks @garbas and @sylvestre!

@andir
Copy link
Member

andir commented Jan 31, 2018

Since we received positive feedback regarding enabling official branding per default nothing has changed from what I can see.

Are there still any open points? I'd like to push for enabling the official branding with 18.03.

@sylvestre
Copy link

To be clear, we expect the same level of quality for the patches and not making features changes.
Should be about portability and tiny changes.

@andir
Copy link
Member

andir commented Jan 31, 2018

Yes, I think that was mentioned clearly in your other comment.

andir added a commit to andir/nixpkgs that referenced this issue Feb 1, 2018
As stated by Sylvestre Ledru (@sylvestre) on Nov 22, 2017 at
NixOS#31843 (comment) we
have permission to use the official firefox branding.

Fur purposes of documentation the statement of @sylvestre:
> As the person who did part of the work described in the LWN article
> and release manager working for Mozilla, I can confirm the statement
> that I made in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815006
>
> @garbas shared with me the list of patches applied for the Nix package.
> As they are just for portability and tiny modifications, they don't
> alter the experience of the product. In parallel, Rok also shared the
> build options. They seem good (even if I cannot judge the quality of the
> packaging of the underlying dependencies like sqlite, png, etc).
> Therefor, as long as you keep the patch queue sane and you don't alter
> the experience of Firefox users, you won't have any issues using the
> official branding.
garbas pushed a commit that referenced this issue Feb 1, 2018
As stated by Sylvestre Ledru (@sylvestre) on Nov 22, 2017 at
#31843 (comment) we
have permission to use the official firefox branding.

Fur purposes of documentation the statement of @sylvestre:
> As the person who did part of the work described in the LWN article
> and release manager working for Mozilla, I can confirm the statement
> that I made in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815006
>
> @garbas shared with me the list of patches applied for the Nix package.
> As they are just for portability and tiny modifications, they don't
> alter the experience of the product. In parallel, Rok also shared the
> build options. They seem good (even if I cannot judge the quality of the
> packaging of the underlying dependencies like sqlite, png, etc).
> Therefor, as long as you keep the patch queue sane and you don't alter
> the experience of Firefox users, you won't have any issues using the
> official branding.
@vcunat
Copy link
Member

vcunat commented Feb 10, 2018

We now have branding by default, on nixos-unstable.

@vcunat vcunat closed this as completed Feb 10, 2018
@andir
Copy link
Member

andir commented Feb 10, 2018

Sorry for reviving this issue:

Are there any objections against enabling the branding on 17.09 as well? Since the expressions is almost the same as on unstable there shouldn't be any difference in quality. :-)

@vcunat
Copy link
Member

vcunat commented Feb 10, 2018

No objections from me.

andir added a commit to andir/nixpkgs that referenced this issue Feb 11, 2018
As stated by Sylvestre Ledru (@sylvestre) on Nov 22, 2017 at
NixOS#31843 (comment) we
have permission to use the official firefox branding.

Fur purposes of documentation the statement of @sylvestre:
> As the person who did part of the work described in the LWN article
> and release manager working for Mozilla, I can confirm the statement
> that I made in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815006
>
> @garbas shared with me the list of patches applied for the Nix package.
> As they are just for portability and tiny modifications, they don't
> alter the experience of the product. In parallel, Rok also shared the
> build options. They seem good (even if I cannot judge the quality of the
> packaging of the underlying dependencies like sqlite, png, etc).
> Therefor, as long as you keep the patch queue sane and you don't alter
> the experience of Firefox users, you won't have any issues using the
> official branding.

(cherry picked from commit ce08581 &
discussed at NixOS#31843 (comment))
andir added a commit to andir/nixpkgs that referenced this issue Apr 22, 2018
As stated by Sylvestre Ledru (@sylvestre) on Nov 22, 2017 at
NixOS#31843 (comment) we
should have permission to use the official firefox branding.

Fur purposes of documentation the statement of @sylvestre:
> As the person who did part of the work described in the LWN article
> and release manager working for Mozilla, I can confirm the statement
> that I made in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815006
>
> @garbas shared with me the list of patches applied for the Nix package.
> As they are just for portability and tiny modifications, they don't
> alter the experience of the product. In parallel, Rok also shared the
> build options. They seem good (even if I cannot judge the quality of the
> packaging of the underlying dependencies like sqlite, png, etc).
> Therefor, as long as you keep the patch queue sane and you don't alter
> the experience of Firefox users, you won't have any issues using the
> official branding.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants