Recently I was confronted with several projects that claim to be open source. I was happy to find their source code on a public repository but when looking at the license I was wondering why they do not take up official open source licenses but introduce their own proprietary licenses.

In my opinion, this severely hinders the uptake of these works - as non-experts on licensing cannot evaluate if the proprietary license statements are OK. Hence the conditions of usage of the source code are left ambiguous.

  • 1
    If the license is well written then the terms of use should be clear. Just take the time to read through the license in detail and see if you will want to comply with it. Commented Jul 2, 2015 at 13:41
  • 1
    Related: opensource.stackexchange.com/questions/71/…
    – Martijn
    Commented Jul 2, 2015 at 13:42

2 Answers 2


Beware of projects which claim to be open source but don't have a standard license approved by the FSF or approved by the OSI.

  1. Some people misunderstand what "Open Source" actually means. It is a very common misconception that simply allowing people to look at the source makes it open source. It doesn't - that's called "Source Available". To be really open source, a project must be licensed under a license which fulfills the open source definition. A very popular license clause some people try but which prevents a project from being open is a non-commercial clause. It violates the right of "No Discrimination Against Fields of Endeavor, Persons or Groups". It's far better to just use an existing license like the GPL which theoretically allows commercial use but practically has various conditions which make most common business models these people are usually afraid of completely infeasible.
  2. Writing licenses is hard. Licenses are legal documents. When you are not a trained lawyer and try to write one, it will likely not say what you want it to say or include clauses which are simply invalid or meaningless. So even when the author understood the definition of open source and wants his project to follow this philosophy, their homebrewed license might still be proprietary without them realizing.

So how to deal with such licenses?

When the license is short, you could try to evaluate for yourself if it fulfills the open source definition or the definition of free software. But when the license is longer or hard to understand, chances are that as a legal layman you will be out of your league. The best advise would be to ask a lawyer, but unless you have commercial interest in the software, you likely don't want to afford one.

You could also try to convince the author to switch to an approved open source license. There are so many licenses available that they will likely find one which says what they want (as long as what they want is actually open source). When they still do not want to abandon their own license, you might be able to convince them to at least dual-license the software under both their homebrewed license and a proper open-source license so that people can choose which one to use.

When they also refuse to do that, you might still decide to use it and even contribute to it, but you must be aware that the software might be gratis but not free and that when you contribute, you might be performing gratis work for a proprietary product. What you should do under no circumstances is merge the code into another project. That way you plant a legal landmine in the other project which might not just blow up on you but also on any downstream users.


Even a license that is not approved by the OSI, might still be Open Source. But, with an unknown license, it is hard to know what implications the license has and if it really supports the basic traits of Open Source. The creators might have intended to make it open source, but unwittingly might have created a license that isn't.

Choosing a common license has another upside: it is more tested as many projects use it and problems are already found and may be tackled in a followup-version.

  • 4
    A good example of this is TrueCrypt and the TrueCrypt License. While the intention of the license seemed to be to write a share-alike license in the style of the GPL, they added some very unorthodox passages which make it too legally shaky to be accepted as a proper open source license. (a real gem is this one: "NOTHING IN THIS LICENSE SHALL IMPLY OR BE CONSTRUED AS A PROMISE, OBLIGATION, OR COVENANT NOT TO SUE FOR COPYRIGHT OR TRADEMARK INFRINGEMENT." which basically says "this whole license is irrelevant") That's why you should not write licenses unless you are a lawyer.
    – Philipp
    Commented Jul 2, 2015 at 14:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.