Protection for packages from being copied without pay-or-wait limitation

[PatchRanger]

First appeared in https://github.com/ddeboer/imap/pull/277#issuecomment-355913369 . Also seems relevant https://github.com/salsify/jsonstreamingparser/pull/63#issuecomment-355770195 .

Problem

According a license any package has, it could be copied by someone without the pay-or-wait limitation.

Solution

The only solution I could imagine for now - is to change licensing for packages that want to adopt this monetization scheme to more restricitve: it should permit linking and forbid changing. I guess, https://github.com/Free2Wait/composer-free2wait/issues/1#issuecomment-355802857 could be the option.

[aidantwoods]

change licensing for packages that want to adopt this monetization scheme to more restricitve: it should permit linking and forbid changing.

This directly opposes the objective of open-source – to build great things together. This is impossible if the licence forbids changes. If you want this you should remove the project from GitHub because by uploading it here you consent to forking of the project, which would allow changes to be made.

https://help.github.com/articles/licensing-a-repository/

[mbabker]

The only solution I could imagine for now - is to change licensing for packages that want to adopt this monetization scheme to more restricitve: it should permit linking and forbid changing.

Translation - To even consider this madness, package maintainers must release their code under a license which contradicts the nature of open source software development.

[PatchRanger]

@aidantwoods @mbabker Why are you so categorical?) Please be more open to another point of view. I'd suggest you to read my arguments carefully (with all the proofs attached) before judging - because it's not the first case when I was mistakenly (!) blamed that I "really don't understand what open source means" (the previous one was https://github.com/Free2Wait/composer-free2wait/pull/7#issuecomment-355966324 )

This directly opposes the objective of open-source – to build great things together.

I could put the original idea about licensing wrong or you could get it wrong. But please note - forbidding to use modificated version doesn't opposes the idea of open-source! If you read the link I mentioned (I hope you did), you should know that "Apple Public Source License" approved by Free Software Foundation, Open Source Initiative and Fedora Project as corresponding to "free software" or "open source", while "Common Development and Distribution License" is "open-sourcy" for every competent organization apart "Copyfree": https://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses#Approvals .

This is impossible if the licence forbids changes.

My understanding of these licenses (I could be wrong - please correct me if you read the licenses and found that it is not true) is that they forbid to use changed code - but you can change the code of the library itself if the change would be accepted by project maintainers. The freedom to modify the code is not restricted - and that's why these licenses are mostly approved by the OSS-organizations.

[mbabker]

Your presumption that package maintainers would change their licensing models is in part demonstrative of the issue I have with your endeavor philosophically.

You asked for feedback from Joomla regarding this endeavor. Joomla is distributed under a licensing model (specifically the GPL version 2 or later) that allows users to view, modify, and redistribute the source code (with all respect to the chosen license and copyrights). The "fix" you propose in this issue is to take away from end users the modify and redistribute portion of that sentence; end users are allowed to view the code and nothing else. As a project maintainer, that is a lot of effort just to make a few dollars for asking users to wait a couple of seconds to get a download (in the case of Joomla this requires seeking approval of hundreds of contributors over a 12+ year period to relicense their contributions). Logistically, it just can't work. Philosophically, you will piss off a lot of people by taking away their rights as users of the software.

[PatchRanger]

The "fix" you propose in this issue is to take away from end users the modify and redistribute portion of that sentence; end users are allowed to view the code and nothing else.

@mbabker I agree that suggesting to change licensing for entire project is not the best idea ever) Probably it would be enough to change licensing on per-file basis: e.g., composer.json should be licensed under more restrictive license that permits linking (in order to allow incorporation with another source code of the project) and forbids usage of its changed version (to forbid avoiding pay-or-wait limitation) - while the rest of source code stays under the original license. That should prevent the original issue of immediate forking at the moment of adopting this scheme of monetization.

[mbabker]

So now you are saying that only the privileged are able to modify the Composer manifest of projects? And that the Composer manifest be licensed in a manner which may be incompatible with the project license, which would mean the Composer manifest couldn't be distributed with the source project (effectively meaning the source package could not be used with Composer)?

The point to be made here is that your pay to play plan fractures the ecosystem and the only people it benefits is those whose wallets get fat, assuming anyone continues to use their source package and does not go to a fork or alternative implementation, while at the same time placing heavy restrictions on how a project may be interacted with as a downstream consumer or a potential contributor (your solution has the implication that I could not legally click the Fork button here on GitHub and propose a modification to the source code). THAT is why this proposal is dangerous. You may have intended well with the proposal, but look at the practical changes this requires. This fractures the open source ecosystem and the PHP community in a way that makes the Laravel vs. Symfony spat seem like child's play.

[PatchRanger]

So now you are saying that only the privileged are able to modify the Composer manifest of projects?

Do you understand the difference between "forbidden to change" and "forbidden to use modified version"? It looks like you're missing them - so let me clarify it: project's composer.json should be public and could be changed with Fork button by everybody - this thing shouldn't be changed. The only restriction I propose in this issue - is to legally forbid usage of modified version of project's composer.json, that's it! The only way to legally modify project's composer.json - is to create a PR to the original repo. I guess, it shouldn't hit anybody's freedom.

And that the Composer manifest be licensed in a manner which may be incompatible with the project license, which would mean the Composer manifest couldn't be distributed with the source project (effectively meaning the source package could not be used with Composer)?

May - or may not. The purpose of mine is not to ruin everything leaving burning houses and crying children) I just want to determine what minimal changes are required to make the endeavor theoretically possible. If there is a way to make licenses compatible - fine, if not - looks like we should find easier way.

(your solution has the implication that I could not legally click the Fork button here on GitHub and propose a modification to the source code)

As I've explained above, it's not true, I do not want to restrict modifiactions - as that is what really drives open-source.

You may have intended well with the proposal, but look at the practical changes this requires.

That's the case: I want to see what would happen if we (theoretically) would choose that way. Thank you for your input, it helps to either eliminate all of the troubles and make it happen - or we'll see that it's no-way as it implies unaffordable damage.

This fractures the open source ecosystem and the PHP community in a way that makes the Laravel vs. Symfony spat seem like child's play.

Could you please review the situation once more - after accepting all of the new information I've said above? I still don't believe it would hurt open-source spirit, the opposite: I believe that it would help to grow it up. I see the issues - but I don't think it would fracture the ecosystem. Well, in fact I still believe that there should be an easy way to achieve the purpose (without "seeking approval of hundreds of contributors over a 12+ year period to relicense their contributions" or similar - that's a nightmare I agree) - but I suppose that I could be wrong)

[mbabker]

Do you understand the difference between "forbidden to change" and "forbidden to use modified version"? It looks like you're missing them - so let me clarify it: project's composer.json should be public and could be changed with Fork button by everybody - this thing shouldn't be changed.

It would change. If the Composer manifest is licensed in a way that forbids change, this means a user cannot fork the repository to propose a change because the derived work would be published via GitHub. If that fork is used, due to the licensing terms on the Composer manifest there opens the door for legal arguments to be made. Effectively this precludes the manifest from being altered and majorly restricting how users can interact with a project, or how a project may be distributed.

As I've explained above, it's not true, I do not want to restrict modifiactions - as that is what really drives open-source.

Except that is exactly what would happen for projects electing to participate in an endeavor such as this and making the changes required to enforce any protections it could enact. A licensing model that restricts modifications has a lot of ramifications, ranging from how the project may be distributed to whether it could even be hosted on a platform like GitHub.

The long and short is this, to "protect" a project in the ways you suggest with your issues on this repository collides heavily with the fundamentals of open source software development and can be damaging to the PHP ecosystem. You can't have an open and collaborative project environment while also imposing the restrictions that your thought collection suggests, both for philosophical and legal reasons.

[aidantwoods]

If you read the link I mentioned (I hope you did), you should know that "Apple Public Source License" approved by Free Software Foundation, Open Source Initiative and Fedora Project as corresponding to "free software" or "open source", while "Common Development and Distribution License" is "open-sourcy" for every competent organization apart "Copyfree":

I'd recommend reading the following from the Open Source Initiative: https://opensource.org/osd, in-which I think you'll find that restriction of modification to your desired extent is incompatible.

APSL does not forbid changes either: https://opensource.org/licenses/APSL-2.0.

2.2 Modified Code. You may modify Covered Code and use, reproduce, display, perform, internally distribute within Your organization, and Externally Deploy Your Modifications and Covered Code, for commercial or non-commercial purposes, provided that in each instance You also meet all of these conditions:[...]

Furthermore, as I and now @mbabker have mentioned, your desired restrictions appear to be incompatible with GitHub's terms of service.

If you publish your source code in a public repository on GitHub, according to the Terms of Service, other GitHub users have the right to view and fork your repository within the GitHub site.

https://help.github.com/articles/licensing-a-repository/

If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to use, display, and perform Your Content through the GitHub Service and to reproduce Your Content solely on GitHub as permitted through GitHub's functionality (for example, through forking).

https://help.github.com/articles/github-terms-of-service/#d-user-generated-content

---

Do you understand the difference between "forbidden to change" and "forbidden to use modified version"?

No I don't, these aren't sufficiently distinct. How are you defining "use"? Does testing to see if my change breaks anything count as using a modified version? What about opening it in a text-editor – where I have used the file contents to fill pixels on the screen?

Consider that you would have to use the modified version of the file to upload its changes. How exactly could you change a file without using it?

---

As a more general point – your objective seems to be that you would like to force users to run your code. You can't do this for many reasons... for example someone might produce a PHP extension to ignore your code. Someone may modify their copy of PHP, or composer to refuse to run it.

You cannot force someone to accept your licence either, they may simply reject your package along with its licence – someone could create their own package which "replaces" your one (causing theirs to be installed, and yours not). They could even just delete the files containing your code from their machine.

I'd hate to see the equivalent of ad-blockers have to make their way into the composer eco-system, but they'd be relatively easy to make if necessary. You wouldn't be able to do much about them either, because ultimately the user is in control of their own machine and what it runs.

And if you licensed against all of that (restricting freedom to modify other software on their own machine that they would otherwise be permitted to modify) then you definitely don't have something that's open-source.