Hi,
>From Telefónica side, we don’t plan at the present moment to do any privative development of our software in FIWARE.
However, having said that, we don’t agree in including a clause like the one you are discussing. Note the IPR owner is already granting rights for using, copying, modifying and redistribute the software with the open source license. That is in fact very generous. Going beyond that point, limiting IPR owner rights with a clause like that, will be unfair for the owner and contrary to the praxis in open source projects. In fact, we don’t know any widely used, well-known project or community using a clause like the one you want to introduce.
I think this point of view is similar to the one already expressed by NEC, Engineering and Martel. Please, take this feedback into account in any discussion about this topic.
Best regards,
------
Fermín
El 05/10/2018 a las 11:08, Portosa Alessandro escribió:
Hi,
thanks, Josè to raise this up again. Let me be clear: Knowage is AGPL licensed, and not by mistake. From a company perspective, it is really difficult to accept to be forced to change this because of a possible "unfair" behaviour. Furthermore, let me say that the "fairness" is a very subjective concept. Again, from a company perspective, giving all its work for free to the community but keeping the right to handle the software internally how it prefer, could be fair. Let me stress again that even if you keep saying that this does not impact the license, I would say it is.
What can be done with a piece of software, should be bound by its license. Nothing more. Nothing less. That's my vision.
Cheers,
Alessandro Portosa
Technical Consultant
[X][1513603850060_logotipo_knowage_150px.png]
Knowage Labs
Engineering Group
Via G. Marconi, 10 - 40131 Bologna - Italy
Tel. + 39 051 0435090
Skype alessandro.portosa
www.knowage-suite.com<http://www.knowage-suite.com/> - www.eng.it<http://www.eng.it/web/eng_en/home>
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
________________________________
Da: fiware-technical-committee-bounces at lists.fiware.org<mailto:fiware-technical-committee-bounces at lists.fiware.org> <fiware-technical-committee-bounces at lists.fiware.org><mailto:fiware-technical-committee-bounces at lists.fiware.org> per conto di Federico Michele Facca <federico.facca at martel-innovate.com><mailto:federico.facca at martel-innovate.com>
Inviato: venerdì 5 ottobre 2018 10:15
A: José Manuel Cantera
Cc: fiware-technical-committee at lists.fiware.org<mailto:fiware-technical-committee at lists.fiware.org>
Oggetto: Re: [Fiware-technical-committee] Controversial point regarding requirements on contribution management policies with respect to FIWARE GEs
Hi,
We don’t use GPL or AGPL so, I am fine with that. We should check at least with who is now using such licenses (e.g. TID) to understand if they are fine with that,
or we are going to loose key pieces of software.
In general I agree Jose, probably we should open up the discussion to the wide public. It could be good to ask for the review of the guidelines by the community.
e.g. we give them 2 weeks time, if no comments it stays what TSC decided.
Federico
On 5 Oct 2018, at 08:37, José Manuel Cantera <josemanuel.cantera at fiware.org<mailto:josemanuel.cantera at fiware.org>> wrote:
Dear Juanjo,
Just my two cents here, as an individual member of the FIWARE Community.
Do we really need such lenghty disclaimers? Are mature open source communities using similar statements?
Nonetheless, the important opinion is the opinion of people who are actually code owners and developers of FIWARE, the companies. Please it is important to hear your voice!
Thanks,
Best
On 1 Oct 2018, at 02:12, Juanjo Hierro <juanjose.hierro at fiware.org<mailto:juanjose.hierro at fiware.org>> wrote:
Dear all,
As promised, even though later than planned, here you have a message where I try to elaborate on the controversial point we started to discuss during our last TSC regarding requirements on contribution management policies for products contributed as FIWARE GEs.
@Federico: please read this mail carefully since the controversial issue under discussion has to do a lot with concerns raised by you at the FIWARE Roadmap meeting in July.
Apologies for the long mail, but these things are not trivial.
Let me first bring a bit of introduction on some fundamental background. Apologies to those who already know and understand about this stuff very well, but I hope it will be valuable for others who may not be so experts.
In those open source project that aims at managing contribution from third parties, there is a legal document besides the open source license that is rather relevant. That is usually referred as the "Individual Contribution License Agreement". Such legal document governs, among other things, how the IPR of software being contributed by parties to the open source code of the project will be managed. As an example, within the Apache open source community, there are two documents which each project adopts:
* The Apache 2.0 open source license<https://www.apache.org/licenses/LICENSE-2.0>
* The Apache Individual Contribution License Agreement (ICLA) v2.0
<https://www.apache.org/licenses/icla.pdf>
This are TOTALLY different documents which govern totally different things. This to the extend that there may be many open source projects who adopt the Apache 2.0 open source license but not the Apache ICLA (nor even an adaption to it replacing references to the "Apache Foundation" by references to whatever organization).
Note that both documents should also exist in open source projects which may have different open source licenses than Apache, but still wish to make it clear to third parties how contributions will be managed.
Now, coming to our case, we are in a process where we want to establish what are the requirements that we want to impose to any project/product which a given organization pretends to contribute to FIWARE and be labeled as FIWARE GE.
We long time ago agreed that we couldn't impose a single open source license (if it were one, probably had to be Apache 2.0). We agreed that this may become a barrier for contribution because organizations willing to contribute may be willing to do so under certain circumstances not necessarily covered by the Apache 2.0 open source license. Fair enough and, as far as I know, this is the position that certain organizations like the Linux Foundation seem to adopt.
The only requirements (all MUST requirements) we are proposing with regarding open source license, were that:
* The source code of the product MUST be licensed under one of the well-recognized open source licenses approved by the Open Source Initiative<https://opensource.org/licenses/alphabetical>.
* The source code open source license MUST be mentioned in a relevant section within the README.md file of the project on GitHub
* In the case of projects licensing the code under a copyleft open source license (e.g., GNU GPL 3.0 or GNU Affero GPL 3.0) a statement like the following MUST be added in the same section:
* Please note that software derived as a result of modifying the source code of the <name-of-product> software in order to fix a bug or incorporate enhancements IS considered a derivative work of the product. Software that merely uses or aggregates (i.e. links to) an otherwise unmodified version of existing software IS NOT considered a derivative work.
So far, so good, but the above doesn't govern anything regarding how contributions to the source code should be managed. Only what are the requirements regarding licensing of the source code.
Now, regarding requirements we are proposing regarding "Individual Contribution Management Policty", we had agreed that the following requirements MUST be met:
* Contributions from third parties MUST be accepted.
* There MUST be a document (that would be the equivalent to the Apache 2.0 ICLA) clearly describing the terms under which the IPR of contributions to the source code of the product will be managed.
* Such document should be made accessible in a relevant section in the README.md file of the project on GitHub
And with regard to the document for the management of contributions (the ICLA-like document) we have agreed that the following requirement MUST be met:
* There isshould be at least one organization which can exercise IPRs on the whole software. It is acceptable that such organization is the original contributor (aka “Owner”).
* There shall be a commitment to transfer to the FIWARE Foundation the IPRs on the whole software in case that the software is not longer supported by the organization(s) that currently own(s) IPR on the whole software.
Again, so far, so good. But then some of you (Federico) raised an interesting issue for the specif case of products licensed under GNU Affero GPL:
* the original owner of the product, precisely because it will own IPRs for the whole product, can keep an internal copy of the whole software which it may distribute under licenses other than GNU Affero GPL.
* the original owner of the product would, therefore, the only one that would be able to perform changes in the software (the internal copy not attached to the GNU Affero GPL) without sharing those changes with others. Rest of the universe got only a copy of the software licensed under GNU Affero GPL and therefore are bound by its rules: if they implement a change in the software, they have to publish them to the whole Community (and hence, the original owner). The original owner can implement changes without sharing those changes because essentially he also got a copy of the software which is not necesarily licensed under GNU Affero GPL.
I pretended to solve this strange (but feasible) "unfair" behavior by means of asking the FIWARE GE owner who is contributing software released under a copyleft open source license to incorporate clauses in its ICLA stating that it commits to make publicly available on the GitHub repo(s) associated to the product all changes developed on the product, i.e., they won't develop nor retain any changes in a private version of the software. I want to insist that such clause wouldn't go into, nor refer to, the open source license under which the software is released. It would be a clause for the ICLA.
Based on the discussion in our latest TSC, it seems like some people is confusing the way GNU Affero GPL works (or any other copyleft open source license) and the clauses which we may require to be added on the ICLA-like document governing how IPR of contributions are managed (from third parties as well as the original owner). These are totally different (although related, of course).
Note that we are not impeding that a given contributor releases software under GNU Affero GPL and develops "enterprise editions" of that software adding, as plug-ins, added-value features. Why? because those plug-ins would not be considered derivate work of the core part of the software (differently would be the part of the software, which would be core, which brings support to creation of plug-ins).
With such requirement (to be followed by owners who are releasing software under a copyleft open source license) we achieve the following fair balance:
* If the software is licensed under an Apache-like license, then the clause will not be required. Everyone (contributors as well as the original owner) would be able to develop derivate work they don't share. Fair enough.
* if the software is licensed under a copyleft license, then the clause will be required. Everyone (contributors as well as the original owner) should share whatever derivate work (defined as previously, i.e., plug-ins would not be considered derivate work).
I hope this clarifies the rationale behind the clause that has been proposed and we can conduct a fruitful discussion.
Cheers,
Juanjo Hierro
Chief Technology Officer
juanjose.hierro at fiware.org<mailto:juanjose.hierro at fiware.org>
www.linkedin.com/in/jhierro<https://www.linkedin.com/in/jhierro>
Twitter: @fiware<https://twitter.com/fiware> @JuanjoHierro<https://twitter.com/JuanjoHierro>
<pemigncpdbphiahk.png>
__________________________________________________________________________________________
You can get more information about our cookies and privacy policies on the following links:
- http://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE_Privacy_Policy
- http://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/Cookies_Policy_FIWARE
Fiware-technical-committee mailing list
Fiware-technical-committee at lists.fiware.org<mailto:Fiware-technical-committee at lists.fiware.org>
https://lists.fiware.org/listinfo/fiware-technical-committee
__________________________________________________________________________________________
You can get more information about our cookies and privacy policies on the following links:
- http://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE_Privacy_Policy
- http://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/Cookies_Policy_FIWARE
Fiware-technical-committee mailing list
Fiware-technical-committee at lists.fiware.org<mailto:Fiware-technical-committee at lists.fiware.org>
https://lists.fiware.org/listinfo/fiware-technical-committee
Dr. FEDERICO MICHELE FACCA
Head of Martel Lab
0041 78 807 58 38
Martel Innovate<https://www.martel-innovate.com> - Professional support for innovation projects
Click to download our innovators' insights!<https://www.martel-innovate.com/premium-content/>
Follow Us on Twitter<https://twitter.com/Martel_Innovate>
__________________________________________________________________________________________
You can get more information about our cookies and privacy policies on the following links:
- http://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE_Privacy_Policy
- http://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/Cookies_Policy_FIWARE
Fiware-technical-committee mailing list
Fiware-technical-committee at lists.fiware.org<mailto:Fiware-technical-committee at lists.fiware.org>
https://lists.fiware.org/listinfo/fiware-technical-committee
________________________________
Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.
Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-technical-committee/attachments/20181011/6410eceb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-1513603850.png
Type: image/png
Size: 3338 bytes
Desc: Outlook-1513603850.png
URL: <https://lists.fiware.org/private/fiware-technical-committee/attachments/20181011/6410eceb/attachment-0001.png>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy