Read time: 10+ minutes

Introduction

For quite some time I wanted to make this research for me. We all know some general points about licensing, or at least have heard of GNU GPL, LGPL and few others. Most of the SW developers know at least that the idea of an open source SW is to remain open for the future generations, and that there are different licenses that provide you with a variety of rights to use, but not to distribute the SW, or distribute only unchanged pieces and so on. Each different license has a reason why it was created. And just like we have hundreds of brands of cars – we have now a jungle of open source SW licenses around. Most of the open source SW is distributed under some version or variation of few main ones – GPL, LGPL, Apache, MIT, BSD. Still – despite that this number is limited – the variety and details of each license differ quite a lot. A good comparison of most of them in a nice table form is given in Wikipedia here [1]. And in my opinion it is not so digestible due to its scope and hundreds of details. Finally I add – it turned out that there are quite a number of additional licenses that make the picture really colorful.

So – as I care only for the main points – I make this investigation with the purpose of understanding what happens when we have a regular company which needs to keep its SW mostly as proprietary and closed. We assume the company will never distribute its products openly as it wants to create a commercial product for profit. The question is – which open source library can I use, and what should I do if I’m limited? One common situation – GPL forces me to open the changes I did, but I cannot do it completely as I’m afraid my product will be copied.

Short note – if you are quite familiar with the area and you are in a rush – feel free to directly jump to the second part of the article, which describes the business cases and compares the licenses with respect to that. Otherwise please spend the 5 minutes to get into the briefly described terms.

******* ******* ******* ******* ******* ******* *******

Getting familiar with basics on Open Source

One of the main pluses of the open source SW is that you can use parts of it to develop a device with already prepared libraries. You can pay a developer to widen some of them for the common benefit and provide that part of the work to everyone, and then use the bundle of this library and some other libraries (e.g. proprietary of your company or bought from external companies) to create your product. It is a complete win-win scenario for all (considering that you will not release your product openly). And this is how the open source SW contributes immensely to the community and companies all over the world. Once a library is created – it can be used from everyone. At the moment that I make improvement – all users benefit. At the moment that someone else makes some attribution – I have the option to directly adopt the new features and fixes. But how to make the difference whether we can use this or that piece of source available around for commercial purposes? And what license to use when we want to contribute?

Before we go further I’m obliged to point out explicitly – the recommendations here are only about the basic points. This short article cannot replace the obligatory thorough check of a license once you choose a library source. If you have completely no idea of this – please read at least this article, and read the corresponding full license text carefully. In addition – most probably it is a good idea to consult with a lawyer specializing in SW and intellectual rights and licenses any time you have serious doubts or questions. Only then you can be sure that e.g. GPLv2 or BSD are ok for you to use in your current situation, or by some reason if a library is licensed under XXX – you should not use it at all due to marketing restrictions or your own company’s internal policy.

Let’s first list:

The main points of open source licensing

1. Each piece of SW can be copied practically freely once provided as a source. That’s why we need the licenses.
2. So we decide whether the user has the right to:
   1. Change it
      1. He may be allowed only to use it as is and not change it. And in case he wants to have further functionality – then he may have to make explicit external wrapper SW around the original piece.
      2. If changes are allowed – is he obligated to publish the changes or not.
      3. If changes are allowed – is he allowed to embed it in a resulting bigger product e.g. without mentioning it
   2. Use it for profit. Let’s imagine we have an open source library for reading capacitive touchscreen signals and able to recognize double and triple finger contact and basic gestures
      1. We can say that you are allowed to use it in commercial products only if you point out explicitly e.g. the name of the library on the cover of your product
      2. Or that you are strictly forbidden to use the library name for promoting the product
      3. Or you are not allowed at all to use it for profit
      4. Or that you are allowed to use it for profit but have to pay some single contribution fee
      5. Or that you have to pay per device (and yes – this may still be an open source based product)
      6. Think of any other possible options. Because I may say – my library is licensed under GPLv3, but with this and that addition or condition. E.g. – by default GPLv2 and v3 provide optional addition of the text “and any further versions of this license”. After all – the license is a free text inserted and / or written by the author(s).

Basic glossary of terms

