Software licencing is becoming more and more complex each day. Progressive increment in no of licence is agonizing for architects and developers in choosing dependencies. Let’s take a look at few cardinal open source licence that a developer may stumble upon in the day to day life.

Why it matters?

Often it doesn’t matter if we are doing a weekend project, academic project or pet projects. But the licencing get very comprehensive and influential, when we talk about professional side of our day to day life. More than that, its significant if you are into an enterprise ecosystem.

Incautious about licenses could not only put you in niggle, but also take the entire organization into a diagnostic situation.

When we should be cautious?

“All that’s free is not free”

We should be cautious while dealing with

  • An external library.
  • An application for development, eg: IDE, Text editor, build tools, DBMS.
  • An external service.
  • Forking a project.
  • …

Kinds of licenses.

I know, remembering these would be tough, and you need not. These are the classes of licencees. In case you need to explore more feel free to open the links.

Now lets take a look at few licencees that we may come across.

MIT

Can be

  • Commercially used
  • Distributed
  • Modified
  • Privately used

Should be

  • Included with License and copyright notice

Also

  • Larger work can be distributed in any other licence.
  • Source code can be kept closed.

Limitations

  • Liability
  • Warranty

ISC [BSD2-Clause is almost similar to ISC]

Can be

  • Commercially used
  • Distributed
  • Modified
  • Privately used

Should be

  • Included with License and copyright notice

Also

  • Larger work derived from parent can be distributed in any other licence.
  • Source code can be kept closed.

Limitations

  • Liability
  • Warranty

Apache

Can be

  • Commercially used
  • Distributed
  • Modified
  • Patented
  • Privately used

Should be

  • Included with License and copyright notice
  • Documenting the changes happened in the work

Also

  • Larger work using the licensed work can be distributed with different terms and condition.
  • Source code of larger work need not to be open sourced.

Limitations

  • Liability
  • Warranty
  • No trademark rights

GPL

AGPLv1

Can be

  • Commercially used
  • Distributed
  • Modified
  • Patented
  • Privately used

Should be

  • Open source full source code
    • If the modified version is distributed.
    • If modified version is used to provide a service over a network.
  • Included with License and copyright notice
  • Using same licence for derived work (Copyleft)
  • Documenting the changes happened in the work

Limitations

  • Liability
  • Warranty

GPLv3

Can be

  • Commercially used
  • Distributed
  • Modified
  • Patented
  • Privately used

Should be

  • Open source full source code
    • If the modified version is distributed.
  • Included with License and copyright notice
  • Using same licence for derived work (Copyleft)
  • Documenting the changes happened in the work

Limitations

  • Liability
  • Warranty

LGPLv3

Can be

  • Commercially used
  • Distributed
  • Modified
  • Patented
  • Privately used

Should be

  • Open source full source code
    • If the modified version is distributed.
  • Included with License and copyright notice
  • Using same licence for derived work (Copyleft)
  • Documenting the changes happened in the work

But

  • If the project is a part of a larger work. And in the larger work, the project is used via interfaces, then the larger work could be distributed in a different licence. eg: Using a dll or jar file in a project.

Limitations

  • Liability
  • Warranty

Mozilla

Can be

  • Commercially used
  • Distributed
  • Modified
  • Patented
  • Privately used

Should be

  • Open source full source code
    • If the modified version is distributed.
  • Included with License and copyright notice
  • Using same licence for derived work (Copyleft), or could use GPL licence in some cases
  • Documenting the changes happened in the work

But

  • If the project is a part of a larger work. And in the larger work, the project is used via interfaces, then the larger work could be distributed in a different licence. Provided the original source code is not contained in the distribution.

Limitations

  • Liability
  • Warranty
  • No trademark rights

The Unlicensed

When you dont mention any Licence, or specifically say Unlicensed. Then

  • You are the sole owner of the work
  • No one can copy, distribute or modify your work
  • This may create chaotic situation if some one else contributed to work, because now you are also forbidden to use the other persons contribution
  • It is always a best practice to choose a suitable licence, and keep it with your work.

How to licence my library or application.

  • Add a LICENCE.md file at the root directory of project.
  • Checkout github documentation

Helpful links (Gratitude).

Terminologies

Term Meaning
copyleft The derivative work from this licence should always be of the parent’s licence
GPL GNU General Public License family
AGPL GNU Affero General Public License
LGPL GNU Lesser General Public License
ISC Internet Software Consortium

Conclusion.

Licencing is a crucial part of software development. We have to be cautious about licenses, when dependencies are being resolved. Most of the time, architects are responsible for all these actions. But that time is long gone, now junior developer may make decision. Decision of using a specific npm or maven or nuget module to avoid re-invention of wheel. Thus as a developer it is our responsibility to understand how each licence matter to our work.

On the other hand its important to specify the licence in a project we start. This is cardinal during distribution.

Just to add, my personal choice for an open source project is MIT.