When choosing a technology for the front-end implementation, there’s a pretty important, and ultimately the most important, issue no one should overlook. We’re speaking of the copyright of the final software system. At first glance, everything is apparent. As soon as the customer pays the vendor to develop a software system, the copyright for the system developed by the vendor automatically transfers to the customer (there are particular cases of contractual relationships that lay outside the scope of this article). However, some intricate copyright aspects may elude an untrained eye.
The Tricky World of Software Licensing
Let’s consider the following two options:
- The source code is written with the Webix UI library. Webix is written in pure JavaScript, doesn’t use third-party libraries, and provides access to many widgets (simple and complex) required to build a UI for a web application. A software system developed with Webix belongs to the customer as soon as the work is paid;
- The source code of a software product is written with React. It is the basic library for building the UI but doesn’t include ready-to-use components. However, thanks to an extensive community on the Internet, there’s a plethora of components you can use in your React source code and libraries for building them yourself. Therefore, you can create a UI of any complexity without significant effort. The software system built with React belongs to the customer after the work is paid.
It may seem that both described cases are equal, except that Webix is a paid library. With Webix, you’ll get the package with everything you need, while with React, everything is free, and the vendor will select the suitable components.
Read Also The Difference Between Programming Languages and Frameworks
The difference is that in the case of Webix, the client gets everything in one package under one license. With React, in its turn, the client receives a source code written with many libraries distributed under various licenses. Moreover, you can face the dependency chain, where Library A depends on Library B, Library B depends on Library C, and so on. It may have many levels. As a result, even a middle-size software project built with React can use several hundred libraries with different licenses.
Most of these libraries will be MIT-licensed, but not all. In the worst-case scenario, there will be a GPL-licensed library somewhere in this colossal dependency tree. All source code of the paid software product will automatically be required to be published under the GPL license and posted on the Internet at the first request of any curious person or the customer’s competitor. That’s how easily copyright can turn into a copyleft. Did the client initially want to spend a lot of time and pay a ton of money to the developer to build a software system, the source code of which they will be obliged to publish on the Internet in the public domain? That’s a rhetorical question.
How to Avoid Unpleasant Surprises?
The most straightforward option is to build the software system using paid libraries only. That’s why, at XB Software, we primarily use Webix or DHTMLX JavaScript UI Framework on many of our projects. Webix enables countless possibilities, including easier development, thanks to many auxiliary tools such as Skin Builder, UI Designer, Form Builder, Code Snippet, and Webix Jet. Being a full-fledged library with all the necessary components, Webix still allows your use of third-party tools, including MVC frameworks, Backbone.js, jQuery, Angular, and others. These and other features result, among other things, in quicker time-to-market. It compensates costs of using a paid library and, coupled with solving copyright problems, bring multiple benefits to those who choose it for building their software products:
Source: Warehouse and Inventory Management System
A more complex approach implies using free libraries like React, Vue.js, and others. In this case, the vendor is obligated to use third-party libraries only after the client’s approval. It is required to avoid getting into the dependency trap we described earlier.
There are tons of different licenses under which the source code can be distributed. If the client is not savvy enough to tell the difference between them, there’s a golden rule to follow: “MIT or BSD is good. Everything else is bad.”
With libraries that use Apache 2.0, you need to be careful. It requires including the library’s NOTICE in the NOTICE of the final product. It may lead to reputational losses, especially when selling a software system. Also, it negatively impacts the safety of the software product, because it reveals its internal structure, i.e., tells everyone what libraries the system consists of. Such information may help malefactors to understand what exploits they should look for and implement.
If the requirement for licensing is reported to the vendor during the pre-sale, the provided estimate will change quite significantly, and the process of its creation will take much more time. The reason is that a responsible vendor will have to spend time developing the entire UI to understand what types of components will be required. Plus, for each type, the developer must choose a free MIT-licensed component (all the libraries it uses also must be MIT-licensed). The vendor must find a suitable paid alternative or develop it from scratch if there’s no such option.
Read Also What is a Tech Stack and How to Choose the Right One for Web Application Development [2023 Update]
All this requires significant work from the Business Analyst to get a detailed description of the functionality, the Designer to draw the UI, and the Tech Lead to identify all components and libraries.
Suppose the client prefers not to spend time and start the development immediately based on an unfinished estimate. In that case, they agreed to start the project without knowing the budget and deadline, because a component developers expected to use may have an unacceptable license. Also, everything is aggravated by the fact that it can change after a new library version is released. Therefore, it must be checked before each release for production.
Conclusions
You must always be very careful when developing a software system based on free frameworks and libraries. It’s like walking on eggshells. You must navigate potentially tricky situations requiring sensitivity and careful consideration to avoid adverse outcomes, which requires a lot of experience. Suppose you, as a customer, have no experience in how a particular license can affect the source code of the entire software product and don’t want to get into the nitty-gritty of it. In that case, you can contact us and rely on the industry experts.