Pale Moon Official Branding Violation

[mattatobin]

You will revise your mozconfig located at www/palemoon/files/mozconfig to remove the following:

ac_add_options --with-system-jpeg="${LOCALBASE}"
ac_add_options --with-system-zlib
ac_add_options --with-system-bz2="${LOCALBASE}"
ac_add_options --with-system-libevent
ac_add_options --with-system-icu
ac_add_options --with-system-webp="${LOCALBASE}"
ac_add_options --with-system-sqlite="${LOCALBASE}"
ac_add_options --with-system-ffi="${LOCALBASE}"
ac_add_options --with-system-pixman
ac_add_options --with-system-libvpx
ac_add_options --with-system-nss
ac_add_options --with-system-nspr

We do not allow system libs to be used with official branding because it deviates from official configuration. You must comply with the directive or you must disable official branding for your builds.

---

http://www.palemoon.org/redist.shtml

8) An exception applies to point 5 of this license for inclusion of the officially branded binaries in freely available and fully Open Source operating systems, including but not limited to non-commercial variants of Linux, variants of BSD and ReactOS. This exception only applies to unaltered versions of the Pale Moon binaries or officially branded variants specifically built for the target operating system from source that have not been materially changed (including build configuration not necessary for the resulting binary's proper operation and brand-specific configurations like e.g. home page, default search engine). If any of the essential settings of the browser are altered beyond what is strictly needed for providing a working and stable build on the target operating system, the exception in this point does not apply and the license defaults to point 10, instead.

8a) Clarification of "officially branded variants specifically built for the target operating system": If an officially-built binary (i.e. built by our team) is available for the target operating system (e.g. existing Linux binaries), then those binaries will always, in principle, take precedence over a third-party build to ensure necessary QA and compatibility. Building and distributing a binary with official branding is in that situation only in principle allowed if an actual variant build is required for the target distribution's compatibility (e.g. kernel or library requirements) or operation, and otherwise not impacting the material content of the browser package as a whole. QA of and support for the resulting variant binaries will in that case fall on the maintainer who will have to take full responsibility for the variant binary.

8b) When redistributing the browser in source form through a distribution system that imposes or can impose a specific configuration for building and run-time operation (e.g. portage trees, overlays, ebuilds) that configures the build system to use official branding in the resulting binary, you (as a package maintainer/distributor) must adhere as closely as possible to the build configuration used in official generic binaries. You must not reconfigure the build system or browser preferences beyond what is necessary to produce the browser on the target operating system. Any individual additional configurations done on the browser (either build- or run-time) must be done by the end user, not imposed by package maintainers/distributors. In principle, browser preferences and the supplied profile defaults must not be changed for the exception outlined in this point.

---

Additionally, you will please explain and justify the patches you are applying in www/palemoon/patches.

[mattatobin]

@ibara

[ibara]

I will do no such thing until I speak with the person who owns the rights to the intellectual property, which appears to be not you.

Additionally, your confrontational attitude dismisses you from any and all future discussions on the matter. I will only speak to M.C. Straver about this issue, and I wish to do so amicably. Your attitude demonstrates that you are unfit to be an intermediary of any sort.

[mattatobin]

Alright.

@wolfbeast Tag, you're it!

[ibara]

I have sent him an email.

[mattatobin]

@ibara You could have just complied. I don't see the problem. You know, except for this being a direct violation of the terms for redistribution with official branding as you are materially changing the end result of the intended software beyond what is absolutely necessary for the application's operation on BSD.

I became aware of this because a user pointed out they were using Pale Moon on BSD. A Build I was unaware of so I came to check out what exactly was going on with it since you had used Official Branding.

[ibara]

This repository does not create nor distribute binaries. This repository is not official in any way.
Again, you are dismissed from this conversation since you have no legal authority over the matter.

[mattatobin]

This repository does not create nor distribute binaries.

Point 8b, my friend. Also, Moonchild will respond in his own time but I suggest you stop being rude to me.. All I did was point out issues with your imposed build configuration and gave you options under the Redistribution License for which I know very well and have had to obey for my own build once upon a time.

[ibara]

I suggest you leave then.

[wolfbeast]

@ibara Please comply with the requests made in this issue, or re-brand the browser.

1. You are redistributing the browser to others
2. You are using Official Branding
3. You are not following the requirements set out to use official branding

If your repository is in any way redistributing the browser in source or binary form with official branding, you must understand the fact you have no rights to such branding unless specifically given (see also the statements to that effect everywhere in the source).
The redist license's stipulations apply in that it provides an exception to the need for permission in specific situations (see point 8, specifically).
You have not been given special permission to deviate from 8b; as such you must stick to normal practices for GNU porting of software and not reconfigure the build- or run-time of the application beyond what is required "to make it run" (and that does not include externalizing libs because such has a direct and severe impact on the resulting application's operation). As an author of a ports system you should be familiar with this general rule, explicitly stated once again in our redist license.

Your insistence to only speak to me in person about such matters is ridiculous, considering the license is up on the website, worded clearly for everyone to see, and you're clearly not adhering to it. But, here I am, as requested.

Now, follow the license terms, please.

I will not be as educational next time.

[landryb]

I will not be as educational next time.

What next, lawyers ? mafia ? Wow, that escalated quickly. Cool down please..

@mattatobin : starting your issue by you will was clearly not the nicest way to put things. Maybe Please would have helped...

Anyway, i'd suggest removing the port. We already have enough mozillas in the portstree, and given how this started, i doubt it'd end up being imported in the official portstree.

[wolfbeast]

What next, lawyers ?

You think trademark law is a joke?

[landryb]

Absolutely not. I'm just saying escalating to "i'm going to send you my lawyers" over an issue which was opened 3 hours ago is completely out of proportion.

[wolfbeast]

I said no such thing. You implied it.
I stated I'm not going to explain this any further. You should know these things if you write a ports system. I should not have to re-iterate it.

[landryb]

I said no such thing. You implied it

Oh, sorry then.

I will not be as educational next time.

Then enlighten me, what was this implying ? :)

Anyway, i'll let @ibara do what he thinks is the best way to solve this issue. My position would be to remove the port to avoid any kind of issue, but if he prefers disabling the branding (and i don't know if a non-official default branding is shipped in the source as mozilla does, because otherwise that means creating your own branding which is much more work) that's his call.

[wolfbeast]

Then enlighten me, what was this implying ? :)

It was implying that you can expect me to be as demanding as @mattatobin and expect at the very least an official cease&desist if persisted.
By the way, the escalation was fast because of what @ibara did, in refusing to talk to anyone but the IP owner. You're playing it high if you do that, expect responses in kind. I do not take very kindly to be dragged into this kind of thing first thing on a Monday morning, either. ☕

As for branding, the default branding (when not using --enable-official-branding) is the New Moon branding included in the tree which has no limitations (see redist point 13 in the current version).

[mattatobin]

Of course, they could just stop using system libs.. And upon inspection of the patches I find them to be necessary for proper operation on BSD.. My only remaining concern is the CFLAGS being used in --enable-optimise.

Then it wouldn't be a problem to use official branding.

[ibara]

This issue is now officially resolved. There will be no Pale Moon browser, official or not. The port has been removed. Farewell, petulant children.

[mattatobin]

Sigh.

[wolfbeast]

For the record, apparently the e-mail reply I sent was never delivered, because the devio.us mail server choked on having a TLS encrypted connection established with it. (fix it?)

For completeness, here's the important bit of that e-mail response that apparently never got across:

The issue you don't seem to understand here is that our in-tree
libraries are often patched specifically for the quirks of our code, and
of very specific versions (system-installed versions may or may not
work, since APIs and behavior changes). Also, due to the sheer size of
our code, number of components involved and interconnectivity between
such components, any component that does not play well due to a version
difference or missing a patch will have immediate and far-reaching
impact on the rest of the resulting application.

..., there are too many unknown factors in the resulting binaries on
user's systems. What you are asking is exchanging known-good
combinations of libraries with unknown and potentially disastrous
combinations as-present on end-user's systems.

[Sa-Ja-Di]

Too bad that that that had to end like that. That outcome was less than productive, as escalation leads always to a non-success.... Something everyone of us should keep in mind more clearly.

[ShalokShalom]

The issue you don't seem to understand here is that our in-tree
libraries are often patched specifically for the quirks of our code, and
of very specific versions (system-installed versions may or may not
work, since APIs and behavior changes). Also, due to the sheer size of
our code, number of components involved and interconnectivity between
such components, any component that does not play well due to a version
difference or missing a patch will have immediate and far-reaching
impact on the rest of the resulting application.

It makes sense to mention this somewhere obvious for the packagers?
So you can avoid to piss of projects.
My 2 cents

[mattatobin]

The why isn't the issue here only the what and the what is the redistribution license to use official trademarked branding.

If people actually read the licenses, obeyed them, and not escalated the issue beyond all reason because of a couple of phrasing choices. Then perhaps this could have been resolved to everyone's satisfaction.

However, this didn't work out. Hopefully, in the future everyone can learn from this incident. I am sure there are BSD users who would like to have their choice in web browsers and if that choice were to be Pale Moon.. Then we should make sure they get Pale Moon and not something.. other.

Though a maintainer who can keep their composer and not fly off the handle at the slightest perceived provocation would be nice too.

Stable build, stable maintainer.. A winning combination! Maybe next time.

[IanDarwin]

On 2018-02-06 8:35 AM, New Tobin Paradigm wrote: The why isn't the issue here only the what and the what is the redistribution license to use official trademarked branding. If people actually read the licenses, obeyed them, and not escalated the issue beyond all beyond all reason because of a couple of phrasing choices. Then perhaps this could have been resolved to everyone's satisfaction.

The phrasing choices really set people off. So maybe you could consider rewording your template. How about: We notice that your port of %s at %s doesn't conform to the licensing policy for our software. We hereby request that you bleah bleah bleah Your opening volley would then sound a lot more like a normal license conformance request and a lot less like something from You Know Who.

[sthen]

This is all totally ridiculous because the basic premise "You are redistributing the browser to others" is incorrect.

[ShalokShalom]

"The why isn't the issue here only the what"

This why is the cause for this what.

If you go this superexotic way of brandings in the open source community, you might be so kind to actually tell that. Packagers have much to do, to make their life even harder by stating "read all licences from top to the ground and consult some lawyers to be sure" is unpractical.

[amitkulz]

Actually, reading the first email carefully says that: you should use the bundled projects, not reuse the system installed projects. I don't understand what branding would be affected by using internal libraries. If you carefully explain this point, and do this politely, maybe people would listen. ac_add_options --with-system-jpeg="${LOCALBASE}" ac_add_options --with-system-zlib ac_add_options --with-system-bz2="${LOCALBASE}" ac_add_options --with-system-libevent ac_add_options --with-system-icu ac_add_options --with-system-webp="${LOCALBASE}" ac_add_options --with-system-sqlite="${LOCALBASE}" ac_add_options --with-system-ffi="${LOCALBASE}" ac_add_options --with-system-pixman ac_add_options --with-system-libvpx ac_add_options --with-system-nss ac_add_options --with-system-nspr

…

On Tue, Feb 6, 2018 at 10:09 AM, MatthiasSchuster ***@***.***> wrote: "The why isn't the issue here only the what" This why is the cause for this what. If you go this superexotic way of brandings in the open source community, you might be so kind to actually tell that. Packagers have much to do, to make their life even harder by stating "read all licences from top to the ground and consult some lawyers to be sure" is unpractical. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#86 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA9V0K96vmp1-MvTILAQSoMozzuFUFTCks5tSHlGgaJpZM4R48vm> .

[asiekierka]

As I understand it, Pale Moon does not want to be blamed and/or responsible for issues stemming from regressions in versions of libraries other than the ones they officially test with, correct? At the same time, OpenBSD does not want to be blamed and/or responsible for regressions in versions of packages which do not come with their system and, as such, were not tested anywhere near as well.

Sorry for barging in, but honestly, I think in this case both sides walking off and agreeing to disagree might be the best option, if so. (That, or I suppose Pale Moon could distribute an official build of their browser aside from the official OpenBSD ports tree - but I'm not sure if there's enough user demand to justify that?)

[mulander]

@mattatobin @wolfbeast

This is ridiculous. You were apparently approached 2 days ago. This repository is a work in progress staging area, nothing is built or distributed to users from here - heck, you attacked the person doing the actual legwork of getting your stuff to build on OpenBSD.

Regarding patches on the port and enabling branding - damn read that forum topic 'OpenBSD & Pale Moon: coordinating patches and officially branded package?'. They were likely to be upstream.

We rarely allow software to use bundled libraries - the equivalents in our system have patches that actually make them build and work on OpenBSD - I would guess that your bundled ones do not - hence would require the same work we put on the dependencies applied as custom patches just to build your project...

You flipped out with your cease & decease against a work in progress port of a person who was actually trying to cooperate with you.

I'm sure as hell I will personally stick the hell away from Pale Moon.

[atomicthumbs]

your browser, your way

[ShalokShalom]

@mulander

"I'm sure as hell I will personally stick the hell away from Pale Moon."

I already read the same in some communities.

This reminds me of the Debian - Firefox (Iceweasel) case.
While this one escalated probably quicker.

Once an attack is more important as cooperation, is there something ill.

[mattatobin]

The Mozilla Public License is several orders of magnitude from the Near-Public-Domain licenses than you guys may be used to.

The MPL clearly states:

This License does not grant any rights in the trademarks, service marks, or logos of any Contributor

This is where the Redistribution License comes in where Point 5 deals with unmodified and unaltered redistribution. Point 8 is a special exception to that which was created specifically for free and open source operating system packagers. If those are not satisfied then it falls to point 5 which is unmodified and unaltered and if THAT is not satisfied it goes to point 10 which is basically "Ask for special permission". Failing THAT it falls back to the MPL which does not grant any rights in the trademarks, service marks, or logos.

Because we do alter our in-tree libs with specific fixes with our glue in mind as well as add additional features and capabilities they are as much parts of the total sum of what makes up Pale Moon as the layout engine or javascript engine.

Most notably, nspr/nss as well as libpng, and who knows what happens with libicu.

So, since this has been a problem elsewhere and over the past few years.. I am considering ripping out the ability to use systemlibs period. What is your BSD policy of generally not allowing bundled libs in that case?

[apotheon]

Today is my last day using Palemoon. Rewarding offensive bullies running restrictively licensed projects is not high on my list of things to do.

[amitkulz]

Tone deaf upstream. I never ever used Palemoon, but I sure won't ever use it.

@ibara was just trying to port Palemoon, and as @mulander pointed out we don't allow bundled libs in OpenBSD...

[jasperla]

@mattatobin do you really think coming here and berating volunteers who put their spare time and effort into porting Pale Moon code to OpenBSD is a good idea? While you are certainly entitled to claims through your license and the other scrolls you reference, please get down from your high horse and realise your behaviour is actively turning people away from Pale Moon. Well done.

Folks, move along, nothing to see here.