This is not for tech support! Please do not post tech support questions in the "Development" board!Please make sure not to use this board for support questions. Most "bug reports" do not belong in this board and should initially be posted in Community Support or other relevant support boards.

Please keep things on-topic as this forum will be used for reference for Pale Moon development. Expect topics that aren't relevant as such to be moved or deleted.

There are a couple of patches I had to make to get it working. Mostly related to building with clang-5.0.1 (the default compiler on OpenBSD)--but I will say that I've been using Pale Moon as my only browser for a few days now for everything from webmail to YouTube and Twitch.tv, and haven't experienced any issues or problems. So my first question is what is the easiest way to coordinate patches? Is it the GitHub? Or is there another way?

Browsing the website, I noticed that in order to distribute officially branded binaries requires approval. Which is perfectly fine and I understand why. I think it would be mutually beneficial to offer an officially branded Pale Moon browser through the OpenBSD package system. How would we go about making sure I can do that? I'm also an OpenBSD developer, so I would be the one maintaining any such package. I've already had a number of OpenBSD users express interest in using Pale Moon and are eagerly anticipating an official package.

Yeah, you should probably open an issue or issues on GitHub (https://github.com/MoonchildProductions/Pale-Moon) and tag the relevant issue in any pull requests you make. If you're fixing problems caused by building with Clang, I'm excited, because it's also the default compiler on current versions of macOS.

Well done, you have completely not understood what happened or who "killed" it.

"Our way or the highway" doesn't fly when you're enabling official branding (including trademarks and branding you don't have rights to) as if it was public domain. And then demanding the IP rights holder to come in as the only accepted valid voice in the matter while things are clearly stated in the source AND redist license is exactly what makes such a thing escalate.Then they still had the option to either make the changes to adhere to the license OR not use official branding but New Moon instead, and instead chose to just remove it from the portage tree.

So who "killed" it? Not us.

If anyone wants officially branded Pale Moon on *BSD, I suggest you submit a proper portage addition that adheres to the license for official branding exceptions OR work with me to get an agreement on different build configuration if deviant build rules are desired that make it not comply with normally-accepted porting practices for packages.Alternatively, add it with unofficial branding or fork it with different branding altogether for BSD and apply whatever patches are needed and whatever unwise build configuration you think works "best" for "your" OS.

Last edited by Moonchild on Mon, 05 Feb 2018, 21:04, edited 3 times in total.

Improving Mozilla code: You know you're on the right track with code changes when you spend the majority of your time deleting code.

"If you want to build a better world for yourself, you have to be willing to build one for everybody." -- Coyote Osborne

That was not meant to be an attack, Moonchild. I understand the contradiction between OpenBSD's "no non-free software" and Pale Moon's "no modifications" approaches. It will be ... interesting to see what happens now.

I, for one, don't care about the branding, I could live with a New Moon or QuuxBrowser or whatever.

Moonchild wrote:...OR work with me to get an agreement on different build configuration if deviant build rules are desired that make it not comply with normally-accepted porting practices for packages.Alternatively, add it with unofficial branding or fork it with different branding altogether for BSD and apply whatever patches are needed and whatever unwise build configuration you think works "best" for "your" OS.

Do you think they would have been more willing to cooperate had these options had been presented earlier in the discussion?

Sadly, after reading that whole debacle I find more than ever some folk who cannot handle any sort of "Do it right" response even when it's clearly explained why. Could it have been handled better? Perhaps.

But the fact is, it's not their creation and they don't have any right to abuse or change anything that could and would have come back to bite not only them but Moonchild and the team themselves.

The reaction of the ibara was at the least, snobish and childish and thus continued the hard edged attitude that continued throughout.

What I find most amazing is that not one of the people that commented and decided that they would never ever use PM again, stopped to even think about how ridiculous their reaction even was. They were in the wrong, They were told to correct the problem or stop. Instead of seeing their error and correcting the issue they decided it was better to crucify the messenger and the project and rant against the idea of rules to the point of daring the use of force.

This "free at any cost, I will do what I want with your software" is a cancer in the minds of a lot of people these days.And sadly, it goes way beyond software. This, rules be dammed entitlement mind set is a rot to society.

The fact is, if this was their reaction to something as simple as this, how much different would it have been down the road?

Good afternoon. This section is about OpenBSD but I came from another resource: https://forums.freebsd.org/threads/59110/page-4After reading https://lists.freebsd.org/pipermail/fre ... 12455.html and OpenBSD issue I was very disappointed by this attitude to your clients (I'm one of Pale Moon users on TrueOS/FreeBSD workstation) and especially to those who are involved in the Pale Moon development (yes, peoples who spends hours of their lives and portes your browser to additional platforms, making the lives of other users more happy - participating in the development of your product).I am shocked by your unwillingness to make official support for the Pale Moon for xBSD platform (a small user base, I agree). You could at least just help make the port better. Instead, you kill this endeavor. Except for the use of BSD, I widely use Linux and Windows in my work. However, I decided not to use Pale Moon on any OSes. I hope that someday I'll see official support on the BSD and the desire to make your project more accessible. Good luck!

Would you like us to delete our port of it now? I can arrange for that if you insist on not having proper ports of your software. At this point it might be easier to just add a clause to your license that prohibits non-Linux platforms.

Patches to anywhere in the codebase to accommodate our in-tree code for BSD systems to get a positive build is totally permitted. If that means libvpx or nss needs an in-tree patch then that is totally fine.

In fact, if you do the patches in such a way as it won't interfere with other platforms via proper ifdef we would gladly accept them up the line. We were close to having this in the past but the contributor would not make clean patches that didn't fundamentally bust other platforms and we had to back it all out.

We do want to work with platforms and projects but we also don't want our rights to be trampled on any more than you would want yours to be. Frankly, we didn't want the OpenBSD people to remove the port either but that was their decision to escalate a situation beyond reason over a couple of perhaps poor phrasing choices.

The Mozilla Public License is clear in its provisions and grants and protections for covered code. The Pale Moon Redistribution License actually extends rights and permissions beyond what the MPL allows but has its own conditions that need to be met. None of these are insane or out of line and are there so that users of the software know they are getting what the name and logo claim it to be.

However, given all that if you guys are going to follow suit and not going to follow point 8 of the Redist License you ask under point 10 for special permission to use trademarked branding and perhaps find a happy medium between which libs are absolutely required to satisfy the Pale Moon feature set and what ones can get by with using system libs.

The decision is yours. Please make it a good one.

Mark Felder wrote:[ I do not speak on behalf of the project ]

Two problems:

1) You're not the upstream for any of these codebases: sqlite, nspr, nss, png, icu... As such there will be no effort made to submit you patches. You are welcome to retrieve our patches from the FreeBSD ports tree and apply them to your codebase if you so choose. Many man hours were spent adjusting these projects to work with FreeBSD's expectations; spending more to appease your private forks of these projects is unconscionable.

2) Shared system libraries exist for a reason and we intend to use them.

3) It will be beyond tedious to track down which vulnerabilities your browser is shipping. A CVE in nss or sqlite3 will not show up automatically for Palemoon in the results of our "pkg audit" tool unless someone has the ambition to peek into your codebase and see which extra copy of those libraries are being used.

Building with your libraries is the wrong way to ship this software for our users.

Do we need to disable your branding only or also stop using the name? If both, we will likely remove the port and suggest users upgrade to www/waterfox if they want an alternative to Firefox.

Matt A. Tobin wrote:Alright, if that is the case, then yeah you can just disable branding. If you run into troubles, i can help on this.. Or if you wanna come up with new branding I can also help with this.

And that is ALL that happened with FreeBSD and me us all of us.. Anything else is just them.. Same goes with OpenBSD everything me us everyone happened in the GitHub issue on the ports-dev repo..

Judge for your self but despite the FreeBSD person being obviously initially defensive and a little passive aggressive and slightly under false impressions.. It was handled at LEAST best it could be and know what? FreeBSD followed licenses even if it ended up with switching officially trademarked branding off.. OpenBSD threw a babybitch fit from the START and have basically spurred a war of disinformation in their little community and a couple of spammers to come and harass us.

Now everyone who knows me knows sometimes I don't always pick the best phrasing but with rare exception I don't try and intentionally to piss people off. There is no denying now that I could have switched a few words around added a few more "pleases" to my opening post over on GitHub.. But I didn't, however, I still don't think the response I got from OpenBSD was anywhere near on the same level as what I initially directed them to do to comply with the Pale Moon Redistribution License and YEAH it was a very fact over form opening post.. But was it the end of the world situation it evolved into? I don't think so..

In any case, I'd rather work and cooperate with FreeBSD than OpenBSD at this point.

New Tobin Paradigm wrote:Here is the full story with FreeBSD as far as my interactions are concerned because mailing lists can be hard to follow.

I read this story, and it made me come here. I would like to be more clear. Since I'm also a developer, I understand your motivation - you do not want to be responsible for the code that you did not produce. A huge number of large projects, such as LibreOffice, Gnome3, KDE, firefox, chromium, VBOX, virt-manager, mythtv etc., has the "#ifdef FreeBSD ..." block in its code, and these corrections are sent by volunteers. And these projects are still called by their name. It's quite obvious that BSD (Mac OS X, Windows, etc.) are not the same systems, otherwise they will be called Linux. Somewhere there is no udev, here and there the epoll does not work, where LibreSSL is used instead of OpenSSL. I understand very well that you do not have the opportunity (resources and time) to check and write code for all platforms. And you are offered help. You want new users, but you are not ready to help yourself when you say: "If you made changes, you must rename the project."You want to completely disengage from it. I would advise you to go to Vagrant-distribution, where you can build Pale Moon with specific compilers with certain optimization flags and, of course, with the libraries you have checked. I will not use "New Moon" in FreeBSD ports, since I can not cope with any problem on this forum. I can not write to the author of any plugin that his plugin does not work: "New Moon?" what kind of shit are you using ?! " So I think that the developers of OpenBSD in this regard did the right thing. For any problem with the "New Moon" you will send to the port manager, who will have to check this problem on the source code and act mediately, even if the problem is in the pale moon.

Also, this is a good comment:

Peter Jeremy peter at rulingia.com wrote:Most definitely. I notice that Palemoon claims to be "free software" andlinks to https://www.gnu.org/philosophy/free-sw.html as a definition of "freesoftware". One of the "four essential freedoms" listed on that page is "Thefreedom to distribute copies of your modified versions to others (freedom 3)"- and it is precisely the exercise of that "freedom" that Matt A. Tobin isobjecting to.

As I said before, If someone wants to apply the required fixes needed for the in-tree code for BSD it would be gladly accepted provided it is done in a cross-platform way.. Meaning the ifdefs so it doesn't bust other platforms. That way it can be compiled as intended for the target operating system.. That is what point 8 in the Redistribution License is ALL about..

But the FreeBSD/OpenBSD situation isn't about doing that.. it is about using system libs verses the libs we have in tree.. As mentioned, many of these libs must be at specific versions with specific capabilities including changed or added capabilities to our in-tree libs that are as much apart of the whole that makes up the final product as the javascript or layout engines.

Pale Moon as a product IS the Codebase.. the entire codebase and the branding as determined by the creators of the product. Point 8 allows for code changes that allow a positive build but do not result in a materially different product. Substituting in-tree libs for system libs, beyond the potential mismatch and subtle and hard to reconcile conflicts with the glue code, materially changes the nature of the end result. It's like baking a cake and using margarine, powdered eggs, and powdered milk instead of real butter, real eggs, and real milk.

You get something kinda close but it isn't the same thing.. It is something.. OTHER.. Then slapping the Pale Moon sticker on it and passing it off as something it kinda isn't is what the issue is. People are gonna consume that modified cake and it JUST isn't gonna be what they were expecting and then they will come to us about it. It may even taste HORRIBLE instead of off and guess who is blamed for that.. "This cake tastes horrible! Don't eat any of it".

That is what it boils down to. They want to distribute our cake but then want the ability to change that cake how they see fit but still use our sticker.

https://www.gnu.org/philosophy/free-sw.html wrote:Rules about how to package a modified version are acceptable, if they don't substantively limit your freedom to release modified versions, or your freedom to make and use modified versions privately. Thus, it is acceptable for the license to require that you change the name of the modified version, remove a logo, or identify your modifications as yours. As long as these requirements are not so burdensome that they effectively hamper you from releasing your changes, they are acceptable; you're already making other changes to the program, so you won't have trouble making a few more.

New Tobin Paradigm wrote:... People are gonna consume that modified cake and it JUST isn't gonna be what they were expecting and then they will come to us about it. It may even taste HORRIBLE instead of off and guess who is blamed for that.. "This cake tastes horrible! Don't eat any of it".

...

Cave Johnson wrote:We're done here.

Living on TrueOS (based on FreeBSD 12 CURRENT) for some time now I was very glad finding today a package of Pale Moon within the official package manager, installed it and I'm using it at this very moment. It is not the newest version but 27.6.2 64bit.For me this cake tastes very yummy!

Is this discussion related to the package I am using now? Does this discussion mean, I will lose the just found package again soon?

FreeBSD has temporarily stopped distribution of their Ports package until they get it reconfigured then it will continue under unofficial or whatever other branding they decide on. However, we are not going to force them to rename an already established package name (The package not the application) since that would be very disruptive to users. In any case I wish them well.

https://github.com/ibaraYou know ibara is a computer student at a university in NY?I just randomly checked that. Perhaps when you shout at some young guy you might expect an unexpected response. Probably it was just some private project of his to package Pale Moon for BSD.Mind you, I figured a long while ago that the best way to get a virtually bulletproof browser was to use the precompiled static linked genuine one, so I see the point about libs. I suppose that's not an option for the BSD world here though. And license terms are what they are.I'm not using any BSD but thought that fact may have been overlooked. (As a Pale Moon user I shall boycott BSD by not using it for at least the rest of this week, probably longer )

There are a handful of packagers who do a great job working with us on building Pale Moon correctly for their target distros and users. Such as deu and his gentoo overlay, or Steve and his packages for all things remotely debian, and of course khronosschoty who creates a perfect slackbuild. They all work very hard to make sure that when you see the name Pale Moon you are getting the very best Pale Moon has to offer and those packages mentioned here and a couple others are every bit as legit as the generic binary Travis works so very hard to put out.

New to packaging. I'm trying to comply to be able to offer Pale Moon package for Devuan (and maybe some Debian folks might find interest to try it).

Moonchild wrote:[...]Then they still had the option to either make the changes to adhere to the license OR not use official branding but New Moon instead, and instead chose to just remove it from the portage tree.

I don't want to lose support, New Moon does not apeal to me. I want to comply.

And I'm using this topic to try and:

If anyone wants officially branded Pale Moon on...

[in my case Devuan, not on BSD]

I suggest you submit a proper portage addition that adheres to the license for official branding exceptions OR work with me to get an agreement on different build configuration if deviant build rules are desired that make it not comply with normally-accepted porting practices for packages.

I don't have any --with-system-<this-or-that> which was the case in this BSD case, but my current mozconfig does depart a lot from the default.I'm not an expert at all, but I did some packaging occasionally and with some reliability. Serving a real repo by Debian/Devuan policy is a first in my lifetime.

I have pretty clear concepts of possible deviations from the default in my mozconfig that I would like to do next, and my question is about those.

It's in that link, and it boils down, essentially, whether it is acceptable for Moonchild Productions to allow publishing Pale Moon package, and sources, with official branding, that would have all or most of the basic default options, but also these, I believe non-default options:

There are a handful of packagers who do a great job working with us on building Pale Moon correctly for their target distros and users. Such as deu and his gentoo overlay,

I did use his overlay and his ebuilds a few times back some one and a half years ago... but I'm not on Gentoo since one year ago. Devuan I use now.

or Steve and his packages for all things remotely debian,

The thing here is the departure from systemd in Devuan, which is still remotely a debian Devuan distro, that's true of course.

And because of that departure (and SSL-key logging support in the browser) I have, for months now (see: Building Pale Moon on Devuan failsviewtopic.php?f=57&t=15751) been building my own Pale Moon, and since yesterday started offering it to public.

IOW, while my builds are all based on Steve Pusser's work, I need those modifications, because his packages do not provide them... And not just me, but I'd believe most other Devuan users will like it better without pulseaudio and without dbus dependencies.

Yes there is great enthusiasm in Devuan for pure alsa, so no pulseaudio, as well as freedom from dbus.

Gentoo (and likely his, essentially, derivative Funtoo, and other derivatives) are currently I believe only distros that make it possible to run machines dbus free, e.g. without any of dbus programs, including libdbus and libgdbus libraries. I'd need to check, but I think it is close to complete purge of those...

Devuan is not completely dbus free (the libraries and not easily made redundant as in Gentoo), but is aspiring to become such...

So, would those --disable-dbus and --disable-pulseaudio in my next compilation for publishing in my repo void my permission to use:

These I would like to include too (however, I could go without them, but may not have enough knowledge at this time about them and the alternatives, nor what the defaults would be if these are not included ... ):

I am a fairly recent convert to PaleMoon since I could see the writing on the wall with FF switching off the old add-on XUL(?) system and driving itself towards being more Chromelike - except, if I wanted a webkit based Chrome-like browser I'd probably use, um, Chrome...

Anyhow my Windows and GNU/Linux systems are gradually being changed over to PM, and now I've also moving my FreeBSD Desktop/Development machine over to it (or rather the New Moon version). I came across this spat between PM and OpenBSD and as I see it this seems to be a case of the immovable object meeting the irresistible force!

Looking at https://en.wikipedia.org/wiki/Compariso ... ilosophies one can see that OpenBSD really emphasises security and auditing of its code-base and libraries - so PaleMoon's need to have it's own in-source possibly customised copies of what would be considered system libraries to meet its specific needs/functionality is going to be a point of strong contention; OpenBSD is going to want to build against the versions of the libraries that it has audited and know to be secure but those are not always going to be what PaleMoon wants to have available across the range of OSes that it is ported to. Conversely it may be that for performance reasons PM would like to compile with optimisations or options that are enough for it to work reasonably fast or efficiently but which have corner cases or minor vulnerabilities that are not likely to be encountered in reasonably normal situations but which OpenBSD holds to not be robust in every conceivable situation and which would impose a responsiveness hit were PaleMoon to work to accommodate them.

It is sad that this does seem to have led to the use of language that I would not personally call assertive between the two sides, the making of a demand rather than a firm request as the opening approach seems way too aggressive to me - I can see now that there are explicit terms and conditions related to branding the application as "The PaleMoon Browser" so you could be said to have the moral high ground but this could have been handled better - after all, who benefits from the current situation? OpenBSD doesn't and although PaleMoon has protected it's brand-integrity I guess it has missed out on linking up with a small number of user that include some people who are all-over making applications more secure and robust against malicious third-parties. As a user I can only see other browsers, {probably with non-Mozilla origins }, standing to gain from this - oh and it is really un-great publicity for both OpenBSD and PaleMoon.

Just the 2 pence of a slightly (after all I am on FreeBSD not OpenBSD ) disappointed user...

Also - to the previous poster - I am also moving away from a (Sys V init) Debian to Devuan on some of my Linux boxes - so I look forward to seeing your work come to fruition!

Last edited by SlySven on Sun, 14 Oct 2018, 02:42, edited 1 time in total.