Package Details: basilisk 2022.01.27-1

Git Clone URL: (read-only, click to copy)
Package Base: basilisk
Description: A XUL-based web-browser demonstrating the Unified XUL Platform (UXP)
Upstream URL:
Licenses: GPL, MPL, LGPL
Submitter: bm456
Maintainer: figue (jfigueras, figuepluto)
Last Packager: figue
Votes: 1
Popularity: 0.003055
First Submitted: 2017-12-25 20:34 (UTC)
Last Updated: 2022-01-28 23:44 (UTC)

Dependencies (14)

Required by (0)

Sources (2)

Latest Comments

figue commented on 2022-01-28 23:44 (UTC) (edited on 2022-01-28 23:45 (UTC) by figue)

Probably 2022.01.27 will be the final release of Basilisk. So enjoy it!

micwoj92 commented on 2022-01-10 00:41 (UTC)

Nothing is confirmed now, I guess best is to wait couple weeks/months to see what happens.

figue commented on 2022-01-10 00:37 (UTC)

@micwoj92 yeah, but accourding to forums, it seems the project will be transfered to another maitainer [1]. We can keep this package and change the URLs to the new site or we can remove this package.


micwoj92 commented on 2022-01-09 21:14 (UTC)

Basilisk is discontinued.

figue commented on 2021-09-07 17:08 (UTC)

I'm not interested in maintain this package anymore. Any volunteer to adopt it?

micwoj92 commented on 2021-07-21 04:08 (UTC)

Is tagged now

micwoj92 commented on 2021-07-20 19:59 (UTC)

On Basilisk website

figue commented on 2021-07-20 07:13 (UTC)

@micwoj92 where do you see the 2021.07.19 release? It's not in their gitea:

figue commented on 2020-12-29 19:37 (UTC)

@ccorn thanks! bb0e3d74e61f

ccorn commented on 2020-12-29 18:40 (UTC)

With the new config the chroot build now fails if gtk3 is not installed. Therefore I have added gtk3 to depends in my checkout.

figue commented on 2020-12-26 17:28 (UTC)

@micwoj92 thanks. Done in 374abdaa0978

micwoj92 commented on 2020-12-25 22:23 (UTC)

Thanks. I took this info from about:buildconfig from official binary --enable-application=basilisk --with-external-source-dir=/home/PM4Linux/REPO/MCP/Basilisk --enable-update-channel=release --disable-debug-symbols --enable-jemalloc --enable-default-toolkit=cairo-gtk3 MAKE=/usr/bin/gmake --enable-av1 --enable-eme --enable-gamepad --enable-official-branding --enable-official-vendor '--enable-optimize=-O2 -msse -mfpmath=sse' --enable-strip --disable-tests --enable-updater --enable-webrtc --with-pthreads --x-libraries=/usr/lib64

I would definitely change gtk2 to gtk3 and enable webrtc, eme and av1. webrtc is the reason I am using this over Pale Moon as I needed it. I am not sure what all the options do that this PKGBUILD has but in case of doubt I would contact the forum at

figue commented on 2020-12-25 19:10 (UTC)

@micwoj92 thanks see 5672cf04feff

If you have more suggestions they will be welcome. I only use basilisk to open an old HPE software, so I'm not actively using.

micwoj92 commented on 2020-12-25 02:47 (UTC)

Hello, could you make this a bit more similar to official basilisk build config? Also things like mk_add_options MOZ_MAKE_FLAGS="-j4" are bad because this depends on system.

figue commented on 2020-10-27 17:17 (UTC) (edited on 2020-10-27 17:18 (UTC) by figue)

@CYBERDEViL thanks! 133043f52662

CYBERDEViL commented on 2020-10-27 15:23 (UTC)

They changed their user from MCP to MoonchildProductions. New source URL's:


figue commented on 2020-06-25 21:55 (UTC)

Adopted for now...

Winux commented on 2020-05-29 09:51 (UTC) (edited on 2020-05-29 09:51 (UTC) by Winux)

Hi I have fixed all issues that I found. You can find the new PKGBUILD here:

Winux commented on 2020-05-25 11:39 (UTC) (edited on 2020-05-25 11:40 (UTC) by Winux)

Hi there, I'm having problems. with this package. If I install the basilisk-bin package webrtc is working correctly, but if install this package the webrtc doesn't work.

Can you please fix this issue?

Thanks in advance!

ryan659 commented on 2020-03-10 16:27 (UTC) (edited on 2020-03-10 16:28 (UTC) by ryan659)

Basilisk as of v2020.03.04 now lives in its own repository, which depends on the UXP repository as a git submodule. For this package as it relies on the packaged source rather than git it should be enough to grab the release tarball of Basilisk, plus the UXP commit tagged 88da01c (as mentioned in the release notes, and would be set as a pointer in git) which should be placed in the "platform" folder from the release tarball.

figue commented on 2020-02-09 17:16 (UTC)

Please fix sha256sum:

04571b15fb720535cf390e3004821f22d2f120e720b121fd3046b907714b3e37 v2020.02.06.tar.gz

And don't forget that pkgrel should be 1 when a new version is out.


figue commented on 2020-01-31 00:36 (UTC)

  1. Your are right, just added a comment in basilisk-bin AUR.

  2. I've compiled again several times, and finally using this mozconfig advanced preferences works:

ac_add_options --enable-application=browser
ac_add_options --enable-release
ac_add_options --enable-official-branding
ac_add_options --enable-private-build

ac_add_options --disable-updater
ac_add_options --disable-maintenance-service
#ac_add_options --disable-stylo
#ac_add_options --disable-servo
#ac_add_options --disable-webextensions

ac_add_options --prefix=/usr
ac_add_options --enable-strip
ac_add_options --enable-install-strip
ac_add_options --enable-gold
ac_add_options --enable-pie
#ac_add_options --enable-jemalloc
#ac_add_options --enable-replace-malloc
ac_add_options --with-pthreads
ac_add_options --enable-optimize="-O2 -msse -msse2 -msse3 -mmmx -mfpmath=sse"

ac_add_options --enable-default-toolkit=cairo-gtk2

ac_add_options --enable-alsa
#ac_add_options --disable-pulseaudio
#ac_add_options --disable-jack

#ac_add_options --disable-dbus
#ac_add_options --disable-gconf
#ac_add_options --disable-gio
#ac_add_options --disable-necko-wifi
#ac_add_options --disable-startup-notification

ac_add_options --enable-devtools

ac_add_options --disable-debug
ac_add_options --disable-debug-symbols
ac_add_options --disable-tests

#ac_add_options --disable-eme
ac_add_options --disable-crashreporter
#ac_add_options --disable-parental-controls
#ac_add_options --disable-accessibility
#ac_add_options --disable-safe-browsing
#ac_add_options --disable-sync
#ac_add_options --disable-webspeech
#ac_add_options --disable-webspeechtestbackend
#ac_add_options --disable-synth-speechd
#ac_add_options --disable-synth-pico
#ac_add_options --disable-webrtc
#ac_add_options --disable-gamepad
#ac_add_options --disable-b2g-camera
#ac_add_options --disable-b2g-ril
#ac_add_options --disable-b2g-bt
#ac_add_options --disable-mozril-geoloc
#ac_add_options --disable-nfc
#ac_add_options --disable-url-classifier
#ac_add_options --disable-userinfo

mk_add_options MOZ_MAKE_FLAGS="-j4"
mk_add_options PYTHON=/usr/bin/python2

I think that a better approach to Arch philosofy is keep package as close as possible to upstream. You can let user decide to enable or disable features, but by default, basilisk should be very close to official binary. You can optimize and patch if something is broken for Arch, but IMHO feature list should be almost stock.

Maybe comment the options should be a good start, and let commented for the user, or you can add a custom flag that enables a group of privacy features for instance... I don't know...

neeshy commented on 2020-01-30 19:39 (UTC)


  1. Usually it's derivative packages (in this case basilisk-bin) which should define the conflicts and provides arrays.
  2. I was aware of this for a while but I had assumed that it was an upstream bug. The presence of this bug is probably due to my build time configuration. Unfortunately, it will take some time to track down which build flag in particular is causing the issue. In the mean time you can try removing some of the lines in the mozconfig.

figue commented on 2020-01-29 13:47 (UTC) (edited on 2020-01-29 14:14 (UTC) by figue)

@neeshy thanks for maintaining this package. Was trying to update myself yesterday but I think you did it much much better... I have several things at work that I want to keep in UXL platform, so I read about this project and would give it a try.

A couple of things:

  • perhaps you can add replaces/conflicts just in case somebody has basilisk-bin installed wants to replace the package.
conflicts=('basilisk-bin' 'basilisk-git')
replaces=('basilisk-bin' 'basilisk-git')
  • Advanced preferences doesn't work, but it does with basilisk-bin, same clean profile. Can you test in your system?


FredBezies commented on 2018-07-26 07:22 (UTC) (edited on 2018-07-26 07:22 (UTC) by FredBezies)

Here is a working - and dirty - PKGBUILD for Basilisk 2018.07.18

1) Modified commit reference to get Basilisk 2018.07.18 release

2) Removed useless and dead patches : fix-wifi-scanner, 0001-Bug-54395-remove-hardcoded-flag-lcrmf.patch, nss_mozbuild.patch, modified-install-dir.patch

3) Added a mozver value in order to fix packaging

4) Removed some part of copy icon line in order to keep existing icons

5) || return 1 are obsolete. If a build process is broken, makepkg will manage it flawlessly.

Yes I know, it is a little dirty, but you can use it to make an up-to-date PKGBUILD.

frankspace commented on 2018-06-04 13:19 (UTC)


Thank you so very much. Yes, that's great, and I'm glad we can come to a solution that satisfies everyone. My apologies also for the delay in responding -- like everyone else, I'm afraid I too have a day job (and not an especially fast computer), so I'd like to beg a crumb of further indulgence by giving me a few days to put this together. If you'd like me to specifically contact you to keep you in the loop, I'm sure I can find your contact details somewhere to do that, but otherwise I'll get on this as soon as the rest of my meatspace-world commitments permit. Again, thanks very much for your help.

KlipperKyle commented on 2018-06-03 02:01 (UTC)


a cross between Steve Jobs and Hans Reiser.

That's an interesting combination. It made me laugh!

The problem I have is, the build process is eventually going to generate various things with "basilisk" in the name somewhere. If all of that has to be somehow renamed without breaking anything, well, that's certainly beyond my capabilities, and I don't even know where to begin. I expect that would be "behind the scenes" to a user, but technically still present.

I just talked to @mattatobin. He says not to worry about it. The build will generate some files that have the Basilisk name. However what's important is the name of the package, the name on the desktop file, and the logo.

I'd also like to know if it's acceptable to note in the package description that it's "derived from Basilisk",

He says that's OK too.

I'm glad I can help.

frankspace commented on 2018-06-03 00:31 (UTC)

@KlipperKyle, thank you. It is helpful.

Given that I don't want to put up with bickering, interpreting or defending whatever anyone believes a "necessary" patch to be, or depending on the whims of someone whose identity is not actually clear to me and may be the person with exceedingly poor diplomacy and communication skills who below made reference to "completely insane" and "squatting", yes, I would definitely be pursuing the first option. Bluntly, I have no intention of tolerating that kind of aggressive attitude; it reminds me a little of a cross between Steve Jobs and Hans Reiser.

Anyway, yes, the icon is already something new, the browser itself already identifies itself as "serpent," and it should be easy enough to rename the bin file used to launch it, desktop file, and I think that's it. The problem I have is, the build process is eventually going to generate various things with "basilisk" in the name somewhere. If all of that has to be somehow renamed without breaking anything, well, that's certainly beyond my capabilities, and I don't even know where to begin. I expect that would be "behind the scenes" to a user, but technically still present.

