Re: Adding functionality to a port

From: Guido Falsi <>
Date: Sun, 14 Nov 2021 19:49:52 UTC
On 14/11/21 20:32, Rob LA LAU wrote:
> And hi again,
> On 14/11/2021 19:42, Guido Falsi wrote:
>  > IN fact I would very astonished if some port (say firefox for 
> example) started behaving very differently than it does on other OSes 
> for no good technical reason.
> True.
> But what if we're not talking about 'behaving very differently'. How 
> about we patch a browser to send the user's passwords to a server we 
> own, while - apart from that - the browser continues to work as expected?

I'd argue that adding such a behaviour is a significant change in behaviour.

Apart from that such a change would be criminal in most jurisdictions 
too. And I'd add that the juridical system would simply persecute 
whoever owns the server the information is being sent too.

My opinion about allowed changes is also guided by avoiding this kind of 

>  > OTOH a valid technical reason could be dropping some functionality 
> depending on some API not available on FreeBSD, just to make an example 
> from the top of my head. >
> Dropping something because it is impossible to implement is different. 
> Sometimes you don't have a choice.

Exactly, so an acceptable change.

> My initial question was about a script that was added by the port 
> maintainer, which is not quite the same. Patching software to log 
> keystrokes, or to open a backdoor is also different.

I did not reply directly to your original question because I don't have 
a final solution.

You talk about "adding a periodic script". That is not even a real 
modification to the upstream software IMHO. Just adding some glue code 
for FreeBSD. If the script does what it advertises, and has no malicious 
intent I see nothing wrong with it. If it is broken fixing it is the 
logical thing to do.

Again, this is my personal opinion though.

> Clearly you can't solve all these problems by creating some guidelines 
> and rules. But I don't think that a serious software project can 
> continue without rules. Just like we need passwords and keys.
> And preferably those rules would be very clear and simple, so that the 
> compliance can be verified (largely) in an automated fashion.
Being a son of two lawyers, and having a lot of friends who are lawyers, 
and also clients who are law firms, my informed (by having had a lot of 
arguments with all these people about this very subject) opinion is that 
there is no such thing in the world as a "clear and simple" set of rules.

I think I could simplify this in an aphorism like this:

About rules and laws: Simple, clear and useful, you can't have all 
three, pick two.

Guido Falsi <>