3. For the purpose of licensing we need to understand the following terms (definitions are taken from Wikipedia as for this matter they are defined there perfectly obviously from people with experience in the area):
   1. Copyleft license – in general means the further copies of the SW and its derivatives will preserve the same licensing as the originating SW (e.g. GPL). Copyleft (a play on the word copyright) is the practice of offering people the right to freely distribute copies and modified versions of a work with the stipulation that the same rights leave inseparably in further derivative works. Copyleft software licenses are considered protective, as contrasted with permissive free software Copy-left means that the license is left in the copy you have created.
   2. Permissive software license – (sometimes also called BSD-like or BSD-style license) is a free software software license with minimal requirements about how the software can be redistributed. It is permissive – gives permissions. Examples include the MIT License, BSD licenses, Apple Public Source License and the Apache license. As of 2016, the most popular free software license is the permissive MIT license.
   3. Tivoization – a term deriving from the company TiVo that used Linux accordingly with GNU GPLv2 for creating consumer products and released their code. However they included additional piece of SW in their platform that checked the loaded SW thus preventing any future users of the HW to load their own SW on the TiVo HW platform. This is TiVo’s DRM
   4. DRM – Digital Rights Management is a set of access control technologies for restricting the use of proprietary hardware and copyrighted^[1] DRM technologies try to control the use, modification, and distribution of copyrighted works (such as software and multimedia content), as well as systems within devices that enforce these policies.^[2] DRM is used for movies, books, electronic documents, streaming media services and so on. Each restriction to use those freely is a type of DRM. E.g. you need special card and a device to decode and unlock some TV channels.
   5. Free software or libre software^[1][2] is computer software distributed under terms that allow users to run the software for any purpose as well as to study, change, and distribute it and any adapted versions.^{[3][4][5][6][7]} Free software is a matter of liberty, not price: users —individually or in cooperation with computer programmers— are free to do what they want with their copies of a free software application (including profiting from them) regardless of how much is paid to obtain the program.^[8][2] Computer programs are deemed free insofar as they give users (not just the developer) ultimate control over the first, thereby allowing them to control what their computers are programmed to do.
   6. Open-source software (OSS) – is computer software with its source code made available with a license in which the copyright holder provides the rights to study, change, and distribute the software to anyone and for any purpose.^[1] Open-source software may be developed in a collaborative public manner.
   7. Proprietary software – is computer software for which the software’s publisher or another person retains intellectual property rights—usually copyright of the source code,^[1] but sometimes patent^[2]
   8. Freeware – mostly proprietary SW that is provided at no cost. Classical examples – Skype and Adobe Acrobat Reader.
   9. FSF – Free Software Foundation – non-profit organization founded by Richard Stallman on 4 October 1985 to support the free software movement, which promotes the universal freedom to study, distribute, create, and modify computer software,^[4] with the organization’s preference for software being distributed under copyleft (“share alike”) terms,^[5] such as with its own GNU General Public License.^[6]
   10. FOSS – Free and Open Source Software

About the Copyright, Permissive, Weakly and Strongly Protective licenses

Now that we know the basics here are two pictures that I got from Wikipedia, from the Permissive license page. The first is self-explanatory in my opinion. The second is interesting as it shows not only some main permissive and protective licenses, but it gives you a grasp on the variety of licenses when we include their versions. The arrows show the transition to more protective SW or the general possible transitions. They mean e.g. a MIT licensed library may be included in a GPLv2 SW and probably re-licensed under GPLv2, but once you have any e.g. LGPL licensed piece of source – you cannot go back to the more permissive licenses and sign the whole bundle under e.g. BSD.

******* ******* ******* ******* ******* ******* ******* ******* ******* ******* ******* ******* ******* *******

******* ******* ******* ******* ******* ******* *******

Our business cases (Scenarios)

1. I want to create a SW that is proprietary, closed and for profit.

2. I want to create a SW that is proprietary, closed and for profit, I’m OK to release only the contributions made to the used libraries.

3. I want to create a SW that is proprietary, opened and for profit, I’m OK to release the complete source, forbid the users to change anything in my particular SW, and I want to forbid the users to use my HW for their customized SW.

4. I want to create a SW that is proprietary, opened and for profit, I’m OK to release the complete source, allow the users to change parts in my particular SW, but I still want to forbid the users to use my HW for their customized SW.

5. I want to create a SW that is proprietary, opened and for profit, I’m OK to release the complete source, allow the users to change anything in my particular platform, and I’m allowing the users to use my HW for their customized SW.

The important points