So, I just want to clarify whether it's necessary to literally strip the word "basilisk" out of everything, because (a) I don't know how to do that without breaking things, and (b) I'm afraid the license looks like a wall of text to me and I don't trust my own judgment to interpret it correctly. I'd also like to know if it's acceptable to note in the package description that it's "derived from Basilisk", which I would like to think would be okay because it's not claiming to be Basilisk, and Basilisk itself appears to note that it's derived from Mozilla, but I'd prefer not to take that for granted, under the circumstances.

I appreciate that you are not strictly speaking the authority figure here, but it looks as if you are someone who can actually be talked to reasonably. So, again, thank you.

KlipperKyle commented on 2018-06-02 22:56 (UTC)

@frankspace, the problem is that the software calls itself Basilisk when it is not a condoned configuration of Basilisk. That includes the package name, the .desktop file, and the icons.

Someone mentioned the icons have been changed to the non-branded Serpent icons. If that is the case, then great. I do not have an Arch Linux box, so I can neither confirm or deny.

The long story: this build has been customized with patches beyond the amount of patching required to obtain a stable build. For background, see point 8b in the Pale Moon redistribution license:

But keep in mind that the above redistribution license only applies to Pale Moon, not Basilisk. Rights to the Basilisk trademark are all rights reserved, and the trademark is held by Moonchild.

So, there are two routes:

  1. Call the browser Serpent (or whatever other cool name you want), and call this package serpent. (Is this the route you are trying to pursue?)
  2. If you wish to use the Basilisk package, take out all patches except the minimum required to get a stable build. Then, ask Moonchild for permission to use the Basilisk trademark.

For an example of a condoned from-source build of branded Basilisk, take a look at . Notice that there are no patches or modifications beyond those required to obtain a stable build.

Also, khronosschoty, who maintains the SlackBuild, is a build engineer for the Pale Moon team, so this SlackBuild has the stamp of approval. (I myself am not a build engineer for the team, so my personal knowledge of mozconfig is limited at the moment.)

If there are questions, please feel free to reach out to Moonchild or khronosschoty on the forums or IRC. Moonchild is the authoritative source.

The short story: call it Basilisk only if you obtain Moonchild's permission. Otherwise, call it Serpent, or whatever other cool name you want.

I hope this helps.

frankspace commented on 2018-06-02 17:50 (UTC)

I don't claim to understand why calling this package "basilisk" is such an issue, but I'd like to ask for a point of clarification without wading through a whole bunch of nastiness. Is the problem literally just that the package is called "basilisk"? I am not an IP lawyer or a programmer, and I'd like to see the exact problem spelled out in plain English in a non-abusive manner. If it has been, then I apologize, and I'd ask someone to take pity on my stupidity and do so again.

That said, I had a go at tampering with the PKGBUILD to remove any and all references to that word and replace them with "serpent", in the hopes that that will solve everybody's problems. It's easy enough to do things like change the name of icons and the desktop file, but if one of the upstream devs would point out to me how to change things like the internal directory names and the like, that'd be great. Also, note that as it is, the application does identify itself as "Serpent" anyway. Could someone suggest what should be added to mozconfig or anywhere else in the build instructions to forcibly remove literally any and all instances of "basilisk" from anywhere in the entire process whatsoever? Or if that's not necessary, what exactly is?

I'd be happy to try to put together a revised PKGBUILD that would satisfy everyone, but I want to know precisely what that needs to entail, without either aggressive posturing or simply referring to some other document. As has been noted, observations like "completely insane" is the exact opposite of helpful, whereas concrete suggestions like "please add the following line to mozconfig" will almost certainly be accepted without question. Thank you.

frankyboy commented on 2018-06-02 14:32 (UTC)

modified-install-dir.patch and nss_mozbuild.patch not available

Morganamilo commented on 2018-05-24 11:37 (UTC)

The way to rename a package it to upload it under a different name and send a merge request to this package. While you would expect it to be the maintainer who does it, anyone could do it if they wished. There is no need to wait for @bm456.

KlipperKyle commented on 2018-05-24 07:01 (UTC)

@phw, no worries! Take your time. I'll wait for @bm456's call.

I'm glad we could clear things up.

