dear juanjo, ckarifing what i said in the other thread, thsi license you are now proposing is in line with my idea of having the foundation full grants on the contributions. so i migth agree on this. however, the both points 6 are not accepltable as they are now for us, given the principles we stated in the current gm of the community and expressed in many occasions in public events. we indeed ask for a perpetual support to the give contribution. if this does not happen in the rigth forms (we have to clarify the slas about this) either the contribution and eventually the whole ge will be deprecated unless somebody else in the community will take care of it. ciao, stefano 2016-09-16 9:46 GMT+02:00 Juanjo Hierro <juanjose.hierro at telefonica.com>: > Dear all, > > For consideration in our discussion, I provide the link to the ICLA of > the OpenStack Foundation: > > https://review.openstack.org/static/cla.html > > It may be even a more valuable reference than Apache's > > Best regards, > > -- Juanjo > > On 31/08/16 08:26, Juanjo Hierro wrote: > > Dear all, > > I'll try to summarize the issue that exists regarding the ICLA > (Individual Contribution License Agreement) so that we can take an informed > decision. > > The issue doesn't have to do with any particular element of its current > wording. As far as I understand, the wording of the ICLA comes from the > ICLA produced by the well-known and established Apache Foundation, > therefore it is proven to work well and has not legal fissures. > > As you will see below, the issue have to do with whom Individual > Contributors grant licenses on their contributions. An analysis of the > different options is given so we can take a decision. > > A last matter regarding the need to analyze the compatibility of the > adopted ICLA (or ICLA template) with the different open source licenses > that exist and may be used for FIWARE GEris is also provided. > > > 1. Background Info 1.a Why ICLAs are needed in open source projects > > Probably the major reason why ICLAs are needed in open source projects > is to make sure that there is an entity that owns a license in all the IPRs > associated to the software of that project and therefore can take decisions > that affect the whole. > > As an example, it might be desirable to change the open source license > with which the source code of the project is released from say it "GNU > Affero GPL v3" to "Apache 2.0" or from "GNU GPL v3" to "GNU LGPL v3". > Such change can only be implemented if some entity owns a license on the > IPRs on the entire source code. If the open source project is a project > that has allowed contributions from many individuals, and this hadn't been > taken into account, you would need to bring together all those individual > contributors and make a unanimous decision. This might be rather difficult > because projects evolve over time and links to some of these contributors > may have been lost or they simply don't respond. Nothing to say if someone > disagrees, things may become unmanageable. > > There might be other decisions that affect the whole and requires the > existence of such single entity that eases taking decisions. Ability to > easily act/represent contributors in legal disputes, for example. > > In open source communities like Apache, this issue is solved because > every contributor has to sign an ICLA that establishes that the Apache > Foundation is given license on all IPRs. This way, the Apache Foundation > becomes the entity that may take these kind of decisions that affect the > whole of the source code in a given Apache project. > > > 1.b Where components in FIWARE come from > > One important matter that needs to be taken into account is that open > source products contributed to FIWARE as open source reference > implementations of FIWARE Generic Enablers, from now on "FIWARE GEri(s)" > for short, have not been developed from the scratch in the context of the > projects funded by the EU within the Future Internet PPP and concretely the > FI-WARE or FI-Core projects. FIWARE GEris typically come as the result of > the contribution of products that given partners already owned and > developed before any of those projects started. They have contributed > those products to FIWARE as FIWARE GEri and agreed to evolve them in that > context, but not only subject to FIWARE overall needs. Indeed, many > FIWARE GEri products are meaningful on their own, i.e. separated from rest > of FIWARE GEris. They could "survive" as meaningful open source projects > even if FIWARE dissapears as an initiative. > > As an example, one of the FIWARE GEris is SpagoBI which was a product > that has been developed by Engineering since many years and contributed to > FIWARE at a given point in time. Another good example of FIWARE GEri is > Kurento, which was a product developed as open source by a number of > organizations (Adevice and URJC) and contributed as FIWARE component when > those organizations joined the FIWARE initiative. > > This means that each of the FIWARE GEris has what is typically referred > as the FIWARE GEri "owner". > > > 1.c Current approach in FIWARE regarding Open Source License of the > different FIWARE GEris > > To make things a bit more diverse, multiple open source licenses are > allowed regarding each of the adopted FIWARE GEris. The rationale behind > this was to lower the barriers of contribution of products as FIWARE > GEris. > > In essence, any open source license is allowed provided it is one of the > open source licenses listed as valid in https://opensource.org/ > licenses/category and provided the owner grants that such licenses do not > force application developers to release the software they develop as open > source. > > Depending on whether current FIWARE GEri owners are accepting > contributions from third parties or not, they have their own ICLA or not in > addition. I would say that most of them already have their own ICLA. > > > 2. Options regarding IPR licensing > 2.a IPRs are licensed to the FIWARE Foundation > > In this option IPRs are given to the FIWARE Foundation, so the FIWARE > Foundation becomes that legal entity (the only) which can take decisions on > the whole. End users welcome this because it is supposed that the FIWARE > Foundation will act for the benefit of all and not the concrete > benefit/interest of a given company when necessary. It also prevents > uncertain situations if the owner of a given FIWARE GEri disappears or > ceases their contribution but some decisions that affect the overall > product need to be taken. > > The FIWARE Foundation ICLA would need to be signed by the original > FIWARE GEri owner and each new third contributor. > > An issue with this approach is that some FIWARE GEri owners may be > reluctant to give away their IPRs, and overall adopt an ICLA that gives > IPRs of third contributions only to the FIWARE Foundation. This would > mean that, from the time at which the new ICLA applies and if new > contribution from third parties arrive, FIWARE GEri owners will see that > they will not longer own a license on IPRs over the whole product. It > would only be the FIWARE Foundation who own such a license. > > This option might not be necessarily welcomed by all FIWARE GEri > owners. Some of them may decide to no longer contribute their product as > FIWARE GEri and leave FIWARE. This could be a risk when we talk about some > core or interesting FIWARE GEris in FIWARE. > > One matter to take into account is that, for whatever reason, the FIWARE > Foundation may disappear in two years (let's face it, we could fail). > That would put FIWARE GEri owners in a difficult position if third party > contributions had been accepted in the meantime: they had lost a IPR > license over the whole software and the entity who could solve things has > disappeared. > > > 2.b IPRs are licensed to the original owner of each FIWARE GEri > > This is the complementary approach compared to the previous. > Essentially, you ask each and every FIWARE GEri to adopt an ICLA and make > it comply with a *template* you provide. > > You essentially rely on the fact that the FIWARE GEri owner will act as > that single entity that can act over the whole software and you trust it > would follow FIWARE Foundation advice and demands when necessary. > > FIWARE GEris owners would feel obviously comfortable with this approach > because they retain a license on the IPRs of the whole source code of the > product they originally contributed to FIWARE. > > Obviously, the risk is that FIWARE GEri owners disappear or discontinue > their activities without licensing their IPRs to an entity that can replace > them like the FIWARE Foundation could be. Development and support of the > FIWARE GEri may be warranted because there where enough number of third > contributors beyond the original owner who are still working on the source > code, but the issue is that no single entity owns license on IPRs of the > whole software product. > > The risk also exist if a given FIWARE GEri owner simply doesn't want to > adhere to some important decisions that majority of FIWARE Foundation > members wish to taken at overall FIWARE level (e.g., replace the open > source license of all FIWARE GEris to be Apache 2.0). > > > 2.c IPRs are licensed to both, the FIWARE Foundation and the original > owners of each FIWARE GEri > > This could be a mean to solve the risks of each of the previous > options. > > Same as with 2.b, given the fact that a explicit reference to the FIWARE > GEri owner has to be given in the ICLA that applies to each FIWARE GEri, we > would only be able to propose a *template* for the ICLA, to be adopted by > each of the FIWARE GEris. > > The FIWARE Foundation ICLA would need to be signed by the original > FIWARE GEri owner and each new third contributor. > > On the other hand, same as with 2.a, you are asking FIWARE GEri owners > to replace their existing ICLA if any ... let's cross fingers for none of > them is willing to negotiate the conditions of the new ICLA (although I > don't expect to much resistance given the fact that we are relying on > Apache's ICLA). > > > 2.d There are multiple ICLAs to be signed, one giving IPR licenses to the > FIWARE Foundation, allowing that each FIWARE GEri owner also require > additional ICLAs > > To be checked with attorneys whether it is feasible, we may establish > that two ICLAs may apply to each FIWARE GEri. The original ICLA that the > FIWARE GEri owner wishes to maintain and a new ICLA that licenses IPRs from > the original owner and third contributions to the FIWARE Foundation. > > It is a bit cumbersome because individual contributors would need to > sign twice each time they formalize a contribution ... but if attorneys > confirm this is feasible, it could be another option. Maybe an option > that could help negotiations with FIWARE GEri owners regarding acceptance > of a new ICLA: you are not asking them to replace the one they have (so > they can feel confident that the things would still work as they wanted > when the designed their own ICLA) but accept there is another ICLA that > will also apply. > > > 3. Compatibility analysis that is required > > As explained in point 1.c, each FIWARE GEri today has its own open > source license. > > Current text of the ICLA comes from the Apache project where all > projects are assumed to be released under the Apache 2.0 license. > > It is required to run an analysis that confirms that the current wording > would be compatible with different open source licenses or it imposes some > matter that would only be feasible to comply with if the source code of the > project is released under Apache 2.0 license. At least, we should make > sure it works for both Apache 2.0 (this is sure by design) and licenses of > the GPL "family". > > > Best regards, > > -- Juanjo > > ______________________________________________________ > > Coordinator and Chief Architect, FIWARE platform > IoT Unit, Telefónica > > email: juanjose.hierro at telefonica.com > twitter: @JuanjoHierro > > You can follow FIWARE at: > website: http://www.fiware.org > twitter: @FIWARE > facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 > linkedIn: http://www.linkedin.com/groups/FIWARE-4239932 > > > ------------------------------ > > 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 > > > _______________________________________________ > FIWARE-Foundation-legal mailing listFIWARE-Foundation-legal at lists.fiware.orghttps://lists.fiware.org/listinfo/fiware-foundation-legal > > > > _______________________________________________ > FIWARE-Foundation-legal mailing list > FIWARE-Foundation-legal at lists.fiware.org > https://lists.fiware.org/listinfo/fiware-foundation-legal > > -- Stefano De Panfilis Chief Innovation Officer Engineering Ingegneria Informatica S.p.A. via Riccardo Morandi 32 00148 Roma Italy tel (direct): +39-06-8759-4253 tel (secr.): +39-068307-4513 fax: +39-068307-4200 cell: +39-335-7542-567 skype: depa01 twitter: @depa01 -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/fiware-foundation-legal/attachments/20160916/4694c242/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy