OpenBSD & Pale Moon: coordinating patches and officially branded package?

Talk about code development, features, specific bugs, enhancements, patches, and similar things.
Forum rules
Please keep everything here strictly on-topic.
This board is meant for Pale Moon source code development related subjects only like code snippets, patches, specific bugs, git, the repositories, etc.

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. Please post issues with specific websites, extensions, etc. in the relevant boards for those topics.

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.
User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35477
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: OpenBSD & Pale Moon: coordinating patches and officially branded package?

Unread post by Moonchild » 2018-10-14, 05:46

The system library issue is not just about performance. I've explained this before already. Building against unknown types and versions of sytem libraries is almost guaranteed to cause stability issues, and for a complex piece of software there are too many snags and hooks with the interop of dozens of libraries to reasonably cater to all of them. It's not possible to test every version of every library possible. If we can't guarantee reasonable stability, we don't want it to be carrying the Pale Moon label. The same goes for security of libraries contrary to what you posted: it is not unidirectional that a later version of a library will always be "more secure", or that any later version of a lib is actually addressing a problem in the browser (or instead might be causing problems). Any sec updates to libs that are prudent are always addressed by either porting patches or by upgrading the in-tree lib...

So, in short, the system lib setup can neither guarantee a reasonable level of stability nor security of the final product and it's our simple right to say we don't want our label on it.

Aside from that, the way the whole dialogue went has closed that particular door. Not because of technical contention but rather because it was approached as if we had to relinquish our branding rights which I will not do. The wording could have been better on both sides but it remains a fact that we are already being more lenient here than we have to be under open source development practices, including the GNU philosophy. We are not going to treat this as public domain, ever, because it simply isn't!
Last edited by Moonchild on 2018-10-14, 06:08, edited 2 times in total.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

Locked