@bm456, there is a lot of information here. Take your time to absorb it. However, please know that this is a trademark concern, and the MPL does not grant a license to trademarks.

phw commented on 2018-05-24 06:52 (UTC) (edited on 2018-05-24 06:52 (UTC) by phw)

@KlipperKyle While I am happy this is on the path of getting resolved, I am really astonished how you put the blame of escalation on the Arch side. Starting the discussion with "this is insane, I want you to remove it" without further explanation is just rude, aggressive and in no way productive. This set the tone for the entire discussion, the escalation is by no means a surprise. I suggest to send someone with more communication skills in the future for a first contact on trademark issues.

Also keep in mind that Arch is maintained by volunteers. And in the case of the AUR often volunteers with less ties to what can be considered the Arch core team. So you should be patient and respect that those volunteers also take some time to respond, as you for sure understand having a full-time job as well. So far @bm456 has not even commented on this, and currently @bm456 would be the one to do the change. If an AUR maintainer is completely unresponsive there are of course ways to disown the package and change the maintainer, but IMHO before taking action the current maintainership should be respected.

KlipperKyle commented on 2018-05-24 06:37 (UTC)

@Ashie_Princess, I wasn't aware @vonPalitroque was still involved with this PKGBUILD. Current maintainer says @bm456.

As for the 5 hours, I actually waited two days. My complaint is in how instead of listening to several explanations of our beef with this PKGBUILD, @eschwartz turned around, called us "gross", and then let another argument about "fair use" ensue here.

A few of us Pale Moon devs spent an hour on IRC trying to explain to @eschwartz what our concern was. It was a done deal, or so I thought. But based on what I have read in this thread apparently it was just the beginning.

I am really sorry this issue escalated the way it did. But right now, I and the rest of the Pale Moon team would like to see this resolved instead of petty accusations and name calling.

If @bm456 (or whoever the current maintainer is) agrees with @vonPalitroque and decides to rename everything, including the desktop entry, then great. @vonPalitroque is the first person I see in this thread that suggested doing as the Pale Moon devs asked, two days ago, when @eschwartz wandered into our IRC channel.

I expected @eshwartz, an authority figure responsible for Arch Linux, to make the call. I am disappointed that he did not.

And who says I "despise the idea of the open source community"? I love open source. It's the reason I am involved with Pale Moon in the first place, on top of a full-time software job.

Ashie_Princess commented on 2018-05-24 03:45 (UTC)

@KlipperKyle as vonPalitroque stated. the PKGBUILD will actually build a version of the software by the unofficial branding "serpent". the only reference to the name "basilisk" is in the binary name and the package name. the package name is just waiting for the maintainer to update it as such. sorry, the 5 hours you waited wasn't quick enough. but things do take time. Also, will you and all members of the development team please stop referring to the build config as "insane" the reasons that certain patches are used is mentioned in the build file itself, and only what is necessary for it to run under arch is used. Another note: flat out demanding that a package is removed by simply calling the package "insane" and complaining that the build config is non-standard (as developers, I'd hope you'd know that no build config will work on all machines, ever. If you wish the package to use a specific build config, then speak to the maintainer directly, I'm sure they'd be willing to accept input, believe it or not, most of us are highly reasonable people. however, as I've said, these build options are likely required to run on arch. Also @mattatobin purposefully putting in code to prevent it working on arch would be ineffective, as it being an open-source (if you can really consider that "open") project, it would be simple enough to patch out. if you make it closed source, nobody would bother making it work on arch, especially since you seem to despise the idea of the open source community, and of linux users in general.

KlipperKyle commented on 2018-05-24 01:58 (UTC)

Well, it seems I was quoted out of context on IRC too, and apparently whatever I said went in one ear and out the other. So, here I am, signed into AUR for the first time in more than a year.

I tried to be nice, but frankly my patience on this issue is starting to run thin.

@eschwartz, there were at least 3-4 people who attempted to explain the basics of trademark law and how you may not use Moonchild's brand unless you are explicitly given permission. It doesn't matter what Mozilla told Debian or what Spotify told (or may not have told) Arch Linux. We explicitly told you that calling this package Basilisk is not OK.