1. The first two cases are the most common business uses. The latter is always the better for everyone – it may return profit to you as well (because external users of the library may provide future improvements, fixes and new features that you can use).
2. All open source licenses have one thing in common – they provide no warranty for the quality of their product (though quality is mostly quite good or at least good enough for the purposes of its original idea). They have as well limited liability in case of issues (including customer penalties due to product malfunction). This means actually no liability at all – so YOU are OBLIGATED to test completely your product, the integration of the given external source and improve it if necessary to be able to guarantee 100% stability and zero defects. Considering that in general you are completely responsible for your product this is not a discovery of some kind. It means simply that you have to plan in advance the library integration and durability tests.
3. Example from real life – even when you are producing e.g. car doors – in case someone is providing you the windows you still have to check them as you are the end point to the customer. This means you check first the windows that come in your factory, and then each door before it gets out of the factory. So – checking the input and fully testing before the output of your production is already existing around long time ago.
4. Regarding patenting – this is a complete separate universe, but I’ll try to summarize it here. Patenting is a way of granting that a certain technology that is proprietary (no matter owned by an individual or a company) will remain in his full control, and any further use of it requires at least the explicit written consent of the owner and normally – in case allowed to be used by another person or company – it requires some form of fee. Part of the open source licenses grant explicitly the right to use them in a resulting product and apply for a patent with the resulting technology. Others say nothing about this (so mostly you are possibly allowed to do it), and there is a third class of licenses that explicitly forbid the user to use the SW for patenting.
5. Regarding patenting we have here limitless use cases. I would do this if I have created specific technology. As a result I will hardly break the rules related to some library e.g. in case I use XXX FOSS library for my speech recognition for a new type of a washing machine with voice recognition. I may patent the type of commands and the whole product or parts of it that are not related specifically to the speech recognition. On the other hand – if I want to create a commercial high quality voice recognition library that is based on some FOSS library or product – I will be strongly interested in checking the library license for such clauses. Result – as the subject is a completely separate characteristic that has nothing to do with: whether or not I create a commercial product; and has nothing to do with whether or not I will use FOSS; and has nothing to do with whether I consider sharing some contribution to FOSS – I will simply provide a list of the licenses that explicitly forbid patenting after the main table. Again I point out explicitly – patenting is a separate point of view to your technology, product or brand – thus it should be checked for crossing points with FOSS separately.

Now that we have the use cases – we can see external sources signed with which licenses are allowed to be used in the different occasions. Consider this – depending on your design different parts of your product may fall in different categories! This happens especially when you have complex device with different pieces of SW and HW, using multiple libraries and having complex multi-layered structure (OS kernel, low level drivers, higher level drivers and wrappers, and finally applications).

******* ******* ******* ******* ******* ******* *******

Resulting Table of allowed licenses for each Scenario

Here is the resulting table of which licenses to use for what. Lighter green means you have to be very careful due to potential license issues. Darker green means you can do anything in the given scenario. The yellow marked licenses give you full right to use the library for proprietary products.
But as you can see – there are quite a lot of licenses that give you directly the right to use the given source for anything. And at the moment that you are ready to share the contribution – you can practically use almost any license. The exceptions of GPL are that you are expected to make the whole product open source. That’s why it is tricky how to make one part of it completely open, and a second part – closed and proprietary. And as I may be condemned that I propose using GPL for anything like this – if I make commercial product based e.g. on a specific Linux distro, and I’m ready to share all my contribution, but still want to use it for a closed product – I think I do have the right.

After all – I openly state that I will share my attributions and provide them to everyone, but I will e.g. explicitly TiVoize my HW, put a clause in the license and prepare some custom additional application that will encrypt my device. Cause free and open source SW is great, attribution is great – but at the moment that my company of e.g. 150 people (and also my profit depend) on whether or not I disclose completely my product – I will definitely not do anything like using e.g. Linux. And at the moment that I don’t use it – I switch to other options – no matter commercial or free. So I then don’t support Linux and instead of providing attribution to it – I support other solutions. Where is the point then? FOSS, communism or what? FOSS, but only if you never defend your product. This is the result of people having almost no idea of marketing, market and “stealing an idea”, wishing to have the real freedom of everything for anyone and strongly believing that all the people around the world are nice, and that capitalism is bad, and so on and so on. And yes – I will not support them. Cause I care for my company and my team, and I defend my product.

