Tag: legal

The good, the bad and the ugly of the proprietary software model

January 15, 2022 /

The last article discussed the advantages and disadvantages of the Open Source software model. We even listed some uncomfortable truths regarding its economic viability and how it could be more expensive than many proprietary products. Despite being an Open Source zealot, I want to start with the statement that I still think proprietary software is sometimes better than Open Source ones. We can not compare my case with the average customer because I have spent the last 18 years working in IT – aka I want much more control over my system than the standard PC user. At the same time, when I can, I strongly avoid using proprietary software because I want to know what runs on my device or have the ability to review it if I wish. But let me list the good, the bad, and the ugly of using proprietary software:

The good

  • Legal responsibility: Wishing or not proprietary software vendors are obliged by law in most countries to take care of their customers and the data coming with the usage of the software. And yeah, many governments try defending their citizens and their data.
  • Better support: No one will pay for proprietary software if support is not included in the price. The difference to the Open Source vendors is that you receive some hours of first-level support with the cheapest plans, which is better than nothing.
  • Centralization: Having a more centralized way of management has advantages such as faster development speed, faster decision-making process, and fewer intrigues. 
You can see a comparison between BlackBox and Whitebox software on the diagram. Open Source software is considered Whitebox because everyone can see and review its logic. On the other side, proprietary is considered as BlackBox because to analyze its behavior, analysts must use reverse engineering techniques

The bad

  • You should pay for it: One of the bad things regarding proprietary software is that people should pay for it. And the main problem is not the cost but businesswise; when you are using something you don’t have access to, you introduce a critical business dependency. What happens if suddenly this software vendor disappears?
  • Closed ecosystem: Decisions are made by the company’s owners producing the software. Customers usually do not have control or involvement in feature design and implementation. 
  • More complicated collaboration: If two companies want to work together, they should sign a contract, and by signing this contract, they “decide” how their partnership will happen. By not having a ready-for-use framework, lawyers must review every agreement and make sure that both sides are happy with it.

The ugly

  • Sometimes less secure: Proprietary software has the same security problems as Open Source software. Many hackers are pretty adept in reverse engineering and finding security holes. Additionally, proprietary vendors must pay for security audits and could not rely on an ecosystem of hardcore software engineers to do that for them.
  • Lousy support for smaller customers: The bigger a software vendor becomes, the lousier its support becomes for its small customers. And this equals them to the Open Source software vendors without support for their free plans. And yeah, there is a reason for the number of jokes regarding the quality of support provided by given operating systems manufacturer :-).
  • Weaker legal defense: The bigger a software vendor becomes, the more legally powerful it is. And this leads to fewer opportunities for its small customers to search for justice. Usually, the side with the bigger pool of resources is the winning one in legal battles.

In conclusion, there is no significant difference between proprietary and Open Source software models. The only meaningful difference is that customers could legally claim stuff easily from smaller proprietary vendors. However, once the vendor becomes too big, they hire better lawyers, and experienced lawyers are pretty good at defending corporate interests. Other than that, the tradeoff for the end customer is first-level support versus free usage.

The good, the bad and the ugly of Open Source software model

January 9, 2022 /

I want to start this post with the statement that I am a fierce supporter of Open Source, and all of my computers, servers, and smartphones are using different flavors of Linux. For the last ten years, I have used Windows ten times at most, all of this because some software vendors have been neglecting the Linux ecosystem for years. Other than that, I have no wish or necessity to touch Mac or Windows for anything rather than testing web or mobile apps. 

At the same time, I want to strongly emphasize that Open Source as a model has its problems and that I believe no software development practice, Open Source or proprietary, is ideal. This post aims to list some of the advantages and disadvantages the Open Source model has. Despite its widely successful spell during the last 30 or more years, the model is somehow economically broken. But, let’s start with the lists:

The good

  • Open Source is almost free: Most open source projects provide free plans for casual users or tech-savvy customers by having an ecosystem. This way, a whole set of companies can build their business model based on these freemium plans and add value.
  • More openness: People working on open source projects must make an ecosystem. And people stay in any ecosystem only if the system is open to proposals and changes according to members’ needs. In another case, the ecosystem usually does not survive for long. Additionally, everyone can review the code and search for security holes.
  • Better collaboration: Legally speaking, if two organizations want to work together, they should sign a contract on every point they want to collaborate. Organizations already know how to work with the various Open Source licenses and do not need to reinvent the wheel for their specific case.

The bad

  • Lack of responsibility: Most Open Source software comes without any obligations for the authors. Whether there are security holes, bugs, or losses by using the software – authors are not responsible.
  • Too much decentralization: When a project becomes too popular, the lack of centralization increases politics and power struggles. By having multiple controlling bodies or boards of people governing the project, the number of interested parties increases and thus sometimes making the decision-making nightmare.
  • Lack of support: Some Open Source projects entirely lack technical or user support. Even if they offer support, the customer must pay too much money to get any meaningful help. The plans with the lower cost usually are not helpful enough.
On the diagram, you can see a standard crawler architecture diagram. Most of the products implementing this diagram would use Open Source components to speed up the development and lower the cost. They must live with the problems derived from using these components

The ugly

  • Sometimes less secure: Many projects do not have the proper set of resources to ensure their level of cybersecurity, despite being used by many people. A recent example of that is log4j – all major Java products use it, and at the same time, a big security hole was discovered a couple of weeks ago.
  • Complicated business model: Open Source is complex for monetization. Many products try surviving on donations or support. However, this monetization model does not scale as much as the proprietary one.
  • Legal mess: Usually, proprietary products step on Open Source ones to speed up the development time. This technique is used primarily in Start-Ups or consulting companies. However, this approach has its problems. What happens in a similar case such as log4j, where a security hole or a bug in one of your Open Source components leads to data leaks or financial losses? Who is responsible? By default, this is the user of the component, aka you.

In conclusion, Open Source is not for everyone. It could be more secure or with better support, but only if the code comes from a reputable software vendor. In all other cases, the user is left on its own to handle their security and support. Another question is whether the alternative (using only proprietary software) is better, but I will analyze this in another article.

Legal pitfails for Start-Ups – part 2

November 27, 2021 /

In the last part discussed the difference between an idea and a patent and how the proper judgment of whether something is in breach of the intellectual property is a gray area. Additionally, we spent some time analyzing the way software companies make an idea to product. We pointed out that all companies usually use already established algorithms and design patterns free of copyright. In this part, we shall discuss some techniques and pain points Start-Up founders must be aware of.

First – this advice is more oriented towards every entrepreneur – please make sure you hire a good lawyer before you do a single step of your Start-Up journey. And by good, I mean a lawyer with good work etiquette and a moral compass between wrong and right. Additional experience in the field is a bonus, but it must not be the main reason you start working with someone. Additionally, a skilled lawyer can help you set up your company in a way, which can save you many troubles in the future.

Second – make sure that you have at least one technical person with legal knowledge. This person will work closely with your lawyer when you have to make a legal decision regarding your technical product and will clear technical details regarding your contract templates, customer complaints, and, in the worst case, if someone decides to attack your organization legally. Ideally, this person must be part of your founding team but not hired.

On the diagram you can see a standard legal contract workflow. After the initial contract you have actions and finally the contract must end with one of the exits

Third – be paranoid. Contracts are invented for both sides to have the worst-case scenarios covered. And by that, we mean the worst-case scenarios indeed. Some examples are death, theft of intellectual property, not honoring the deal from one of the sides, etc. I can give you some tips: make sure you have every exit situation covered; the contract must have a period and if there is a penalty rule, make sure that there is an upper limit for it.

Fourth – make sure you don’t make enemies. A significant percent of legal arguments are because of personal reasons. The most common cause is that someone’s ego is hurt so much that this same person decides to take legal action. From a business perspective, usually, the main reason is that one of the sides chose not to honor their deal and pay some money. Sometimes the cheating side could even fabricate a whole story to get away from court action.

In conclusion, please make sure you treat your customers, partners, and employees well. Not honoring a deal must be triggered only by terrible reasons, which are out of your control. It is the only way your reputation will stay intact, and you will not make yourself a bad name. From my experience, I can give you an example where not honoring the initial deal led to the company losing all of its technical team and a delay of at least two years. Eventually, the company bankrupted.

Legal pitfails for Start-Ups – part 1

November 20, 2021 /

During the years, I have seen many Start-Up team members lacking the necessary legal knowledge to make effective decisions about what is wrong and what is not wrong to do when working in that field. Many company owners have a too dark and or too light perception regarding the legal requirements when building a new technology-based company. At the same time even more significant number of company owners directly ignore some laws or try bending them to their benefit. As always, the truth is in the middle, and reality is more grayish. 

But let’s start with a simple example regarding copyright laws. I am amazed how many people in technology still neglect them and even have no idea how they work. So let’s give them a ride. In their essence, these laws state the following:

On the diagram you can see a standard diagram included in patent papers. It is On the diagram, you can see a standard chart included in patent papers. This diagram is too general, and systems such as computers, smartphones, etc., could be categorized as devices implementing it
  • Ideas: Ideas are free from copyright. However, here come two questions regarding that statement. First – how do we distinguish an idea from something else? We usually use already established design patterns and algorithms in technology and try to model our ideas using these tools. So, in short, the standard approach of making your concept alive is to use something someone has already invented, but it is not under copyright. Second – having in mind the last sentence, where is the line between an idea and something which must be under copyright? Should we claim the collection of algorithms and design patterns needed for one idea’s implementation to be under copyright?
  • Patents: For anyone reading patent papers, patents describe the design patterns and logic implementing the idea defended by the patent. At the same time, we could ask the following questions: What happens if we change one of the boxes used in the patent and implement it another way, but not the one described in the patent? Will this invalidate the patent? Will this be enough legally to claim that our Start-Up does not use the patent?
  • Programming code: By default, every programming code is under copyright. The idea of this setup is to defend the employer legally. However, there are some exceptions for that – what happens if the employee is an outsourcing company or freelancer? What happens if the employee uses a code or skills acquired before starting working with the employer? What happens if the employer has permitted the employee to operate its own company and projects in the same industry? What happens if there was a verbal agreement for partnership between the employer and the employee, but the employer decides not to honor the deal?

In conclusion, the answer to these questions usually is – It depends. Every situation is different, and that’s the reason we have courts for making decisions. Laws typically try following the community’s moral compass; unfortunately, this is not always possible. It is a good idea for us as entrepreneurs to be prepared for any situation using that knowledge. And the list of bad situations includes legal, financial problems, and even personal vendetta from ex-partners and ex-employers. People change with age, and sometimes these changes are for the better, which is why contracts were invented.