What these jokers don't seem to get is that there is NO packages involved here. There is nothing here that violates the license as there is no redistribution at all. Moot point, move on and whine somewhere else.

@scimmia, that's incorrect. AUR is redistributing the package via build script, and the default configuration is insane, as pointed out repeatedly. We have a problem with this non-condoned configuration being called Basilisk, and we asked (no told) the package maintainer to stop.

@eschwartz, we gave you an option for peaceful resolution: renaming the package. I even personally contributed a suggestion.

So, why hasn't the package been renamed yet?

vonPalitroque commented on 2018-05-23 19:24 (UTC) (edited on 2018-05-23 19:25 (UTC) by vonPalitroque)


So it looks like things have been rather festive since I last looked at this PKGBUILD. First and foremost, thanks to frankspace and bm456 for their work on the PKGBUILD. There are a few things I do not agree with, such as hardcoding potentially lethal CFLAGS in the PKGBUILD for optimizations that may not be available in a given architecture (though I am pretty sure that all CPUs officially supported by Arch Linux have these features, but I do not like the idea of my CFLAGS being willy nilly ignored). If anything, leave it as "-march=native -mtune=native" which generates code optimized for the CPU it is being built on (dangerous if using distcc), or pull from the defaults in makepkg.conf and modify from there as most other packages do. Same with the LDFLAGS behavior.

IANAL: Now, regarding the issue with MoonChild Productions and their team. As it is, this PKGBUILD generates a browser that identifies itself as "Serpent", not "Basilisk". A while back, there used to be a package called "swiftfox" in the repositories, which existed as an alternative to "firefox". Furthermore, at some point, Firefox itself identified as a different browser. Pointing to a different distribution, Debian started shipping Iceweasel as a rebranded Firefox in response to what they perceived as non-free trademarks from Mozilla.

Given that this PKGBUILD does not generate a browser called Basilisk, the only instance of the name that remains is in the package name [and resulting binary], I propose that we just provide our own branding and rename the PKGBUILD to something else. The default unbranded "serpent" could work I guess. We also specify in the package description that this is a "Web browser based on the Basilisk source code with some modifications and optimizations for Arch Linux". As such, those looking for "Basilisk" will be able to find an alternative that is built from source, or the binary package that is already being distributed in the AUR. At this point, we are no longer claiming to be Basilisk. We are explicitly stating that this would be a derived product that does not use their branding, which, as far as I am aware, is valid under the MPL. This is what in effect Debian did with Iceweasel (maybe rename the binary that is outputted just to be sure).

Although somewhat understandable since by providing a potentially unstable product under a brand can tarnish the brand itself, I strongly believe the way this was approached from MoonChild Productions and their team was improper. Instead of demanding a very vocal, very public takedown, they should have privately contacted the maintainer voicing their concerns and offering assistance on how to resolve the issue. Their attitude and community response has left a rather sour taste in my mouth.

Cheers, Orlando.

[edit] Formatting.

Ashie_Princess commented on 2018-05-22 11:38 (UTC)

@eschwartz I would argue that theoretically, the most effective solution would be to go the way of the OpenBSD people and just outright remove the software from the AUR, not in compliance with the request, but from the fact that Moon "Acts like a child" Productions clearly don't understand what the AUR, or a trademark are.