The full table in an excel sheet format with all relevant additional properties like requirements on source disclosure, patent use, stating of changes publicly and so on is available here.

******* ******* ******* ******* ******* ******* *******

Regarding patenting

Based on GitHub’s page https://choosealicense.com/appendix/ and with links to the licenses text in this page:

A list of the licenses that explicitly forbid patenting:

BSD 3-Clause Clear License, Creative Commons Attribution 4.0, Creative Commons Attribution Share Alike 4.0, Creative Commons Zero v1.0 Universal

A list of licenses that explicitly grant a right for patenting but require source disclosure:

Eclipse Public License 1.0, Eclipse Public License 2.0, European Union Public License 1.1, European Union Public License 1.2, GNU General Public License v2.0, GNU General Public License v3.0, GNU Lesser General Public License v2.1, GNU Lesser General Public License v3.0, GNU Affero General Public License v3.0, LaTeX Project Public License v1.3c, Microsoft Reciprocal License, Mozilla Public License 2.0, Open Software License 3.0

******* ******* ******* ******* ******* ******* *******

A short description of the most common and famous licenses around

Again based on Wikipedia pages

GPL – GNU General Public License (GNU GPL or GPL)

A widely used free software license, which guarantees end users the freedom to run, study, share and modify the software.^[7] The license was originally written by Richard Stallman of the Free Software Foundation (FSF) for the GNU Project, and grants the recipients of a computer program the rights of the Free Software Definition.^[8] The GPL is a copyleft license, which means that derivative work can only be distributed under the same license terms. Versions:

1. Version 1 of the GNU GPL,[21] released on 25 February 1989,[22] prevented what were then the two main ways that software distributors restricted the freedoms that define free software. The first problem was that distributors may publish binary files only—executable, but not readable or modifiable by humans. To prevent this, GPLv1 stated that copying and distributing copies or any portion of the program must also make the human-readable source code available under the same licensing terms.[23]

The second problem was that distributors might add restrictions, either to the license, or by combining the software with other software that had other restrictions on distribution. The union of two sets of restrictions would apply to the combined work, thus adding unacceptable restrictions. To prevent this, GPLv1 stated that modified versions, as a whole, had to be distributed under the terms in GPLv1.[24] Therefore, software distributed under the terms of GPLv1 could be combined with software under more permissive terms, as this would not change the terms under which the whole could be distributed. However, software distributed under GPLv1 could not be combined with software distributed under a more restrictive license, as this would conflict with the requirement that the whole be distributable under the terms of GPLv1.

2. According to Richard Stallman, the major change in GPLv2 was the “Liberty or Death” clause, as he calls it[18] – Section 7. The section says that licensees may distribute a GPL-covered work only if they can satisfy all of the license’s obligations, despite any other legal obligations they might have. In other words, the obligations of the license may not be severed due to conflicting obligations. This provision is intended to discourage any party from using a patent infringement claim or other litigation to impair users’ freedom under the license.[18]

By 1990, it was becoming apparent that a less restrictive license would be strategically useful for the C library and for software libraries that essentially did the job of existing proprietary ones;[25] when version 2 of the GPL (GPLv2) was released in June 1991, therefore, a second license – the Library General Public License – was introduced at the same time and numbered with version 2 to show that both were complementary.

3. According to Stallman, the most important changes are in relation to software patents, free software license compatibility, the definition of “source code”, and hardware restrictions on software modification (“tivoization“).[26][29] Other changes relate to internationalization, how license violations are handled, and how additional permissions can be granted by the copyright holder.

It also adds a provision that “strips” Digital Rights Management (DRM) of its legal value, so people can break anything a court might recognize as DRM on GPL software without breaking laws like the DMCA.[30]

******* ******* *******

LGPL – Limited GPL

The LGPL enforces the ability to modify your project in any way. It may be incorporated into proprietary works which can stay proprietary, but the parts licensed under LGPL need to be distributed with it in a way that allows to modify the library the project uses. This is not enforced neither by the Apache license nor by the MIT/BSD licenses. The relevant part from the LGPL is section 4 which requires someone incorporating a library licensed under the LGPL to

• a) state that you are using the library
• b) provide copies of the GPL and LGPL license documents
• c) show the library’s copyright notice and finally the interesting point,
• d) Either distribute the library’s source code along with the program plus the ability to relink the program with a modified version of the library or use a shared library mechanism that allows to exchange the library with a modified version without breaking the program (assuming one doesn’t change the API).

******* ******* *******

MIT License

A permissive free software license originating at the Massachusetts Institute of Technology (MIT).^[5] As a permissive license, it puts only very limited restriction on reuse and has, therefore, an excellent license compatibility.^[6][7] The MIT license permits reuse within proprietary software provided that all copies of the licensed software include a copy of the MIT License terms and the copyright notice. The MIT license is also compatible with many copyleft licenses, such as the GNU General Public License (GPL); MIT licensed software can be integrated into GPL software, but not the other way around.^[8]

As of 2015, it was the most popular software license on GitHub, ahead of any GPL variant and other Free and open-source software (FOSS) licenses.^[9] Notable projects that use one of the versions of the MIT License include Ruby on Rails, Node.js, jQuery, and the X Window System.

******* ******* *******

BSD licenses

A family of permissive free software licenses, imposing minimal restrictions on the use and redistribution of covered software. This is in contrast to copyleft licenses, which have reciprocity share-alike requirements. The original BSD license was used for its namesake, the Berkeley Software Distribution (BSD), a Unix-like operating system.  It is a simple license that merely requires that all code licensed under the BSD license be licensed under the BSD license if redistributed in source code format. BSD (unlike some other licenses) does not require that source code be distributed at all.

******* ******* *******

Apache license

A permissive free software license written by the Apache Software Foundation (ASF).^[5] The Apache License, Version 2.0 requires preservation of the copyright notice and disclaimer. Like other free software licenses, the license allows the user of the software the freedom to use the software for any purpose, to distribute it, to modify it, and to distribute modified versions of the software, under the terms of the license, without concern for royalties. This makes ALv2 a FRAND-RF license. The ASF and its projects release the software they produce under the Apache License and many non-ASF projects are also using the ALv2.

******* ******* ******* ******* ******* ******* *******

One of the greatest examples of Open Source Platform that is as well commercially available and extremely successful in both areas is Android – it is licensed under Apache 2.0

Here is also an example how the “free and open source” Android (that can be used to build mobile devices) turns out to be not so simply free when you have to acquire an official license from Google to use the Google play services (Gmail, Playstore and Maps) for a commercial mobile device from The Guardian. In other words – before using a certain open source resource – please check for any potential “hidden costs”, post-fees, fees for standardization and so on.

******* ******* ******* ******* ******* ******* *******

A few other widely used licenses due to their parent products

Related to specific products and companies we have the following important licenses:

Apple Public Source License

License under which Apple‘s Darwin operating system was released. It is the foundation of the Mac OS X.

Python Software Foundation License

A BSD-style, permissive free software license which is compatible with the GNU General Public License (GPL).^[1] Its primary use is for distribution of the Python project software. Unlike the GPL the Python license is not a copyleft license, and allows modified versions to be distributed without source code.

Mozilla Public License (MPL)

A free and open source software license developed and maintained by the Mozilla Foundation.^[7] It is a weak copyleft license, characterized as a middle ground between permissive free software licenses and the GPL, that seeks to balance the concerns of proprietary and open source developers.^[8] It has undergone two revisions,^[9] a minor update to version 1.1, and a major update to version 2.0 with the goals of greater simplicity and better compatibility with other licenses.^[10]

The MPL is the license for Firefox, Thunderbird, and most other Mozilla software,^[11] but it has been used by others, such as Adobe to license their Flex product line^[12] and The Document Foundation to license LibreOffice 4.0 (also on LGPL 3+).^[13][14] Version 1.1 was adapted by several projects to form derivative licenses like Sun Microsystems‘ own Common Development and Distribution License.^[15]

Eclipse Public License (EPL)

License used by the Eclipse Foundation for its software. It replaces the Common Public License (CPL) and removes certain terms relating to litigations related to patents.^[6] The EPL is designed to be a business-friendly free software license, and features weaker copyleft provisions than licenses such as the GPL.^[7] The receiver of EPL-licensed programs can use, modify, copy and distribute the work and modified versions, in some cases being obligated to release their own changes.^[8]

******* ******* ******* ******* ******* ******* *******

Here is a full table of almost all relevant FOSS licenses on GitHub with really good description of each of the common features. And their home page https://choosealicense.com/  can help you even more when you want to choose a license under which you would like to share your knowledge.

Example for LGPL based commercial SW: https://www.medialooks.com/lgpl

