[Fiware-technical-committee] Controversial point regarding requirements on contribution management policies with respect to FIWARE GEs

José Manuel Cantera josemanuel.cantera at fiware.org
Fri Oct 5 08:37:56 CEST 2018


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> 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
> https://lists.fiware.org/listinfo/fiware-technical-committee
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-technical-committee/attachments/20181005/761b3d78/attachment.html>


More information about the Fiware-technical-committee mailing list

You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy   Cookies policy