Each project we feature on DailyJS includes the license. If your project doesn’t include a license, it may not be used by the wider community and commercial developers.
Why is licensing important? From the author’s perspective, it can be used to influence how the project is reused. From our perspective, as users of your software, the license determines whether we can legally reuse your software.
Licenses are split into permissive and copyleft. Permissive licenses have less restrictive requirements about how the software can be redistributed – copyleft licenses aim to preserve the freedoms dictated by the original license.
Under these broad categories, the GPL is a copyleft license. The MIT license is a permissive license.
GNU’s site explains how to use the GPL. Other initiatives aim to help configure the most appropriate license for a given project, such as the Creative Commons non-profit organisation. For a large list of licenses, see the OSI’s list here: Open Source Licenses by Category.
jQuery Plugins and Client-side Projects
Many of the jQuery plugins we receive for review are dual licensed under the GPL and MIT. Why? Well, this allows the author of a derivative work to choose either license for their work.
The jQuery project itself has some comments on this: jQuery License
The MIT License is recommended for most projects. It is simple and easy to understand and it places almost no restrictions on what you can do with a jQuery project. If the GPL suits your project better you are also free to use a jQuery project under that license.
If you’re writing a jQuery project, consider adopting this approach as it’s widely used by the community.
It’s pretty clear at this point that Node developers like permissive licensing. Almost all of the Node modules we receive are MIT licensed. Let’s take a look at the current top 5 projects according to npm’s stats:
- Underscore: MIT
- CoffeeScript: MIT
- Request: Apache License Version 2.0
- Express: MIT
- Async.js: MIT
Notice that the Apache License is also a permissive license.
Isaac Schlueter wrote an interesting post about a modification to permissive licenses called “no-false-attribs”: Wanted: “no-false-attribs” OSS License. People are starting to include “MIT no-false-attribs” with their projects to denote that any derivatives must amend incorrect references like contact information and bug reporting links.
How to Include a License
It’s not acceptable to simply paste a license’s text into your readme, or a license file in the project. The license must be edited to include your name and the date of copyright.
Include the name of the license in your project’s readme and the license file. The name is important – people don’t want to have to memorise and recognise license text, they simply want to look for license names they know are compatible with their project’s policies. From my perspective, I want to be able to include the license name in my articles.
Also consider writing a package.json – even if it’s not a Node project! A well-written
package.json includes a license, author information, homepage and repository links.
- Choose a license based on your organisation’s policies, or your own opinions – have a look at some permissive or copyleft licenses and see what fits
- Include the name of your license in your project’s readme
- Add the license to your project as a text file, and edit it to include your name
- Write a
package.jsonthat includes the license name even if it’s a client-side project
This article was inspired by Why I’d like a “license type” setting for GitHub projects by Thomas Fuchs.