Site Tools


introduction:oss

...of open source...

Open source software (OSS), that means “free software”, right?

Well, yes… but the word “free” can mean (at least) three different things:

  1. The source code has the freedom to move and to be shared with anyone. It cannot be restricted (this also applies to derivative work)
  2. Anyone is free to use the source code however they like.
  3. The source code is free as in “free beer”

License Issues

The difference between the first two bullets is fundamental to the understanding of the two main directions of open source, and the ongoing discourse on which direction is “more free”.

The first (source code is free) is most prominently advocated by the Free Software Foundation and GNU Project, and commonly known as “copy-left”, “protective”, or “viral”. The fundamental view is, that the source code must remain free (libre), and once it has been set free, it can never be restricted – not even through derivative work, which must be re-published under the same license terms. The focus is thus on the rights of the end-user of the software application based on the original source code – he or she must be allowed full access “behind the scenes” to inspect and modify the software. Popular licenses include the GNU GPL family and the Creative Commons Share-alike family.

The second bullet (user of the source code is free) has the main focus on the rights of the software developer using the source code to create derivative works. The Apache Software Foundation is one of the best known advocates of this point-of-view. When source code is shared under these terms, the software developer is free to make closed/proprietary products based on the original source code. In most cases, the new product must credit the authors of the original source code (e.g. in the documentation), but apart from that there are no restrictions. These terms are often referred to as “permissive”. Popular licenses include the MIT, BSD, Apache, and Creative Commons Attribution license families.

Which of the two types is more “free”, then? That clearly depends on what you seek to accomplish – and probably also your political or philosophical standpoint.

The main problem with all these different types of licenses are compatibility! Some copy-left license terms require that the same license must apply to derivative work and that no additional restrictions may be added to this derivative work. This makes these license terms incompatible with other license terms which add different restrictions. Hence, due to legal subtleties, open source components with different licenses cannot always be combined, as illustrated by the figure below.

Compatibility of common open-source software licenses. By David A. Wheeler. License: CC BY-SA

In the choice between “permissive” and “copy-left”, 4S has chosen the permissive side. It is not the ambition of 4S to enforce open source license terms on all who choose to use 4S modules – on the contrary, 4S welcomes community members, who can make a profit from building proprietary software based on 4S source code. In particular, 4S has chosen the Apache 2.0 license for source code and the Creative Commons Attribution 4.0 International license for documentation. The Apache 2.0 license is widely regarded as one of the most modern permissive licenses, and it was the natural choice as it is already used in many of the libraries, 4S software is currently used together with.

Cost and Business Models

In general, open source code has the third (free beer) property of the list above. However, this does not mean that there will be no cost of using the software! There are many types of cost involved in using open source software:

  1. The cost of initial development.
  2. The cost of documentation.
  3. The cost of transforming the source code (which is basically a bunch of text files) to a software application that the end-users can install and use.
  4. The cost of testing the application.
  5. The cost of assisting / supporting the end-users.
  6. The cost of monitoring the use of the software and discovering security or usability problems.
  7. The cost of fixing these problems and repeating all of the bullets above for a new version of the application.
  8. The cost of adapting and testing the application on new platforms (hardware and/or operating system versions) and repeating all of the bullets above for a new version of the application.
  9. The cost of developing new features and repeating all of the bullets above for a new version of the application.
  10. The source code may be implementing functions covered by software patents, which means that license fees to the owners of these patents are required to legally use the software.
  11. In some cases and jurisdictions, the software provider may be liable for damages caused by software problems, which means that some kind of product liability insurance may be necessary.

All these costs of using the software still need to be covered, and of course the business model has to be different to do this, than the business model of producing ordinary proprietary software,

The initial development of traditional proprietary software (entailing at least the first 4 items of the list above) is usually paid by an investor. When it is complete, and software licenses are sold to paying customers, part of the income goes to finance the maintenance of the code (the remaining items) and a part goes to pay the investor back (with interests).

This model will not work, if the source code is released as open source, as everyone else can just take the source code, pay the costs associated with items 3, 5 and 10–11 (and optionally 6–9 if they feel like it), and then sell essentially the same software for a fraction of the unit-price offered by the original company.

We need different business models to cover:

  • Initial development (items 1,2,4) and further development (item 9)
  • Maintenance (items 6,7,8)
  • Deployment (items 3,5,10,11)

One way to finance initial and further development could be a “potluck dinner” model, where different sponsors make it their responsibility to finance the development of a single module. Maintenance and deployment costs could still be covered by a per-unit license fee to a company who takes charge of maintenance and deployment (the license fee would then of course be lower than the license fee of a similar proprietary system). This model is not completely uncomplicated, though, due to the inherent conflict between items 1/9 and 7.

In summary, for large organisations who need many copies of a piece of software, choosing an open-source-software-based system has several advantages: first of all, there should be a significant saving per copy; secondly, as the source code is open, many different companies can help with customisation / adaptation (more competition and lower price); and thirdly, there is no dependency on a single proprietary software vendor. On the other hand, it is (much) more expensive to get started, due to the need for sponsors of the initial development. However, for large organisations, the savings on licenses should justify the extra cost of sponsoring one or more modules.

Learn More

introduction/oss.txt · Last modified: 2018/12/12 13:27 (external edit)