Closed scottgonzalez closed 3 years ago
@scottgonzalez can you create a pull request to remove it?
I would suggest leaving the copyright in the original files and adding comments that users can alter and change the copyright notice to the generated code to anything they want and are not bound to use our copyright or license in their own code. This is already well known in the community since we started the project, but making it clearer in the output or documentation gets a +1 from me.
I would suggest leaving the copyright in the original files and adding comments that users can alter and change the copyright notice to the generated code to anything they want and are not bound to use our copyright or license in their own code.
So you want to avoid a well known version of this via CC0 that actually deals with the legal issues around removing copyright where possible and instead create your own legal wording to handle this?
This is already well known in the community since we started the project, but making it clearer in the output or documentation gets a +1 from me.
Sure, but well known does not equate to legal correctness. This isn't just about clarity, it's about proper licensing.
What exactly would the terms be in your suggested change?
@scottgonzalez I made a mistake and was referring to code that is generated using bake. I will need to think about changing or removing the copyright from the files in the app repo. Make the pull request @lorenzo suggested and I will review it.
Thanks Mr. @phpnut for explaining our freedom to alter/remove baked copyright notices, I was never sure about that. I would be :+1: on removing it for app-specific files (only).
I think there should be two fold a.) CC0 for the app repo (one file which also points out that the core library is MIT based, just the app skeleton is for convenience CC0) - This file may be removed/altered by the developer. b.) A license template for baking that COULD be set to null string (if no per file license information is a preference). That license template would by default generate what it is currently generating but could be changed by the end user to fit her/his licensing needs.
I can take care of removing the licenses on the generated output of bake.
I couldn't find any templates in bake that added licenses to the top. I think this is only about the app skeleton files now.
Yes, I think those can and should be removed: https://github.com/cakephp/app/blob/master/src/Controller/AppController.php#L2-L14 They bear no meaning to the framework and every one cloning a fresh app and wanting to start coding has to first remove all those copyright notices in all class files.
The copyright notices should only be present in actually relevant (business) logic files or files relevant to the framework code itself IMO.
The 2nd option would be to have a bin/cake clean
command, which removes all those from the files after composer create-project. But this might not be necessary as this repo's AppController and other files are really just skeleton (bake) templates to get started.
//EDIT: for now this shell is able to clean your APP code.
Imo copyright on boilerplate code of cakephp/app should stay here, if removed, someone else can create bogus/app with restrictive license and no cakephp user is then able to use cakephp/app since that now conflicts with the bogus license. So no matter how little is in cakephp/app imo the copyright should remain there, not to protect the boilerplate itself, but to protect anyone using it.
CC0 would solve that? Not?
CC0 is like having no license at all. Op 24 dec. 2015 03:53 schreef "Jonas" notifications@github.com:
CC0 would solve that? Not?
— Reply to this email directly or view it on GitHub https://github.com/cakephp/app/issues/297#issuecomment-167032022.
Well, that leaves @dereuromark option 2 (post install clean command) does it not?
@ceeram Is there really a difference in having the license noise in every file at the top vs just once in the readme/root of the repository? Look at laravel for example, they do it that way for app and core. There is not a single license doc block in any of their files, and they don't seem to be worried about someone hurting their users (yet). Please clarify on that, I personally would very much prefer to have noise moved out of the PHP class files (even for the core) and put to a central location in the repository as long as that leaves the full copyright intact.
From my understanding, the license for a repo and its files is clear either way (files protected with only root licensing vs. verbose file licensing), and therefore it suffices to keep things DRY. But maybe you have more insight here.
Im not an expert in that. Should ask lawyers if that would suffice. Im just saying it should not be removed. Still, people not wanting to have it in their application for whatever reasons still wont be happy with a single file. They seem to not want to have it in their application at all.
From what i understood it should be in every file. Only if not possible for some (technical) reason you can have it in a folder where people would expect it to be. (Whatever that means) Op 24 dec. 2015 11:15 schreef "Mark S." notifications@github.com:
@ceeram https://github.com/ceeram Is there really a difference in having the license noise in every file at the top vs just once in the readme/root of the repository? Look at laravel https://github.com/laravel/laravel for example, they do it that way for app and core. There is not a single license code block in any of their files, and they don't seem to be worried about someone hurting their users (yet). Please clarify on that, I personally would very much prefer to have noise moved out of the PHP class files (even for the core) and put to a central location in the repository as long as that leaves the full copyright intact.
— Reply to this email directly or view it on GitHub https://github.com/cakephp/app/issues/297#issuecomment-167083348.
Imo copyright on boilerplate code of cakephp/app should stay here, if removed, someone else can create bogus/app with restrictive license and no cakephp user is then able to use cakephp/app since that now conflicts with the bogus license.
I'm not sure what case you're actually trying to describe, but if any users decide to use some other app boilerplate, then they have to abide by the licensing terms of that boilerplate regardless.
So no matter how little is in cakephp/app imo the copyright should remain there, not to protect the boilerplate itself, but to protect anyone using it.
The best way to protect the users is to waive the rights via CC0. That gives all users the right to use the code however they want, and nobody can change that. Providing (almost) any other licensing terms means that the user has a set of rules they must follow.
CC0 is like having no license at all.
This is very far from true. No licensing at all would mean that users have no rights granted to them. That's pretty much the opposite of CC0 which gives users the rights to do whatever they want (other than try to claim copyright on that code).
@ceeram Is there really a difference in having the license noise in every file at the top vs just once in the readme/root of the repository?
This is a bit of a gray area, so the answer to that question will differ based on who you ask. Lawyers look at decision in previous court cases for precedence, but there is no precedence here. As a result, some lawyers will say that you should put the copyright notice and licensing terms in every file, while others will tell you this is unnecessary so long as the licensing terms are available.
Look at laravel for example, they do it that way for app and core. There is not a single license doc block in any of their files, and they don't seem to be worried about someone hurting their users (yet).
Not just laravel, but the vast majority of open source projects.
Im not an expert in that. Should ask lawyers if that would suffice. Im just saying it should not be removed. Still, people not wanting to have it in their application for whatever reasons still wont be happy with a single file. They seem to not want to have it in their application at all.
The real problem isn't whether the terms are listed per file, but rather what license is listed. Even if the license were kept as MIT and moved to a single location, the fact that it's MIT requires the licensing info to continue to exist in the user's application. Distinguishing between the code that is copyright Cake Software Foundation and licensed under MIT vs. the code that is copyright someone else (the app developer, some consultant, a third-party developer, etc.) and potentially licensed under different terms gets tricky as the files are modified. Specifics depend on the size and context of the changes.
Switching to CC0 would mean that the app developer can just remove the licensing terms since nobody can claim copyright on the code anyway. Note that this doe not mean they can start to claim copyright or apply different terms to the boilerplate code.
Reading all this... one more :+1: for the strip command since it seems to be the perfect middle ground solution here; keeps me protected as an end-user and saves me the time to manually remove them every time I generate a new app.
Laravel?
The MIT license was chosen when the project started because it offers more freedoms and protections for the project and the community, It is not a viral license and does not require any application to be released under the same license. The whole spirit of OS development is that anyone can use the original work created by us. When you start removing those freedoms this is no longer OS.
Switching to CC0 would mean that the app developer can just remove the licensing terms since nobody can claim copyright on the code anyway. Note that this doe not mean they can start to claim copyright or apply different terms to the boilerplate code.
If the license were to be switched to the CC0 would the CC0 license information still remain in the files? From what I understand it would not and could be removed, so the end user would no longer have the freedoms to use anything that was originally licensed under the MIT however they want. I am not concerned how the works created by someone else is licensed, let them put their copyright and license info in each file so there is no confusion what is MIT and what is not.
I am still failing to see the need to change the license, the MIT is used by many projects. Are there any stats on projects using the CC0? I would also get input from our lawyers before making any official change.
@bravo-kernel Using the strip shell @dereuromark posted to remove the copyright and license from any files technically is violation of the license. You can license your code any way you want, put it in each file as stated above, but removing copyright notices "IS" violation of the MIT.
Thanks for clarifying Mr. @phpnut. I guess I will switch to quiet mode now as far as this subject goes and start preparing for :santa:
to remove the copyright and license from any files technically is violation of the license
This makes it very clear to me - and probably most others - that something is wrong here for our application boilerplate code.
There should be NO need for violating anything when the license is mentioned not in the files directly, but the project root folder. The files are still protected (as mentioned before other open source projects do it this way as well) and can easily be used with the same benefits as before.
You still cannot just re-license them without violating the original CC0 (or MIT we keep it) license (as it is right now), but you can put your own copyrights in it in your OWN app and ship it with your custom header doc blocks and sell your application as intended (this is new, no need to still include the MIT noise). Everyone is happy.
Can we please at least get legal clarification if that is a suitable way?
mkdir myproject
cd myproject
composer init
composer require cakephp/cakephp
Done. If you dont want the skeleton as it contains "noise" then dont use it? the included home.ctp is also required to be removed from any skeleton install. Would you consider this noise too?
Also CC0 imo is not a good fit for open source projects, it seems to be more appropriate for things like stock photos.
"CC0 was not explicitly rejected, but the License Review Committee was unable to reach consensus that it should be approved, and Creative Commons eventually withdrew the application" see: http://opensource.org/faq#cc-zero
@dereuromark What is wrong with it? The code is copyright and maintained by the project, I see nothing wrong with keeping that information there. You are free to use any license you want for code "YOU" write, nothing is forcing you to release "YOUR" code under any license at all.
What is your reason for wanting to remove anything that is not output directly so end users can see it?
@dereuromark I forgot to add the app root directory does not include a LICENSE.txt file so there is no noise here that anyone would confuse if you put your own LICENSE.txt file.
The MIT license was chosen when the project started because it offers more freedoms and protections for the project and the community, It is not a viral license and does not require any application to be released under the same license. The whole spirit of OS development is that anyone can use the original work created by us. When you start removing those freedoms this is no longer OS.
The MIT part is accurate, though leaves out the part where the licensing is still required to be maintained, which puts a burden on the user yet provides no benefit over CC0 to the user or the foundation. The spirit part gets into philosophy and morality, and I'd rather not get side-railed into that discussion.
If the license were to be switched to the CC0 would the CC0 license information still remain in the files?
As I mentioned above, that's basically personal preference as there is no legal precedence for the necessity. For users' sanity, I'd recommend not including the information in every file.
From what I understand it would not and could be removed, so the end user would no longer have the freedoms to use anything that was originally licensed under the MIT however they want.
A user who manually removes license information has not at all changed the laws that they must abide by. MIT requires the license information to be kept, so if the user removes the license completely, they've violated copyright law.
I am not concerned how the works created by someone else is licensed, let them put their copyright and license info in each file so there is no confusion what is MIT and what is not.
MIT is permissive and allows the user to sublicense the work, but the MIT license notice must stay in place. As a user modifies the boilerplate, there can definitely be confusion about which license applies to which parts of the code.
I am still failing to see the need to change the license, the MIT is used by many projects. Are there any stats on projects using the CC0? I would also get input from our lawyers before making any official change.
I have no stats, but I can say from experience that many developers don't fully understand the legal ramifications of what they do. There is never a reason for any sample code or boilerplate code to not be licensed as CC0. The entire purpose of such code is for others to use as they wish. CC0 allows that better than MIT. MIT is a much better choice for the actual framework code.
@bravo-kernel Using the strip shell @dereuromark posted to remove the copyright and license from any files technically is violation of the license. You can license your code any way you want, put it in each file as stated above, but removing copyright notices "IS" violation of the MIT.
Well, not any way you want. Only in ways that MIT allows. That's why CC0 is better for this specific set of code.
You still cannot just re-license them without violating the original CC0 (or MIT we keep it) license (as it is right now), but you can put your own copyrights in it in your OWN app and ship it with your custom header doc blocks and sell your application as intended (this is new, no need to still include the MIT noise).
There absolutely is a need to still include the MIT noise. It's a legal notice that states what terms must be followed, and one of those terms is including the "noise."
Also CC0 imo is not a good fit for open source projects, it seems to be more appropriate for things like stock photos.
Based on what? CC0 is a very good fit for open source projects. It's just a question of which portions CC0 is applied to.
"CC0 was not explicitly rejected, but the License Review Committee was unable to reach consensus that it should be approved, and Creative Commons eventually withdrew the application"
That's fairly misleading without context. The real debate was the fact that CC0 explicitly excludes patent protection, as opposed to a license like MIT which is silent on the issue (both provide the same protection against patents: absolutely none).
@phpnut I'd like to get an official legal response from the lawyer you've engaged with in the past on this. If the only outcome is "generated code is not subject to the same license", then we can just
That seems fairly reasonable to me. Would complicate the tarball release that markstory prepares a little, but better than having a non-responsive issue and a rotting PR.
👍 on the response of the lawyer.
I am not a fan of moving the app skeleton into bake. But IF done, there should just be a skeleton folder that gets verbatim-copied when running cake new
(similar to rails new
). However I'd still prefer to keep the MIT and how it currently is, if there is such a problem.
Better yet would be a CC0'ed application skeleton repo - I don't understand where the issue is with that?
Long: http://choosealicense.com/licenses/cc0-1.0/ Short: https://creativecommons.org/publicdomain/zero/1.0/deed Comparison: http://choosealicense.com/appendix/
Did you inquire if CC0 would work?
We do not need to alter the license of the code we provide. It is MIT licensed and will stay that way. Bake does not add a license to code it generates. This ticket can be closed.
I am a bit afraid of the consequences for projects.
So you have this MIT license block at the top. Then a projects adds business logic underneath, which is highly sensible (as in company secret) and business critical - and they then wonder if that is now also MIT because of the non-removable license on top?
As far as German lawers are concerned so far (and arent we usually the most detailed on some subjects^^) it suffices even to have them globally MIT licensed (with root or other options) and the files itself cannot just be re-licensed (legally) by evil 3rd parties. Therefore the only "reason" those were kept goes then away. All company written code in boilerplate templates should be able to get their own copyright - to make sure there are no "unclear" points as to if that file content is now MIT, or what part of it is or is not. This is almost impossible to decide after the files (on either side) changed a bit over time, which is the normal process of a framework and its templates...
Or at least waive the copyleft part as opt-in for projects - state somewhere that CakePHP allows the copyright replacement in those boilerplate (app) code files for ease of development if those do not lead to copyright claims back to CakePHP (which it can't due to the original MIT anyway). That would solve all issues?
@dereuromark
What consequences?
MIT is not a copyleft license. There is no replacing the license for the code the project has provided, anything based off of that code can be copyrighted however the person wants. What are you considering boilerplate code?
All in cakephp/app should be boilerplate, as that is what the user can either write himself or copy and paste to his needs and then adjust. There should be no business logic involved from core side. We should also make it as easy and straightforward as possible for them to start coding their own things in there.
We can use https://github.com/cakephp/app/blob/master/config/routes.php as an example. You could add very special custom routes which then should be copyright by that company that earns money with it. Do they need to keep the MIT copyright above? Or can they replace/remove? If it stays it makes the impression to a dev touching the code he can just copy paste that into a StackOverflow post - whereas this was actually company secret code - just because the MIT license on top confused him.
I agree that the Copyright should be removed from the files that make up the App source. The first thing any user is going to do is change the AppController file for example, and there should be no confusion as far as if any modifications need to be released under the MIT license too. Those few files should be license free, as well as any files made by Bake. I think we all know that it's not like CF is going to go after someone who modifies the AppController file and doesn't release that code under MIT... But in order to be used by professional companies, the license and adherence may be taken literally. It is best to not cause a headache and provide copyright free files that make up the skeleton.
This is almost 2 years old now. Any progress?
I'm in favor of removing copyright statements in files of this app skeleton.
Almost 4y ago this has been opened @markstory @lorenzo @ADmad @dereuromark @phpnut any news?
Edit: Could this be cleared up for 4.0 maybe?
Later in 4.x we could then add support for an LICENSE HEADER template that one can create and cake/bake can optionally consume. We could also inject the default cakephp license in there or at least a reference to cake/bake by default for those not caring to change the licensing of an app.
I was afraid of adding a comment here as I'm not interested in re-starting an apparently very charged discussion (as happens with every single similar discussion on a project).
However, I would like to see some clarification on this. What is the intended use of cake/app template from the cakephp dev's perspective? From the readme text, it sounds like you expect users to take this template essentially verbatim and use it over time.
Since this skeleton is a starting point for your application and various files would have been modified as per your needs, there isn't a way to provide automated upgrades, so you have to do any updates manually.
Does that mean you intend for users to have this skeleton portion of their app licensed under MIT in every setting?
If nothing else, maybe it should be clear that this is only meant as a toybox template and not the basis of your production work.
What is the intended use of cake/app template from the cakephp dev's perspective?
I have been using Cakephp/app in almost every project of mine. Have made over 50 sites using Cake3 and currently making the 3rd using Cake 4. Yes, production. It doesnt do wrong stuff and I recommend using this template in production. Quick and easy. The copyright notices did not bother me or my team. We are quite OK with notices staying there. However, when new controllers are generated we do not put copyright notices there, only comments related to the code.
This issue is stale because it has been open for 120 days with no activity. Remove the stale
label or comment or this will be closed in 15 days
Any news here? Can we fix this during the 4.x cycle?
Sit out a legitimate issue over 5 years? Really?
I think this not really is a question at all. Nobody cloning the app repo to start a new app should need to talk to their company lawyers first to decide if they can use it as a starting ground for their business secret containing app or not.
This should be crystal clear and without any doubt at first fight!
I don't care which solution achieves that goal. I too think not providing it anymore and have bake create a template app would be a good solution. This way it can ask the dev at app creation time to actually choose a license! Much like node does...
The other option to me would be to create a new skeleton app that provides this clarity and start promoting it instead of the official cake/app template. I believe that would be the worst solution though.
Please finally come up with something that solves the only problem with the license in this template:
Make it crystal clear to everybody looking at it from the first sight what license applies and what that means for the code you add to it, without needing to deal with a lawyer first and/or removing/altering license terms in the files or repository.
Thanks.
The closing of the issue was by the stale bot, which was an oversight on our end. Bad bot!
Hi everyone,
We’ve been monitoring and discussing this issue for quite a while internally, but there was a lot of back and forth either way. We eventually pulled in CakeDC for input, and they graciously sponsored the time for a lawyere to review this on behalf of CakeSF.
Unfortunately - as these things happen in OSS - we kinda neglected to post their followup here. I’m in contact now with CakeDC to have the lawyer post their summary on what covers the CakePHP Software Foundation, the core developers, and the community from any legal issues. We’ll be following their guidance for this - while not all of us are software developers by day, there isn’t anyone with a law degree on the core team - and we hope that folks in the community understand where we are coming from. Should there be any code changes that we can do, we will do them.
Apologies on the delay, but we’ll get this all straightened out soon.
Unfortunately, we were never able to re-surface the research on this.
We are closing this issue since the discussion was completed along time ago and decision made based on that a while ago. A new discussion would need a new issue and new participation.
Many of the files in this repo are copyright Cake Software Foundation and released under the MIT license. For example, see https://github.com/cakephp/app/blob/401ac46b85514da53ec2a2d153d92a77352743ea/config/routes.php#L12-L18. This is kind of silly since this is boilerplate for users to create new applications with. As a result, every application created from this template requires the generated portions to not only remain copyright Cake Software Foundation, but to always carry the copyright and licensing information.
I'd recommend just waiving the rights under CC0 and removing any copyright and licensing information from the individual files that are app-specific.