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

[meezwhite]

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?

• License

Most appropriate sub-area of p5.js?

• Other (License)

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

#6678 (comment)

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

#6678 (comment)

@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)

#6678 (comment)

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

#6678 (comment)

Thanks for your comments about the license @meezwhite!

Initial thoughts on the licensing proposal

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 (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

#6678 (comment)

@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 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.

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

#6678 (comment)

@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

#6678 (comment)

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 <script> tag where a browser addon could swap it out with a different p5 version would be in the spirit of this clause. If we make an FAQ about this, we can decide what counts as compliance for this point.
  • When you include copyright messages, to avoid making it look like p5 is also part of your copyright, you need to mention it and its license
• If you do modify p5:
  • Those changes also have to be open source and LGPLed
• Ultimately, though, if you want to commercialize something using the library, you have to read the license, and I think that's not a bad thing. It's not as easy as MIT, but if it forces you to interact with the community to ask questions, in my unofficial opinion that's actually a good foundation for a relationship between the commercial entity and the open source community.

Has this ever happened? Are there derivative works of p5.js where changes were/are merged back? I'm curious about this.

A lot of the work on WebGL that I did last year was originally motivated by supporting commercial work, where performance was a bottleneck and the state of p5 at the time would not have been sufficient. Initially the changes were done as an open-source addon to p5, and were later merged in as core features. Later changes were done directly through p5 and its community without first being an addon.

Comment by @limzykenneth

#6678 (comment)

Just to quickly note the following points

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 <script> tag where a browser addon could swap it out with a different p5 version would be in the spirit of this clause. If we make an FAQ about this, we can decide what counts as compliance for this point.
When you include copyright messages, to avoid making it look like p5 is also part of your copyright, you need to mention it and its license

Following LGPL for any commercial entity as long as they are not modifying p5.js is basically the same as following MIT or BSD licenses. This is how Instagram do it which is just a page of all the open source licenses (including very strict ones like GPL and permissive ones like BSD, MIT, ISC).

Comment by @GregStanton

#6678 (comment)

Hi @meezwhite! Above, you asked this:

Not sure whether more discussion is wished. Perhaps a separate issue would be more appropriate to direct discussion regarding licensing away from here?

Submitting a p5.js 2.0 RFC proposal seems reasonable to me, since any changes or clarifications regarding licensing would arguably qualify as a systemic change to an existing feature, in some sense.

I think @davepagurek's ideas about a clarifying document are both feasible to implement and helpful, so that could make for a good proposal.

Having a competing proposal about changing the license itself could also be helpful, even if it's just a way to flesh out the reasoning behind the choice of license, in a place where people can easily find it. If you're interested to submit a proposal like this, maybe you could include a summary of the discussion we've already had. Specifically, you could include points for and against the change under the sections on pros and cons. If one license feature is a pro from one viewpoint and a con from another, you could list it under both sections, along with explanations of how it can be viewed as beneficial or harmful, depending on the case.

What's the solution?

I propose licensing p5.js under a different OpenSource license which:

1. is less complex than LGPL,
2. is less prone to unintentional violation of LGPL
3. imposes less limitations than LGPL
4. (is compatible with GPL licenses) (?)

This new license wouldn't necessarily have to be an existing OpenSource license. We could create the "P5 License" (or even the "Processing License") if there are no other existing and suitable OpenSource licenses in alignment with p5's goals, similar to how Vim has their own license.

Multiple efforts could ease the transition to the new license:

1. Actively asking the past contributors to signal their agreement to switch to the new license. This could be done in an issue. Past contributors could be linked in this issue to make them aware of the intent.
2. Informing contributors and making it clear (in CONTRIBUTING.md) that by contributing to the library, they signal their agreement towards p5.js (and it's maintainers) to license their current and past contribution under the new license (that was agreed upon by the community), as soon as all parts of the code have received clearance from all respective contributors to be licensed under the new license.
3. Final-measure: if after a significant time has passed (e.g. 1 year), since the transition was agreed upon, remaining parts of the library which have not yet received clearance by the original authors would have to be removed, rewritten or (probably preferred) externalized.

Alternative solution

• [p5.js 2.0 RFC Proposal]: New Document outlining FAQs & Guidelines on Licensing & Usage #6800

Pros (updated based on community comments)

• Increased Confidence: A simpler, less complex license would boost users' confidence in utilizing p5.js across diverse projects.
• Enhanced Accessibility: A simpler, less complex license would make p5.js more accessible to a wider range of users (artists, educators, developers, etc.), especially those who don't have the means for proper legal consultation.
• Legal Compliance: Simplifying LGPL complexities would help users better understand their obligations, reducing the risk of unintentional violations.

Cons (updated based on community comments)

• Resource Allocation: Finding, agreeing on and transitioning to a new license would require time and effort from the community, diverting resources from other (potentially more important) issues.
• Uncertain Success of Transition and Timeframe: The transition may take a long time and sucess wouldn't be guaranteed, as past contributors may not actively participate in the process.
• Tracking Transition: Keeping track of which parts of the code have received clearance for the new license could be challenging.
• Disappointment Among Original Contributors: Contributors who don't agree with the new license may be disappointed with the transition.

Proposal status

Under review

[GregStanton]

Wow, thanks @meezwhite for putting together such a clear and thorough proposal! I'm looking forward to more discussion.

[limzykenneth]

I probably should start by saying this might be out of scope for p5.js 2.0 which is more of a technical update and for license update it does not strictly need to happen on a major release, and at the same time I think #6800 will probably be more suitable in terms of scope and actually is something we can do now instead of waiting for 2.0. License change is very disruptive so will be a slow process in any case, especially for a large mature project.

This new license wouldn't necessarily have to be an existing OpenSource license. We could create the "P5 License" (or even the "Processing License") if there are no other existing and suitable OpenSource licenses in alignment with p5's goals, similar to how Vim has their own license.

This is something that has been explored in open source and also in activist circles for a long time now. Famously there is the JSLint license but there are also many (the usual term I see is "boutique") license that are more common as sometimes proof of concept or as a statement on its own. I remember this kind of idea has also been explored in a p5.js community conference before. That is to say there could be interest in something like this given the right aim behind it.

However there are a lot of roadblocks towards being able to create and adopt something like this. First of all is to actually create something that is both enforceable and promotes values in line with p5.js as a project, there will likely be legal work involved. Second is that I am almost willing to bet that the OSI will not recognize it as Open Source™ (this is a very tongue in cheek ™), I personally don't particularly like the OSI be the sole arbiter of Open Source™ but can imagine it being an issue with the much wider open source community that may be more inclined to follow the OSI lead than to consider otherwise.