Does Brave allow the distribution of self-compiled or distro-compiled binaries?

THIS IS NOT A BUG REPORT. HOWEVER, IF YOU ARE FROM THE BRAVE DEV TEAM, PLEASE READ ON.

Description of the issue:
I am currently looking into packaging a built-from-source version of Brave that could make it into Arch Linux Official Community Repo (currently the PKGBUILD file can be found in AUR). However, one thing that’s bothering me is that if Brave allows unofficially built binaries to be distributed by other individual or distros, just like the chromium package provided by Arch.

I hope someone from Brave dev team can clarify this. If this is not allowed or any how against the Brave ToS (which I did not find any entries specifying that distribution of self-compiled binaries is forbidden), then I would say we might consider giving up making Brave a part of the Community Repo.

Thanks a lot for helping!

Regards

Seriously? No one replies?

You can find the license at
brave://settings/help

If you have more specific questions, I suggest you contact Brave Support.
Or maybe @steeven or @Mattches could help you

Thanks. Finally someone could help.
I’ll investigate into MPL 2.0. Meanwhile, the thread would not be labelled as resolved.

Hi there @rdtck

Sorry for the long response time

I think it’s fine to build from source and distribute, but it’s important to make clear that it’s an unofficial distribution. If there’s someone publishing one claiming to be official please let us know

Only Brave Software has the signing keys and service keys used for downloading adblock list, components, etc. Without the service keys, folks using that binary will get ads and will lose a lot of value that Brave adds

Thanks
Brian

2 Likes

But once you enabled the --official_build option during build time, the output binary would label itself as official.

Part of the official build process is the signing. We have our public signing keys shared so the binary that gets output can be verified by anyone as official

With --official_build enabled, there are going to be a lot of config values needed (Google keys for safe browsing, etc) which only the Brave Software owned official build servers have configured. You can stub those config values out (putting fake or empty values)- but the services that Brave consumes at runtime (Safe browsing, fetching extensions, fetching adblock rules, Brave Rewards, Brave News, etc) will fail and folks checking the binary against the signing keys will realize it’s not an official build

TL;DR: Only Brave Software produces the official builds for Brave browser

Hope this helps

Thanks
Brian

2 Likes

Well clarified, but I still have some questions on this.

Let’s take the Chromium builds on Arch Linux as an example. There’s actually an Google API key dedicated for Arch Linux “Official” build on the Arch side, which can be found on the official PKGBUILD. So, I don’t think that will be a problem.

In fact, if you list all the possible params for BUILD.gn of a Brave build, you will see that there’s an option with a default key (see code block below). Not sure if this is Brave’s Google API key.

brave_google_api_key
    Current value = "**REDACTED**"
      From //out/Release/args.gn:23
    Overridden from the default = ""
      From //brave/browser/net/BUILD.gn:8

Second, if Arch wants to provide the users with a distro-built Brave, while maintaining all the Brave features, would there be some official way or channel that other devs could apply for their own service keys to access Brave services? Just like how Chromium in Arch Linux did with Google service keys.

Finally, if someone figured out the built-in Brave service keys and endpoints by reverse engineering the official binary, would it be okay to use these keys to access Brave services (while claiming the build is unofficial)?

Thanks again for answering all these.

1 Like

These service keys can be rotated at any given time; so if the specific key was discovered by reverse engineering, it would only be good for an unspecified amount of time. The concern here is that forks, etc can be making use of Brave Software owned/maintained services which have an ownership cost

wknapik has setup an internal discussion - we’re going to chat more about this case along with other cases. Will share updates here afterwards :smile:

1 Like

I totally understand the situation you described where third-party forks uses the same key and therefore taking advantage of Brave officially maintained services, and I do appreciate it and hope that related issues can be discussed by Brave developers.

However, I would like to summarize my questions:

  1. Does Brave allows other Linux distro ship distro-built packages of Brave browser (this means it’s not a fork)?
    The distro-built version of Brave that we are talking about is Brave itself (not a fork, just vanilla Brave pulled from Brave’s GitHub codebase). There could be patches applied for compiling against other system libraries and toolchains but no changes to any Brave components or branding.

  2. If Brave allows doing so, will there be any proper/official ways or platforms for the package maintainers of those Linux distros to apply for a Brave service key specifically for the purpose of packaging Brave for that distro (could be fixed or rotated) so that we can build distro-shipped Brave packages and conveniently provide it to respective users while not infringing or abusing Brave owned services?

I truely hope that these two questions can be discussed internally.

Thanks again for helping!

@clifton we need ad block services in our fork so is there any way that we can get services keys for that or can we build that service ourselves if the code is opensource ?

Also for a additional example, Discord, as a proprietary software, has given the license or permission to official Arch Repo for packaging Discord as a distro-built package. You can refer to the Arch official GitHub repo for the permission-granting letter and how it’s packaged. This works the same for another proprietary VoIP software called TeamSpeak, and you can check the permission-granting letter and how it’s packaged.

For a simpler solution, Arch can always package Brave browser from a prebuilt official binary, and ship it to the user. However, given that Brave itself is open source and licensed under a proper open-source license, I don’t really see the point of not compiling and packaging Brave from its source for Linux distro packages.

As you have mentioned, it was a potential problem for Brave owned services. Nevertheless, I sincerely hope that there could be a proper way for us packagers to properly obtain various service keys and configurations for distro packaging purposes.

Thanks again for considering this.

This would be a win/win situation:

Allowing distros to ship their own builds would make the Brave browser more popular among Linux uses, wo don’t need to install 3rd party repos but can install right via package manager from trusted distro repos.

Also much more likely builds for all supported platforms are provided or distro maintainers may help solving issues with them upstream. I remember the time it took for Brave to provide aarch64 builds: https://github.com/brave/brave-browser/issues/11836

It also potentially enables an additional code review instance, and one which collects and sorts bug reports and may send them upstream with high quality debug information, or even provide patches.

The common user <> distro <> developer model (as option) has quite some advantages on all sides.

1 Like

Hey @clifton is there any updates on this?

Thanks!