https://www.medialooks.com/mformats/?utm_expid=385009-1.puXcDO7HQROiNOwT2T-iJA.0&utm_referrer=https%3A%2F%2Fwww.medialooks.com%2Fproducts%2F

Interesting article of GPL vs Apache licenses: https://digitizor.com/apache-license-vs-the-gpl/

Very important GPL/ LGPL / 2.0 / 2.1/ 3.0 combination table that shows you how you are allowed to combine libraries signed under different licenses: http://gplv3.fsf.org/dd3-faq

******* ******* ******* ******* ******* ******* *******

Final note: don’t underestimate licensing! Invest the day or two to get inside the key points. Play fair. If you have problems with the licensing scheme of some open source library – simply try to find a workaround – contact owners and developer’s groups, search for replacement, search for external freelancer that can help you with this part of the work. Rest assure, that opening one or two libraries of source code will mostly never compromise your product. Example: if somebody gives me the full blueprints of a car door – I definitely can’t copy the whole car. But somebody may be excited by the buttons on it and may use the idea for something else. Or can think of really fancy quite better new buttons. And knowledge will be spread. Because it is a fact – the more options we give for development – the more creative environment we will have.

******* ******* ******* ******* ******* ******* *******

I promised to give you an option for the case when you shall not use a SW due to its licensing scheme. The back door is simple. Let’s say you need a speech recognition library that shall remain open, but you really want to keep all your development closed by some really important reasons. The fastest option is to search for paid similar library. The slower (but still possible) is to form a small team of developers and give them this task:

1. Study the library OpenLibForSpeechRecognition. Understand the basic ideas behind it.
2. Find books and information sources on the subject. Find experts in the area. Investigate all existing different potential solutions for the task at hand. Prepare a list of all possible points of improvements and as well all possible new features that may be important or at least good to have in your project.
3. Start developing your own library only using the ideas from all sources. You are absolutely not allowed to use a single line of code from the open source lib. You are not allowed to use its structure and architecture. You are assigned the task of thinking of better architecture – so you are allowed to make explicit analysis of its ways of operation and you have to provide me (as your manager) with a proposal for our proprietary product with specific improvements and a custom proprietary architecture that will be solely our design.

Why this is OK? Will we abuse some license? In my opinion – partially yes, but only if we use pieces of the open source library directly. At the moment that you declare developing your own library from scratch – you only get some basic ideas. Of course this will cost money, development time, and the leader of the team shall be experienced person. But you don’t steal anyone’s idea because the idea of open source itself is to provide free distribution of ideas. You will neither harm the free development and use of the open source library itself. You will simply create your own product of your own custom design. If someone thinks he may “protect” his idea with e.g. GPLv3 – he should have never released his library as an open source product at first place. Otherwise he is merely pretending he is great and no one else shall use his idea to create anything unless he is willing to grant it for free for any future customer. And as long as we speak for basic ideas – this is like e.g. licensing the idea of Speech Recognition itself. Or like licensing the idea of creating windows from glass – because method X is already created and licensed – you are forbidden to develop you own version of it, and then change it completely, continue to upgrade and improve it until it becomes something completely different. Of course consulting with a lawyer with experience in the area and aware of similar cases is always a good idea if there are some serious doubts or unclear points. The risk shall be assessed and you, who have the task to find the correct solution, are not free from the responsibility for potential consequences. Hence the recommendation in the introduction – read completely the license under which your source of knowledge has been signed!

Of course some people may argue that my proposal is wrong and suggests a kind of piracy and license infringement. The truth is simple – the fact that I present openly this option doesn’t mean that it doesn’t exist. Because I merely state what is possible. Not to mention that most probably external person cannot even realize you used some idea from the FOSS XXX. And that – again – the fact that the functionality XXX was presented to the public as FOSS means someone was completely OK to give everyone the idea. Finally – except if anyone proves that you have direct copies of a FOSS licensed under GPLv3, and you have never shared the code – no one can make a successful law suit against you. That’s why my suggestion is completely OK in my opinion.

******* ******* ******* ******* ******* ******* *******

This article was written by me, Atanas Rusev, and is copyrighted under my name. You are NOT allowed to use parts of it in any online or offline text without prior approval from me. If I agree with you to use parts of it you will be obligated at least to state my name as author (and in case of online/web content – obligatory a link to this page).

Feel free to share the article link if you like it, and also to post comments below :).