Include attribution requirement in the licence

[Wirone]

Background

Following this tweet I would like to propose adding attribution requirement to our licence. Currently we allow usage as-is, while preserving copyright information, but IMHO it does not work good when it comes to usage within binary executables, like Pint, which releases contain only built PHAR file, composer.json and Laravel's MIT licence:

In this case, the only mention about PHP-CS-Fixer is in require-dev section of composer.json file, which is not enough in my opinion.

Proposal

I think we should add attribution requirement to our licence, so tools that use Fixer under the hood would have been obliged to provide explicit credit visible to the end user. The thing that should be decided is level of the attribution.

References

• https://opensource.stackexchange.com/questions/8161/license-that-requires-attribution-to-end-users
• https://katedowninglaw.com/2022/11/28/is-open-source-attribution-dead/

[Wirone]

Side discussion: (how) do we want to attribute packages we use internally?

[innocenzi]

Pint does explicitly say that it uses php-cs-fixer under the hood. Just saying.

As a side note, I think you're being super petty with the Laravel ecosystem and you should reconsider where you put your efforts. You're free to do as you want, obviously, this is just friendly advice. Improving php-cs-fixer itself is more important than denying its usage with unfinalize, for instance.

[Wirone]

As I said: I believe unfinalize can be considered harmful for the community since it encourages bad practices. People should learn software design, both as a package authors and as the users. Removing final from vendor code and building something on top of it, instead of understanding that software and contribute when it could be improved, is not something Fixer should be used for.

As lons as I see Steve already prepared PR that replaces Fixer with nikic/php-parser, so topic closed - tool will continue to work, but without using Fixer which is enough for me.

[innocenzi]

instead of understanding that software and contribute when it could be improved

Do you realize that you could need a quick workaround in a situation, and PR after to fix the issue in the underlying package? Do you also realize that some packages are not actively maintained?

It's great to have dreams, but if you're being realistic you'll realize that band-aids are often needed in software development. It's not all white or black. There are situations which you, Codito on the internet, did not think of when trying to deny something to 1000s of php-cs-fixer users in the world.

[Wirone]

I know that ad-hoc band-aids are sometimes needed and I know that there are other tools offering similar output. However, they don't use Fixer under the hood and are not advertised as "fight for freedom". Please take a look here, also several other places that I won't link now 😅.

Also, Steve got initial feedback long time ago that we're not happy with him using Fixer for that, but he still did it, as an executable binary that is installed to end users without any credit for the tool he's using. Why people are so angry about our decision, when it was Steve who did not respect our opinion?

[innocenzi]

Why people are so angry about our decision, when it was Steve who did not respect our opinion?

Because his decision is not harmful to anyone (quite literally), but yours is harmful to all users of php-cs-fixer who need, for any reason, whether you like it or not, unfinalize.

In that thread you linked, the PHP CS Fixer account, who I think is managed by you given the writing style, said:

Being adult does not mean you have to break other people's decisions.

It also applies to you. You should act as the adult and don't break my decision to use unfinalize if I want to.

[Wirone]

Being adult does not mean you have to break other people's decisions.

It also applies to you. You should act as the adult and don't break my decision to use unfinalize if I want to.

That's actually very good point 😉. Personally I don't have problems with removing final itself. I have problem with few things around unfinalize that I described several times already.

[stevebauman]

You gotta chill with this vendetta @Wirone. It's not healthy. Let it go ❤️

[Wirone]

I'm chill, and I don't have any reason for vendetta. I've pointed lack of Fixer attribution several times already, first time when Pint was released and my opinion about it is exactly the same now. The idea about including it into the licence came up after several discussion related to unfinalize and it's something that I would like to discuss. Nothing personal, strictly caring about our tool.

[stevebauman]

I don't think anyone is going to believe this. I've personally never seen such a dramatic and drastic action taken on an open source package before. Peace and love homie! ❤️

[Wirone]

I don't think anyone is going to believe this.

🤷‍♂️

[keradus]

if project X uses the PHP CS Fixer as a dependency, it should mention that somewhere - maybe in deps list like composer.json file, maybe in license-3rd-party alike file, maybe in readme, maybe... somewhere legit.
as long as nobody hides it and pretend otherwise, I'm OK with that.

Imagine the other way around Wirone, should we start mentioning in readme/each CLI usage that we are using symfony/console to run our CLI? or PHP tokenizer? we do it in our deps manifest and that's enough.

I'm OK to come back to this discussion if circumstances would change a lot, but for now, I don't plan to change anything regarding licensing.

[Wirone]

I understand that and mostly agree, but you did not address the main thing in this discussion - PHAR files. Is mentioning Fixer in the source repository's readme enough, or this information should be included in the release somehow?

[keradus]

That question would apply to any dependency of the phar file - and to any phar [similar to Fixer's phar ;) ] . I don't have gold solution for it and I don't see a need to organise it urgently.

Potentially, it could be a challenge for the whole PHP community to figure out the best way of doing it, that could be applied for wide group of phar distributions. If to put any focus on this topic around Fixer, I would suggest to act locally on our own food first, before expecting others to do it on their side.

[Wirone]

That's why I created this that went unnoticed 🤷‍♂️.

Even though I personally believe that we could address it on our side, I agree it's a community-wide problem to solve and I understand your decision. Thanks for jumping in 🍻.

[theofidry]

It's a hard problem, but case on point I do not see myself adding "Powered by SymfonyConsole 6.3.11" printed every time I run my CLI...

[mbabker]

IMO this question is better posed to a license/copyright expert and not to an opinionated community. So long as unfinalize and Pint fulfill the attribution requirements of the MIT license that PHP-CS-Fixer is released under, there should be no issues. Any additional requirements may or may not be in line with the MIT license, and may or may not impose unintended consequences on downstream users of your tool.

[Wirone]

I agree, I created this to discuss and get familiar with other people's opinion.

So long as unfinalize and Pint fulfill the attribution requirements of the MIT license that PHP-CS-Fixer is released under, there should be no issues.

The question is: do they fulfil? 🤔 🤷