eMail sent.
Answers to your questions can be found within the text below:
For one of our projects, we would like to use the FIWARE NGSI v2
specification. We rather not use the Orion context broker because it is
licensed with an AGPL-3.0 license, this means that it is for us no option
to integrate it in our current systems that are commercially used, and by
using the Orion context broker we would be forced to open source our code.
As you know, the AGPL license is a copy-left license, but the virality of the license is usually exaggerated:
https://softwareengineering.stackexchange.com/questions/107883/agpl-what-you-can-do-and-what-you-cant
https://opensource.com/article/17/1/providing-corresponding-source-agplv3-license
https://opensource.org/licenses/agpl-3.0
You are able to use/link to the Orion Context broker “as-is” (i.e. as a micro service) without open sourcing
Your codebase, what the license prohibits is modification of the Orion code and then subsequently claiming
commercial ownership of that component, in that respect the context broker service is no different to many other open source
Components used in commercial offering - a typical example would be the Mongo-DB database which used to be offered
Under AGPL if I remember correctly.
We want to be very clear that an AGPL-3.0 license is not applicable for us,
because we lend our projects to third parties, and by open sourcing our
code we lose our business
Obviously this is seen as a barrier for adoption for some commercial companies, the Orion repository attempts to lay these doubts
To rest with the following disclaimer: https://github.com/telefonicaid/fiware-orion#license
If you check the following, you will see that commercial use is permitted:
https://choosealicense.com/licenses/agpl-3.0/
I believe the conditions of “disclose source, same license etc, apply to the component, not your stuff, but obviously you should
Consult a proper legal representative to be certain. Note that the FIWARE Foundation does not own the source code behind the
Various Generic Enablers, all components are contributed open source by the various development teams.
Therefore we would like to implement the NGSI v2 specification ourselves.
We have now some questions we would like to ask you:
Is it allowed to implement the FIWARE-NGSI v2 specification for commercial
purposes when we implement it ourselves?
The NGSIv2 specification is available under MIT, from https://github.com/FIWARE/specifications
The NGSI-LD specification is an ETSI Standard: https://www.etsi.org/deliver/etsi_gs/CIM/001_099/009/01.01.01_60/gs_CIM009v010101p.pdf
There are some projects available which are already using the “writing from scratch idea,
Here is a simple example (WIP): https://github.com/sensinov/djane
Can we state that we implemented the FIWARE-NGSI v2 specification in our
commercial projects?
If a product is using the NGSI interfaces intelligently it can apply to be listed as Powered-by-FIWARE
And devices can be described as FIWARE Ready - see https://marketplace.fiware.org/ on how to apply.
Use of the common data models is highly encouraged, and contributions for additional fields and entities are most welcome
https://github.com/FIWARE/dataModels (the repository will be moving soon, as it is a join effort across multiple standards
Organisations - effectively this is just the FIWARE branded one for now)
If you are looking at creating your own context broker, promotion of the NGSI interface and FIWARE technologies
Is what the FIWARE Foundation is all about - we’re not a software house. There are actually initiatives for additional Context Brokers in place, as well as
Alternative options for some of the Generic Enablers - promotion of FIWARE technologies doesn’t mean picking favourites, it means promoting the
Standard. Note that the Generic Enablers in the catalogue have agreed to abide by an additional set of rules, there are many other FIWARE-based
Technologies which are either commercial (non open source) or open source but follow their own rule set.
https://www.fiware.org/foundation/
https://fiware-requirements.readthedocs.io/en/latest/
To create a fully functioning NGSI-LD interface, you can run the test suite shown below:
https://github.com/FIWARE/NGSI-LD_TestSuite
It is kind of like an ACID test - I don’t think any implementation I know of is fully compliant
With all edge cases, and it can be used as a benchmark of maturity.
Can we contribute to the FIWARE-NGSI v2 specification, with new features?
I believe that NGSI v2 is fixed, but NGSI-LD is still a work on progress.
The Orion Context broker is the Generic Enabler showcasing the standard, and any suggestions
on improvements/changes should probably start with raising an issue to start a discussion there:
https://github.com/telefonicaid/fiware-orion
In some cases you may not get changes directly into the broker, but could discuss architecturally the best way forward.
In others it should merely be a matter of ensuring a common approach for interfaces as they are added.
For example I have recently discovered a tool for massive batch processing of entities which is an additional
Plug-in and not part of the broker. There are other initiatives which are part of the roadmap such as a websocket interface.
I hope this has clarified your doubts and offered a potential way forward for you.
eMail sent.
Answers to your questions can be found within the text below:
For one of our projects, we would like to use the FIWARE NGSI v2
specification. We rather not use the Orion context broker because it is
licensed with an AGPL-3.0 license, this means that it is for us no option
to integrate it in our current systems that are commercially used, and by
using the Orion context broker we would be forced to open source our code.
As you know, the AGPL license is a copy-left license, but the virality of the license is usually exaggerated:
https://softwareengineering.stackexchange.com/questions/107883/agpl-what-you-can-do-and-what-you-cant
https://opensource.com/article/17/1/providing-corresponding-source-agplv3-license
https://opensource.org/licenses/agpl-3.0
You are able to use/link to the Orion Context broker “as-is” (i.e. as a micro service) without open sourcing
Your codebase, what the license prohibits is modification of the Orion code and then subsequently claiming
commercial ownership of that component, in that respect the context broker service is no different to many other open source
Components used in commercial offering - a typical example would be the Mongo-DB database which used to be offered
Under AGPL if I remember correctly.
We want to be very clear that an AGPL-3.0 license is not applicable for us,
because we lend our projects to third parties, and by open sourcing our
code we lose our business
Obviously this is seen as a barrier for adoption for some commercial companies, the Orion repository attempts to lay these doubts
To rest with the following disclaimer: https://github.com/telefonicaid/fiware-orion#license
If you check the following, you will see that commercial use is permitted:
https://choosealicense.com/licenses/agpl-3.0/
I believe the conditions of “disclose source, same license etc, apply to the component, not your stuff, but obviously you should
Consult a proper legal representative to be certain. Note that the FIWARE Foundation does not own the source code behind the
Various Generic Enablers, all components are contributed open source by the various development teams.
Therefore we would like to implement the NGSI v2 specification ourselves.
We have now some questions we would like to ask you:
Is it allowed to implement the FIWARE-NGSI v2 specification for commercial
purposes when we implement it ourselves?
The NGSIv2 specification is available under MIT, from https://github.com/FIWARE/specifications
The NGSI-LD specification is an ETSI Standard: https://www.etsi.org/deliver/etsi_gs/CIM/001_099/009/01.01.01_60/gs_CIM009v010101p.pdf
There are some projects available which are already using the “writing from scratch idea,
Here is a simple example (WIP): https://github.com/sensinov/djane
Can we state that we implemented the FIWARE-NGSI v2 specification in our
commercial projects?
If a product is using the NGSI interfaces intelligently it can apply to be listed as Powered-by-FIWARE
And devices can be described as FIWARE Ready - see https://marketplace.fiware.org/ on how to apply.
Use of the common data models is highly encouraged, and contributions for additional fields and entities are most welcome
https://github.com/FIWARE/dataModels (the repository will be moving soon, as it is a join effort across multiple standards
Organisations - effectively this is just the FIWARE branded one for now)
If you are looking at creating your own context broker, promotion of the NGSI interface and FIWARE technologies
Is what the FIWARE Foundation is all about - we’re not a software house. There are actually initiatives for additional Context Brokers in place, as well as
Alternative options for some of the Generic Enablers - promotion of FIWARE technologies doesn’t mean picking favourites, it means promoting the
Standard. Note that the Generic Enablers in the catalogue have agreed to abide by an additional set of rules, there are many other FIWARE-based
Technologies which are either commercial (non open source) or open source but follow their own rule set.
https://www.fiware.org/foundation/
https://fiware-requirements.readthedocs.io/en/latest/
To create a fully functioning NGSI-LD interface, you can run the test suite shown below:
https://github.com/FIWARE/NGSI-LD_TestSuite
It is kind of like an ACID test - I don’t think any implementation I know of is fully compliant
With all edge cases, and it can be used as a benchmark of maturity.
Can we contribute to the FIWARE-NGSI v2 specification, with new features?
I believe that NGSI v2 is fixed, but NGSI-LD is still a work on progress.
The Orion Context broker is the Generic Enabler showcasing the standard, and any suggestions
on improvements/changes should probably start with raising an issue to start a discussion there:
https://github.com/telefonicaid/fiware-orion
In some cases you may not get changes directly into the broker, but could discuss architecturally the best way forward.
In others it should merely be a matter of ensuring a common approach for interfaces as they are added.
For example I have recently discovered a tool for massive batch processing of entities which is an additional
Plug-in and not part of the broker. There are other initiatives which are part of the roadmap such as a websocket interface.
I hope this has clarified your doubts and offered a potential way forward for you.