From the INTA ( Nominative fair use permits use of another’s trademark to refer to the trademark owner’s actual goods and services associated with the mark. Nominative fair use generally is permissible as long as (1) the product or service in question is not readily identifiable without use of the trademark, (2) only so much of the mark as is reasonably necessary to identify the product or service is used and (3) use of the mark does not suggest sponsorship or endorsement by the trademark owner

To demonstrate this: (1) By naming this something else, such as "webbrowser" or "internet-page-loader" while describing what this product does, does not accurately describe which web browser it is. clearly, if you want to get the basilisk browser, then you would not be able to identify it without the use of the Pale Moon trademarked name "Basilisk". (2) Literally, the only use of the name "Basilisk" is in the PKGBUILD where absolutely necessary, and only to identify it. (3) At no point does this suggest endorsement nor does it suggest that you're agreeing with this. however, as many AUR repos have done in the past, if you wish to help out, by all means, contact the maintainer and do so.

Nowhere does that violate your trademark

eschwartz commented on 2018-05-22 11:31 (UTC)

Fixed some markdown formatting, cf.

mattatobin commented on 2018-05-22 11:17 (UTC)

Since what Eschwartz pasted is completely unreadable here is the complete, readable, and unbiased log from the conversation taken by globbot.

Starts at 01:50 and ends 03:10 globbot time. Enjoy.

eschwartz commented on 2018-05-22 03:17 (UTC) (edited on 2018-05-22 11:28 (UTC) by eschwartz)

1) Pale Moon and everything that comes from there is gross.

2) There's no rule against gross things being in the AUR. If someone wants to maintain it, and users want to use it, that's their choice.

3) On the topic of license violations, I joined #palemoon on Freenode to try to clarify things... @mattatobin responded to me there.

[10:11:52 PM] <eschwartz> so if I understand correctly, it is utterly forbidden to use the basilisk name in any way, shape or form, without exception, under any circumstances whatsoever, bar none? Then what is the purpose of having a trademark...
[10:12:49 PM] <NewTobinParadigm> eschwartz: Your rights are clearly stated in the Mozilla Public License
[10:13:03 PM] <eschwartz> so just to be clear, this is your objection? ^^ you don't allow any sort of use whatsoever, ever, no matter what, ever?
[10:13:37 PM] <NewTobinParadigm> Not for Basilisk.. If you call it something else and don't use the word "Basilisk" but otherwise comply with the MPL.. well that is your business

I'm completely unsure what to do with this information.

I'm inclined to say that since we don't host source code, binaries, branding files, or indeed anything other than download URLs and compilation command lines, we're covered under the same rules that let us host PKGBUILDs for completely proprietary software, rather than basilisk where only the branding is proprietary. But it seems they disagree:

[10:08:23 PM] <eschwartz> But I still don't see what it is doing wrong
[10:08:29 PM] <NewTobinParadigm> because of the Pale Moon redist license
[10:08:34 PM] <NewTobinParadigm> eschwartz: You don't have to
[10:08:55 PM] <NewTobinParadigm> eschwartz: You merely have to comply with the Mozilla Public License
[10:09:12 PM] <NewTobinParadigm> which does not grant any rights to the name "Basilisk"
[10:09:27 PM] <NewTobinParadigm> You do NOT have the right to call it Basilisk in any form
[10:09:29 PM] <NewTobinParadigm> simple as that

[10:24:08 PM] <NewTobinParadigm> You are misrepresenting us is what you are doing..

[11:04:09 PM] <eschwartz> MoonchildPM|Away: I asked an hour ago, what is wrong with the build configuration and what you would prefer. I got flatly stonewalled, and told that NewTobinParadigm as a representative of the Pale Moon team was flatly asserting the trademark rights to unconditionally forbid its use, with the presumed logical conclusion that there is no build configuration other than -when-hell-freezes-over which would be acceptable.
[11:04:37 PM] <eschwartz> then I got the output of `yes MPL`
[11:04:56 PM] <NewTobinParadigm> Colorful
[11:05:32 PM] <NewTobinParadigm> essentually true but not so dramatic
[11:05:34 PM] <eschwartz> are you saying there is something this package could be doing, which would meet your approval? this is news to me

Despite my repeated requests to know what, exactly, we are misrepresenting via this build, no one was inclined to say anything other than "you're in violation of the license, please delete everything".

So as far as I can tell, this really and truly is entirely down to their complete unwillingness to see their name used at all, and not for any reason specific to this package.

In which case I'm unsure why this is worse than distributing Spotify via an AUR package too. We'd need to establish a rule that proprietary software is completely forbidden from the AUR.

... which I pointed out, and was then told:

[10:43:49 PM] <KlipKyle> eschwartz: you are distributing build scripts, like Gentoo ebuilds except less automation.  The same rules apply.

