Category Archives: Generic Enabler

FIWARE Belgium Meetup. Join the Open Source Tech discussion

Join the next FIWARE BELGIUM devops meeting to discuss this edition's topic with Joaquin Cabezas, a representative of the FIWARE association. He will talk about the pitfalls and opportunities when choosing a platform to develop on.

The FIWARE devops meetups offer a sounding board and opportunity to meet other FIWARE developers. Please feel free to volunteer to present your project, product and services to the participants!

Date: 13.01.2016
Place: iMinds-SMIT-VUV, Pleinlaan 9, Elsene (Brussels)

Registration Link

Licenses on FIWARE – Terra Incognita

Beside functionality, quality and documentation the license is one of the most important point of using open source code in commercial products.

It's important to know, if and how the license of a FIWARE Generic Enabler has effects on the overall solutions stack of your work.

So let's have a look on the licenses of Generic Enablers

In the FIWARE Association we did a brief look on the licenses described in the Generic Enabler Catalogue and add them to a map of the FIWARE Architecture Specification. This should help to visualize todays license situation and to get a feeling on the terra incognita (the FIWARE reference architecture map does not match 100% to the names of the GE in the catalogue – we did our best to identify the catalogue GE's. Just let us know if we missed a GE.)

FIWARE Generic Enabler License Map

First the good news:

All Generic Enablers available in the FIWARE Catalogue are published under OSI approved Open Source Licenses. If you use FIWARE Generic Enablers from the catalogue you can be sure that your GE is based upon an OSI approved real open source license.

9 different Open Source Licenses in the FIWARE GE Stack

But what else we see: Generic Enablers in the FIWARE Catalogue are published with different open source licenses. We count at least 9 different license types on the review. Including a broad range of license with strong copyleft effect as GPL and permissive license as MIT.

GPL and MIT for example are OSI approved open source licenses – but they are build on complete different philosophy regarding the freedom of commercialization. GPL has a very strong copyleft – and it's not made for selling code based upon classical proprietary vendor revenue models. On GPL vendors business model has to be charging distribution fees or additional service around the product. The product it self cannot charged by license fees. In opposite the MIT is more vendor friendly: it does not force your overall product to run under open source by copyleft and it allows to use code within a classical proprietary software solution.

On complex open source projects it's not unusual that you can't avoid to build the solution by using code published on different licenses. But at all developers and maintainers should be very careful by mixing too many open source licenses. Adding different licenses to the stack is increasing complexity of how the different licenses are affecting the legal frame of the overall product build upon the software stack.

Managing licenses in open source stacks is a main task

Having 9 different licenses over a set of 40 Generic Enables is increasing the legal complexity on how to use FIWARE by commercial products. Additional on the copyleft licenses we also have to deal with different versions of GPL, GPL v2, GPL v3, LGPL and AGPL. Why? It obviously looks likes a missing task of managing the license model of FIWARE in detail.

One of the most important goals must be to simplify the license map and to install a license management.  Companies and FIWARE users are in need of an easy to use legal frame to build successful commercial products and services.





Keep it simple

Developers like open source when the solution makes their life easier. They turn away if it’s more complex than their daily challenges.

Also the maintainer of an open source community project is in need to avoid complexity.

Because simplicity will lead into a manageable environment:

  • Easy to keep documentation on track
  • Less efforts on providing updates and upgrades
  • Less risk to lose sight of vulnerabilities on code reviews
  • Clear legal fundament with transparent license policies

If we look on FIWARE to today, the eco system needs improvements to attract developers and to provide a maintainable eco system.

Keep is simple will be good guideline go into a reliable future.

But it also takes some painful actions:

  • Remove all parts from FIWARE which are not useful for the core solution (btw. What’s the core solution? Internet of Things, Smart Cities, Rich Media or 3D User Interfaces? State today it sounds like a solution for everything – which is not helpful to attract developers)
  • Reduce Code to a common Open Source License model (instead mixing at least 9 different licenses under one core)
  • Bring the GE’s to common Linux based distribution (force maintainer to adept on a common distribution base)
  • Rebuild the documentation (it will be less documentation than today, more easier to maintain)

It sounds easy, but avoiding complexity on an open source eco system is a never-ending task. State today this is not a question of money. It’s a question of willing ness of courageous actions.