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
Comments
Maybe overriding 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/ |
I don't think this allows to distribute our branded Firefox (at least without explicit permission from Mozilla), but I'm no lawyer. |
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. |
@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. |
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.
Well, 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
(well, there is firefox-bin, which is a minimal patchelf of Mozilla
binary release).
|
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? |
Yes, I suppose that would be OK from legal point of view. |
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.
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. |
> 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.
It all depends on the specific license.
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.
As Mozilla claims to allow arbitrary private modification and only
control public distribution of the branded builds, it is likely that
a script that has to be obtained from its own repo and that asks to
specify the source of logos explicitly will not be violating anything,
as Mozilla did not want to write a forbid-everything license.
But, anyway: if you want official branding, why not use firefox-bin
which is produced by patching the library paths into the official
Mozilla binary releases?
We can either follow Debianʼs precedent and use the official branding, or, if we want to be 100% sure, contact Mozilla.
Debian discussed their build system and patching/backporting practices
with Mozilla. In details. The first time they actually didn't reach
complete agreement and called their build Iceweasel (Debian backports
patches, so their browser doesn't correspond to any version released by
Mozilla).
|
What's the downside to this? |
> 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?
I guess the likely scenarios of problems after dependency updates are
slightly different for builds and for dependency patching. Of course,
Firefox has a good chance to be fixed quite quickly.
|
Why is the official Firefox not the one that nixpkgs offers under the package name " |
Why is the official Firefox not the one that nixpkgs offers under the package name "`firefox`"?
Nixpkgs provides expressions that build from source by default, whenever
feasible.
|
Is it fair to say that |
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. |
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 ;-) |
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. |
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. |
@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. |
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. |
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. |
Well, we could mention the |
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. |
@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. |
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. |
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 |
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. |
Thanks @garbas and @sylvestre! |
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. |
To be clear, we expect the same level of quality for the patches and not making features changes. |
Yes, I think that was mentioned clearly in your other comment. |
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.
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.
We now have branding by default, on nixos-unstable. |
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. :-) |
No objections from me. |
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))
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.
I saw the option in the source code and was expecting to be able to install something like
but this package doesn't seem to have an
override
attribute like most.The text was updated successfully, but these errors were encountered: