search

processing / p5.js

p5.js is a client-side JS platform that empowers artists, designers, students, and anyone to learn to code and express themselves creatively on the web. It is based on the core principles of Processing. http://twitter.com/p5xjs —
http://p5js.org/
GNU Lesser General Public License v2.1
21.2k stars 3.23k forks source link

[p5.js 2.0 RFC Proposal]: Transitioning to a simpler, less complex License #6801

Open meezwhite opened 5 months ago

meezwhite commented 5 months ago

Increasing access

By transitioning to a simpler, less complex license, p5.js users (artists, educators, developers, etc.) could feel more confident and liberated in choosing p5.js for their work, thus increasing access to p5.js especially for those in marginalized groups that don't have the means for proper legal consultation.

Which types of changes would be made?

Most appropriate sub-area of p5.js?

What's the problem?

Complexity of LGPL: Without proper legal consultation LGPL:

  1. can be complex and hard to understand
  2. has certain clauses that in certain cases make it easy to unintentionally violate the license
  3. has certain clauses that in certain cases imposes limitations on the usage of the library

If you search for licensing question in the p5.js forums or here on GitHub, you can find several cases where users had questions about what is allowed and what not (me including).

Recent discussion that initiated this proposal

Discussion initiated by @meezwhite https://github.com/processing/p5.js/issues/6678#issuecomment-1932947280 > Hey everyone, > > I wanted to initiate a discussion about something that's been on my mind: the possibility of transitioning p5.js 2.0 from LGPL-2.1 to MIT. > > Now feels like a good time to talk about this, and I believe shifting to MIT could actually benefit the p5.js ecosystem. I'm not entirely sure how feasible or easy to do this would be, considering the existing code contributed by community members, was contributed to be licensed under LGPL-2.1, thus the keyword **transition**. > > Just to be clear, I'm not pushing too hard for this. But I think it would be valuable to discuss whether moving to MIT would make sense. **What do you all think?** > > I'm sure there are plenty of arguments both for and against this (see this issue almost 10 years ago: #293). To start, I'd like to mention two points, I can relate to. > > ### Avoiding dual-licensing when reusing p5.js code > Let's say I want to incorporate/adapt p5.js code into my MIT-licensed project. My understanding is that my project would now be dual-licensed, with some portions being MIT-licensed and others LGPL-2.1-licensed. > > If p5.js was MIT-licensed the incorporated/adapted p5.js code would still require proper attribution and inclusion of its MIT license, as stated in its attribution clause: > > > The above copyright notice and this permission notice shall be included in all > > copies or substantial portions of the Software. > > ### Encouraging adoption in commercial projects > Switching to MIT could foster increased adoption of p5.js in commercial projects. This shift _might_ attract businesses and developers who prioritize the flexibility and simplicity offered by permissive licenses. > > For instance, a company developing an interactive data visualization tool _might_ find it more appealing to incorporate an MIT-licensed p5.js version into their project, enabling broader usage (and innovation). > > Although modifying an MIT-licensed p5.js wouldn't require publishing the modified version, which _might_ actually "hinder" innovation, this could also be currently circumvented using the addon system. > > ## Related issues > #293 #5150
Comment by @limzykenneth https://github.com/processing/p5.js/issues/6678#issuecomment-1933020645 > @meezwhite Thanks for chiming in about this. To address the two points you mentioned about LGPL: > > > Avoiding dual-licensing when reusing p5.js code > > If your project is using p5.js as a library, ie. you are not creating a derivative work from p5.js code, you can license your code however you wish including under just MIT. LGPL only affects p5.js code. If you are creating derivative work of p5.js code I think it is fair to have that code contributed back under LGPL terms, I want to avoid the case where derivative work is created on top of the work that p5.js contributors created, but never contributed back to the benefit of the p5.js community. > > MIT license only require the license text to be distributed, not the derivative work. > > > Encouraging adoption in commercial projects > > Adoption in commercial projects is not really a priority and at the same time LGPL also does not prevent the use of p5.js in any commercial projects. LGPL only applies to p5.js code and unlike GPL, does not affect code using p5.js including distributing it via any channel including commercial projects. The only requirement that need to be fulfilled is only present if p5.js' code is modified, creating a derivative work of p5.js code, then the modified version must be released under LGPL but only the modified p5.js code, not the rest of the application code. > > This last restriction, as you identified, can be overcome with addon libraries > > > this could also be currently circumvented using the addon system. > > Addon libraries uses p5.js as a library and library authors are not modifying p5.js code nor distributing a modified version of p5.js code, so addon libraries can be freely licensed. > > I hope the above made sense.
Comment from @limzykenneth (unsure if part of discussion, but definitely important consideration) https://github.com/processing/p5.js/issues/6678#issuecomment-1933020736 > Sorry that I wasn't able to participate in the discussions very much recently as I have a lot of work piling up at the moment. However, to guide continued discussion a bit, I want to emphasize that RFC proposals must thoroughly and seriously consider **increasing access especially, to quote from the p5.js access statement, "prioritize the needs of historically marginalized groups over the continued comfort of more privileged groups"**. > > I want to take this quite seriously so that we don't venture down routes that goes counter to the goals of p5.js, and to re-emphasize that p5.js 2.0 does not change the goals, commitments, priorities, or non-priorities for p5.js as a project.
Comment by @GregStanton https://github.com/processing/p5.js/issues/6678#issuecomment-1933415792 > Thanks for your comments about the license @meezwhite! > > ### Initial thoughts on [the licensing proposal](https://github.com/processing/p5.js/issues/6678#issuecomment-1932947280) > This is an interesting topic. I do think the complexity of the current license has certain drawbacks. For example, since many in the community are not lawyers, understanding what the license actually says may be a significant impediment; in that case, they may not feel comfortable going forward even if their intended usage is allowed. In this sense, the MIT license is more accessible, because it's significantly shorter and less complex. So, I think there's room for thoughtful discussion here. > > But, as you noted, the feasibility of a license transition may be an issue, and that may actually be the first concern to deal with. My initial guess is that a transition to MIT at this stage, for a project as big as p5.js, is probably going to be infeasible. Roughly, my reasoning is this: since the MIT license is more permissive, we might need to get permission from all the previous contributors before moving to it. For a sense of the difficulty, here's an example of a project that attempted to do this: [PHPOffice/PhpSpreadsheet#140](https://github.com/PHPOffice/PhpSpreadsheet/issues/140) (It seems they did go ahead with it after a couple years of discussion, although I don't know if they made the change in a totally legal way.) > > Since p5.js has a relatively long history at this point and quite a lot of contributors, going through a similar process would probably be quite time consuming, possibly with no change being made in the end. The project I cited discussed rewriting contributors' code somehow in order to erase past contributions from people who didn't give their consent, but that seems problematic as well. > > _To be clear, I may be wrong and would definitely need to look into this more!_ I'd like to understand these issues better and would be interested to see further discussion. My goal here is to point out difficulties that may need to be investigated.
Comment by @meezwhite https://github.com/processing/p5.js/issues/6678#issuecomment-1935057904 > @limzykenneth Thanks for your answers and thoughts. Everything you said makes sense. A few thoughts: > > ### Avoiding dual-licensing when reusing p5.js code > Let's say I want to incorporate/adapt p5.js code (e.g. a filter shader) into my MIT-licensed p5.js addon. My library would end up being dual-licensed. The filter shader would be LGPL-licensed, while the remaining code would be MIT-licensed. > > ### LGPL isn't as straightforward as MIT > > ie. you are not creating a derivative work from p5.js code > > Understanding what qualifies as a "derivative work" might not be immediately clear to everyone. Personally, I have a rough idea, but it's not so easy for people who aren't lawyers or have to deal with licensing more often. A solution could be to create a document that outlines various possible use-cases, making it easier for people to understand how licensing applies in different scenarios. > > LGPL simply isn't as straightforward as MIT and can sometimes lead to questions, like in point 6: `Each time you redistribute the Library (or any work based on the Library)...` > > What exactly qualifies as `any work based on the Library`? Just this question alone has me reaching for legal advice or ChatGippity 😄 > > Other times you can simply go wrong. For instance, if an artwork were to display a copyright notice during it's loading screen (e.g. © Artist XYZ), LGPL states that `you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: ...` > > I'm simply pointing out that LGPL has certain clauses that in certain cases makes it easy to accidently do something wrong/against the license or poses certain limitations. > > > I want to avoid the case where derivative work is created on top of the work that p5.js contributors created, but never contributed back to the benefit of the p5.js community. > > LGPL doesn't necessary ensure that work is contributed back to the benefit of the p5.js community. For one, by using the addon system, others could still benefit from the work that p5.js contributors contributed, but never publish that code, since it _might_ not be considered derivative work. But even if the code was published, it doesn't necessary mean that the modifications of the work aligns with the goals and direction of p5.js and flow back into p5.js. > > ### Encouraging adoption in commercial projects > > Adoption in commercial projects is not really a priority and at the same time LGPL also does not prevent the use of p5.js in any commercial projects. > > Greater usage in commercial projects could increase exposure of p5.js, ultimately increasing access to it. Personally, I don't see commercial usage conflicting with p5.js's goals. However, LGPL makes it just a little bit harder for entities (developers, artists, non-profits, businesses) who don't have the legal means to simply adopt p5.js. > > ### Biggest consideration imo > > MIT license only require the license text to be distributed, not the derivative work. > > This is the biggest consideration imo (besides how legal and feasible it would actually be to transition to MIT). If p5.js were to adopt the MIT license, it would allow the creation of derivative works without mandating that those works be published. Again, I don't think that we can ever ensure that work created on top of what is already contributed will flow back into p5.js. > > Has this ever happened? Are there derivative works of p5.js where changes were/are merged back? I'm curious about this. > > ### Feasibility and Legality > @[GregStanton](https://github.com/GregStanton) Thanks for your initial thoughts and your considerations. I agree with what you said. > > I'm not sure whether it would be legal or not, to simply change the license, feels like a gray area. Although there could be an argument made that the p5.js maintainers have the authority to change the licensing model of the library, this would require proper legal consultation before moving forward. > > It would be optimal to get everyone on board. But what if somebody who contributed code isn't around anymore? 🤞 I can imagine that specific parts of the code could be rewritten, although I don't know how to feel about simply removing freely-contributed code by a contributor. > > If MIT would be of benefit and would still align with the librarie's goals and long-term vision, then a transition would be my suggestion. This could be achieved by having contributors actively agree to license their past and future work under MIT when commiting to the library. You can find a similar approach in my p5 addon, p5.grain here: [CONTRIBUTING.md Licensing](https://github.com/meezwhite/p5.grain/blob/main/CONTRIBUTING.md#licensing). > > Not sure whether more discussion is wished. Perhaps a separate issue would be more appropriate to direct discussion regarding licensing away from here?
Comment by @limzykenneth https://github.com/processing/p5.js/issues/6678#issuecomment-1935107059 > @meezwhite > > > Let's say I want to incorporate/adapt p5.js code (e.g. a filter shader) into my MIT-licensed p5.js addon. My library would end up being dual-licensed. The filter shader would be LGPL-licensed, while the remaining code would be MIT-licensed. > > If you are directly including code belonging to p5.js and redistribute it as your own code, I think it is fair to expect your code to be made available under the same terms, that is intended, in this case your code cannot be dual-licensed, it must be LGPL or compatible licenced. If your code is using p5.js features or code over an API, that is not you redistributing p5.js code so you can freely license, ie. if your code is using p5.js shader over an API (via WebGL) it does not affect your code, you do not need to dual licence since the p5.js shader code is already covered by our LGPL. You will only need to declare your own code's license. This is the same way that it works under MIT, ie you don't need to include every single MIT license declaration for every MIT licenced code you use (and how we use dependencies in p5.js itself!). > > > LGPL isn't as straightforward as MIT > > Most people will not be creating derivative work of p5.js except when working on the source code of p5.js itself. If you are working on p5.js itself that work, if you are redistributing it, should be made available under LGPL otherwise theoretically someone can take p5.js' code, make improvements to it and sell it without ever contributing that improvement back to open source. > > LGPL ensures that modification is contributed back to open source by forcing it to remain open source through LGPL. Since any modifications will remain LGPL, we can by ourselves copy the code back to our project. This is what forcing the work to be contributed back means, it does not require any good will from the other party to file a PR or anything like that. Addons are delibrately designed to fit around that, since addon is not a direct modification of p5.js it can be freely licensed and if LGPL encourage people to create addons instead, I'm fine with it. > > > Encouraging adoption in commercial projects > > Not all exposure is good exposure, and increasing access is not about increasing the raw number of users but to increase accessibility for the right group of people, aligned with p5.js access statement. I don't see how commercial exposure necessarily targets that. Plus, there is no legal mean necessary for any commercial project to use p5.js as long as they don't modify and redistribute p5.js source code under another license. > > > If p5.js were to adopt the MIT license, it would allow the creation of derivative works without mandating that those works be published. Again, I don't think that we can ever ensure that work created on top of what is already contributed will flow back into p5.js. > > The point here is not that LGPL will ensure anyone who made changes to p5.js source code will contribute it back, but rather if they made changes and release/redistribute it under another license, they will be in violation of the license terms. It protects the project from people taking the code modify it and sell it under a restrictive license. > > > Has this ever happened? Are there derivative works of p5.js where changes were/are merged back? I'm curious about this. > > Not too long ago I used to be a big advocate of permissive license such as MIT license as well but just a bit of annecdote and I will avoid any identifying information but will just say this is for a different open source project (not my own) and from my experience. Said open source project was released under a permissive license and was release as kind of a hobby project for the original author. The project has slow development since it was only one person working on it. > > What happened was that it was found out later that the project was republished wholesale by someone else without obtaining permission from the original author, where this new publisher proceed to indicate that they have co-created the project. The new publisher also proceed to use the code with extra modifications as a bundled premium offering sold for profit under commercial closed source license. Because of the permissive nature of the original code license, there are no recourse for the original author to be fairly compensated for their work that now someone else is profitting off of to the detriment of users of open source projects. > > What I mean to say is, there are very valid reasons that licenses were chosen the way they were chosen and licence terms were written to say what they say. I will still use permissive license in my own projects but I'm more and more concious of the fact I'm only using it when I don't care about the project's code that I wrote, where the code actually matters I'm having second thoughts.
Comment by @davepagurek https://github.com/processing/p5.js/issues/6678#issuecomment-1936153931 > I think some of those common questions (what do I credit if I just use p5 in my art? what do I credit if I use an addon? what do I credit if I copy and modify code from p5's source code?) are things we could try to answer in a readme or a page on the site to make things clearer. Although commercial uses aren't the priority or goal, it probably can't hurt to make it clearer how they fit within the LGPL. Would that help alleviate some of the concern? > > A brief summary of my reading of the LGPL for commercial projects > * If you don't need to modify p5: > * Using p5 as a dependency of closed-source code is allowed > * You can't make p5 effectively be closed by deeply bundling it in: the LGPL text describes letting users use their own version of the library. IANAL but it sounds like just embedding p5 with a Githubissues.
  • Githubissues is a development platform for aggregating issues.