But Gentoo explicitly contains USE flags for proprietary-non-redistributable software, on the grounds that the user can choose whether they want to include non-redistributable code as a general thing on their built system (perhaps they want to redistribute the system as an ISO image or something).

And anyway, we've got no rule against this AFAICT.


All this being said:

[11:07:23 PM] <MoonchildPM|Away> eschwartz: if you plan to go that route, that's fine and someone can have a look over your build configuration (which I could do as well if it is was not 5 in the morning) and can tell you what's wrong with it. In the interim, until permission is granted, you are NOT allowed to keep these packages up since you're in violation. You ask permission first, get it granted first, THEN are allowed to use it if OK, not in any other order

So if @bm456 would like to work with the Pale Moon team to establish a mutually satisfactory outcome, that would certainly be the most... effective solution.

FredBezies commented on 2018-05-20 07:33 (UTC)

Reminds me something about the behaviour of Moonchild productions...

This commit sums it up:

"Remove. clearly, they don't want users, and we're not gonna give them…"

Well, what do you think now? Who needs this browser, after all? Just asking, of course !

jonathon commented on 2018-05-20 00:14 (UTC)

@mattatobin If you feel this package should be taken down file a deletion request with all the necessary details, e.g. where/how your license and trademarks have been infringed.

On the other hand, if you wanted to work with the community instead of alienating them, post a "compliant" example package file so the changes could be considered and adopted.

Ashie_Princess commented on 2018-05-19 18:05 (UTC)

@mattatobin could you also clarify what is meant by the term "squatting"?

phw commented on 2018-05-19 17:50 (UTC)

@mattatobin: You should clarify what parts of you claim violates any branding rules.

Morganamilo commented on 2018-05-19 17:40 (UTC) (edited on 2018-05-19 17:41 (UTC) by Morganamilo)

@mattatobin This is a pkgbuild not a package, which means it is not redistributing the source or binary in any way.

The only thing located here is the name 'basilisk' and some urls. Is the package not allowed to use the name. I'm not familiar with trademark law and all that to I'm not sure on the legality of things.

The desktop file which you specifically mention is hosted here I would recommend opening an issue there instead.

mattatobin commented on 2018-05-16 07:40 (UTC) (edited on 2018-05-16 07:41 (UTC) by mattatobin)

You do realize this package is completely insane. I want you to remove any remaining Basilisk branding and use of the name including in the desktop file and this very package from AUR that you are obviously squatting on.

FabioLolix commented on 2018-04-23 18:04 (UTC)

Hello, there is a 404 for modified-install-dir.patch.

modified-install-dir.patch and nss_mozbuild.patch are now located in basilisk-arch github repo

bm456 commented on 2018-04-17 00:18 (UTC)

testing your changes

frankspace commented on 2018-04-15 02:54 (UTC) (edited on 2018-04-15 02:54 (UTC) by frankspace)

So after a considerable amount of trial and error, I have made a PKGBUILD for the UXP repository noted by @vonPalitroque that I hope works for more than just me. As you can see by the comments I've left, I'm not totally sure what I'm doing. I pulled a few bits and pieces from old PKGBUILDs for Firefox, and cleaned it up quite a bit otherwise. Note that this requires two new patches. Also as noted in this, there is nothing magical about the commit chosen, it's just the most recent one at this time.




I've tried to document everything I did as well as possible, my apologies if I did anything dumb.

vonPalitroque commented on 2018-04-02 23:08 (UTC) (edited on 2018-04-02 23:09 (UTC) by vonPalitroque)


There's actually a bigger issue with this particular PKGBUILD. The repository it pulls from [1] has been deprecated in favor of [2]. Given that [1] was deprecated in commit 868d263f228a98581c35e8b1b29f0e0f2d9d4b07, I suggest we move this PKGBUILD to use [2] at some stable commit. I can try helping port the PKGBUILD, but I am somewhat short in time now.





Slobodan commented on 2018-03-27 21:45 (UTC)

firefox-52-disable-data-sharing-infobar.patch ... FAILED ... FAILED firefox-52-disable-telemetry.patch ... FAILED