-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Protection for packages from being copied without pay-or-wait limitation #5
Comments
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. |
Translation - To even consider this madness, package maintainers must release their code under a license which contradicts the nature of open source software development. |
@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 #7 (comment) )
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 .
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. |
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. |
@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., |
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. |
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
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.
As I've explained above, it's not true, I do not want to restrict modifiactions - as that is what really drives open-source.
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.
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) |
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.
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. |
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.
Furthermore, as I and now @mbabker have mentioned, your desired restrictions appear to be incompatible with GitHub's terms of service.
https://help.github.com/articles/licensing-a-repository/
https://help.github.com/articles/github-terms-of-service/#d-user-generated-content
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. |
First appeared in ddeboer/imap#277 (comment) . Also seems relevant salsify/jsonstreamingparser#63 (comment) .
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, #1 (comment) could be the option.
The text was updated successfully, but these errors were encountered: