Hi Juanjo, all,
thanks for the detailed feedback from you and the positive responses
from others. It seems we all agree that we need to move forward, which
is a good sign.
BTW, I limited the discussion to the WPL/WPA as it could be perceived as
damaging if sent as a response to the entire project (including the EC,
I believe) and I wanted to prevent that from happening. I am all for an
open and broad discussion about these issues! I suggest we prepare this
in smaller circle next week and then open it up to the project.
Regarding the license issue:
I agree that you email is technically a inquiry but it is worded such
that most people will read it as a request to change their license in
short notice ("confirm they would agree to adopt one of the two"). This
also has to do with your role als "benevolent dictator"), like it or
not. This is exactly what has happend in WebUI and I guess others will
read it the same way. So a clarification would be very helpful.
Also, there are licenses that are technical almost the same (MIT, BSD,
and Apache, with only minor differences, e.g. regarding the patent
clause or so). So, one way forward could be to encourage one of those
(e.g. Apache, as it has the Patent clause) but accept the others as
essentially equivalent (at least for some transition period). This would
avoid potentially a lot of additional work and thorny issues of
relicensing for hardly any practical difference. At least regarding
these licenses I consider the problem more of a PR thing than a
technical issue. But let's discuss this on Monday.
One more strategic aspect of this discussion is if we perceive FIWARE as
single uniform platform (with all the same licenses) or more a
consistent set of tools that are designed to work together well but are
not necessarily all the same (e.g. regarding their licenses).
BTW, we should be clear (internally and externally) what our licenses
cover and what they do not. There are limitations on what copyright
(what all these licenses are based on) can regulate, especially in a
service context -- such as in FIWARE. A good starting point for those
discussions (and important to understand the AGPL) is this:
https://www.gnu.org/philosophy/who-does-that-server-really-serve.html.
This last aspect is also causing confusion regarding your statements
about "contamination" ("In both cases, a clear message to deliver is
that applications/services developed based on the FIWARE GEris will not
need to be distributed as open source. In other words, they are not
"contaminated" by the open source nature of FIWARE GEris."). This is
because the GPL and AGPL are clearly contagious when used for linking
application code against them (covering what I would call an
"application"). But, for the reasons discussed in the link in the
previous paragraph, they cannot be contagious if used in separate
services (at least that is my understanding). We need to make this
crytal clear to ourselves first (!!) and to our users (and I am not sure
we are yet). But that is again more a PR issue than a technical one.
Regarding governance:
First of all, I would ask you to unmark your name in the minutes if you
actually participate (like the rest of us), so we have a clear picture
of who is aware of and participated in the discussions. My statements
about your attendance were based on this information (plus not hearing
from you in these calls :-).
I agree with you that a lot of things handled in the coordination call
are more of day to day business and less strategic. But we have had the
slot for the Architecture Call (on Monday mornings) for a long time now,
except that this has hardly been used at all. So, there is little we
need to change -- other than actually doing it :-).
Its good to get the TC officially started (we stated Nov 2015 for that
to happen!). But regarding the work to be done there, I believe we do
have the right people in the coordination/architecture call already. So
I suggest to revive the Architecture Call for doing this more strategic
work and not wait for the elections. They can happen in parallel.
But please revive the Monday morning call *with ample warning* as most
people will have allocated this slot for other work by now (as I have
done, since the event did not happen for too long).
Best,
Philipp
Am 29.12.2015 um 11:50 schrieb Juanjo Hierro:
> Dear Philipp,
>
> Thanks for expressing your concerns.
>
> Some clarifications regarding the email about open source licenses:
>
> * I believe that the issue about number of open source licenses linked
> to FIWARE GEs is not new ... indeed I would say that it has been
> there since years and have been discussed among us from time to
> time, there has been general agreement that some sort of
> simplification would be welcomed, but no action has never been
> done. On the other hand, I believe we cannot longer ignore the
> constant feedback we receive about this being a source of doubts
> about what can be done with FIWARE and how components can be used
> together.
> * What I have shared with the community of FIWARE GE owners is this
> fact, and the need to simplify the model trying to arrive with a
> reduced number of open source licenses we can clearly explain why
> they are accepted for GEs contributed to FIWARE.
> * Then what I have shared is that we **believe** that the number of
> licenses can be reduced to the proposed two (Apache v2.0 and GNU
> Affero GPL v3.0) for the reasons given, and then we have kindly
> asked FIWARE GE owners *whether they would agree* to transition
> their current license to any of the two proposed ones *or explain
> what would be the reasons why* they would oppose doing so. Bottom
> line, *I haven't communicated any decision* to go for the two
> proposed licenses *nor a deadline* for doing so (only a deadline for
> gathering input because the input we have asked should not require a
> long period). *I have raised an issue we believe has to be solved,
> explain what we believe can be done to solve it, and then ask for
> input that would help us to speed up a decision*. Please read
> carefully my email to realize that :-)
> * A final decision may take place in a coordination meeting after the
> Christmas holidays and that was the intention. Hopefully this could
> be mid January. But we need to gather the necessary input/feedback
> in advance from FIWARE GE owners if we want such coordination
> meeting to be effective. This is what, I hope, we will be able to
> do after the email I sent.
> * Nevertheless, given the fact that this has may have created some
> misunderstandings, I will send an email clarifying the above. It's
> been good that you have raised a flag.
>
>
> About the governance model:
>
> * It's not true that I haven't joined the coordination confcall since
> mid September. During many of them I was there, but I have
> deliberately given the lead to Miguel and Manuel since the calls
> have been mostly focused on milestones, deliverables, and follow-up
> of agile practices, so my intervention was not that much necessary
> and I didn't want to act as a bottleneck. I focused more on
> participation in Sprint Review meetings which I found very useful
> (and indeed I believe chapter architects should attend entirely, not
> just when dealing with their chapters). But it's true that I have
> missed probably a half of them (in part because I was informed by
> Miguel in advance that they had to focus on milestones, formal
> deliverables, etc).
> * I have been giving a thought to the matter since a long time because
> I feel we should change the way we run this coordination meetings:
> o I feel that we have to separate the meetings dealing with
> follow-up of milestones and deliverables or the agile practices
> from the meetings dealing with more, sort of, strategic
> decisions (like this one about open source licenses but also
> several others, some of which would be more technical).
> o We have to kick-off the governance model we defined for the
> FIWARE Community and probably the second kind of meetings I'm
> referring to in the previous point (the ones dealing with more
> strategic decisions) could be the ones for which we could start
> putting the notion of FIWARE Technical Committee at work.
> * Regarding how to avoid bottlenecks, I'm happy to discuss formulas,
> but I believe that the right course of action would be to kick-off
> the FIWARE Technical Committee (TC) as soon as possible. Then,
> roles may be decided in TC meetings so that work is placed in the
> hands of as many as possible and we will always have the TC meetings
> to follow up whether things go in the right direction. It will be
> a matter of identifying actions and then ask who can own them.
> Sure some kind of actions will naturally lead to definition of more
> permanent roles which will end up being carried out by those who
> regularly demonstrate they take the ownership for actions they are
> assigned. I trust that members of the TC will feel eager to take
> responsibilities and carry out the duties they are assigned without
> this requiring there is EC funding behind (otherwise, the whole
> story of the FIWARE community will never fly). However, we will
> probably need to define some internal mechanisms to make sure people
> doesn't fall into too voluntarism and then systematically fail
> (e.g., if an action remains pending without progress then it has to
> be reassigned to someone else, maybe also put some karma mechanism
> in place regarding execution of action points).
> * We will probably need to put at work some kind of interim FIWARE TC
> until we run the elections defined in the governance model which in
> turn would require first to identify who can be recognized as Active
> Contributor since they are the ones who can vote who can be members
> of the TC. My proposal would be to go for including the (FIWARE
> and FIWARE Ops) chapter architects and leaders plus the coordinators
> of activities linked to the FIWARE Lab, the FIWARE Catalogue, the
> FIWARE Academy and the FIWARE Developer home. I would volunteer to
> chair it. This FIWARE TC would not focus on follow-up of sprint
> plannings or delivery of releases. We should define a deadline for
> getting this FIWARE TC renewed based on elections according to the
> defined FIWARE Governance Model but at least we would not be blocked
> in taking some decisions.
> * My idea was to discuss all this in an ad-hoc coordination confcall
> beginning in January (i.e., next week :-) Soon I'll send a doodle
> poll for that. We can follow up progress on the matter about open
> source licenses in the same confcall although we will not have all
> the input gathered by then (the deadline we proposed to gather input
> was January 8th).
>
>
> Best regards,
>
> -- Juanjo
>
> ______________________________________________________
>
> Coordinator and Chief Architect, FIWARE platform
> CTO Industrial IoT, 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
>
> On 29/12/15 08:24, Philipp Slusallek wrote:
>> [I have taken this to the CHL/CHA list only]
>>
>> Hi Juanjo,
>>
>> I am very surprised by this email from you. While I am not necessarily
>> opposed to the goal of your email, I find the process deeply flawed.
>>
>> Changing a license is not something we do for fun. There might be
>> implications that are relevant to discuss before such "decisions" are
>> taken and published (for a starters: What about the need for getting
>> permission for such a change by copyright holders of the OSS SW we
>> create?). And there might actually be alternatives as well.
>>
>> Funny enough, we actually have just published a shiny new governance
>> model that defines a Technical Committee for making such decisions. We
>> even have a well-established weekly coordination call where the relevant
>> discussions and decisions can and should take place. None of this has
>> been used in this process, AFAIK. Shouldn't we follow the rules and
>> processes that we have defined for ourselves before we publicly announce
>> such "decisions"?
>>
>> I suggest that we discuss this topic in our next coordination call in
>> more detail and by email in the mean time. Until then I will find out
>> what changing the licenses would even mean in our chapter. Given the
>> holiday season this might take some time.
>>
>>
>> On a highly related note let me bring up a topic that has been worrying
>> me for a while now: The current de-facto governance process is highly
>> focused on you as the main decision facilitator and leader of the
>> project. And let me be clear: You have, in general, been doing a great
>> job at that!
>>
>> However, without you many things simply do not happen. And most
>> importantly: You have not participated in the coordination calls since
>> mid September (according to the minutes) -- this is for *more than three
>> months and counting*. Even worse, you also seem to be hard to reach even
>> when there are important pending decisions (as has been discussed on the
>> call multiple times). I am pretty sure that you are doing good work in
>> the mean time, but that does not really help this situation. This email
>> of yours is most likely a result of this lack of communication.
>>
>> Obviously, by using such a highly centralized structure as we are doing
>> right now, we have created a bottleneck situation for you (and you
>> probably feel it the most!). This is a situation that is not helpful and
>> maybe even dangerous for making progress in the project. This is
>> something that a good governance model should avoid.
>>
>> As we know from SW development, with a bottleneck we have three options:
>> We either free up the bottleneck from other tasks, we add more
>> processing power to it (since upgrading you is probably not an option
>> :-), a dedicated deputy structure or such comes to mind), or we redesign
>> the system to avoid the bottleneck with a more distributed decision
>> making structure (might be hard to implement).
>>
>> I believe, we should be addressing this situation in our next call.
>>
>>
>> Final notes: I have been genuinely worried about the situation for a
>> while now, so please do not shoot the messenger. And no, I am not at all
>> interested nor even willing to take on more power or jobs within FIWARE.
>>
>>
>> Best,
>>
>> Philipp
>>
>>
>>
>> Am 28.12.2015 um 15:09 schrieb Juanjo Hierro:
>>> Dear all,
>>>
>>> 2016 is going to be a crucial year during which we have to
>>> significantly increase the visibility of FIWARE among the wider
>>> community of developers. It also has to experience a significant growth
>>> in terms of adoption (numbers of users of the technology).
>>>
>>> One of the topics in which we have identified a need to improve, in
>>> order to lower the barriers of adoption, is the one about open source
>>> licenses associated to the FIWARE GEris. We have received a lot of
>>> different feedback about the need to be able to deliver a simple
>>> message, easier to understand. Because of that, a first action to
>>> implement would be that of avoiding to manage too many open source
>>> licenses. Having too many open source licenses is hard to explain and
>>> weakens the notion of "platform" which should mean adoption of common
>>> policies, rules and practices for its components, e.g., the open source
>>> license adopted.
>>>
>>> Based on information available and expertise about characteristics of
>>> open source licenses, we believe that the number of Open Source Licenses
>>> can and should be reduced to just two:
>>>
>>> * Apache License version 2.0
>>> * GNU Affero GPL v3.0
>>>
>>>
>>> We believe that one or the other license should allow to address the
>>> goals/needs of FIWARE GEri owners:
>>>
>>> * The Apache version 2.0 license is a paradigm of open source license
>>> giving anyone the permission to derive close products without
>>> contributing back developed improvements. It has been typically
>>> chosen by owners who are mostly focused on accelerating the
>>> adoption, as a de-facto standard, of the specifications implemented
>>> by the open source product under this license.
>>> * The GNU Affero GPL v3.0 license is as paradigm of open source
>>> license where the owner allows third parties to study, use and
>>> modify the software but without the right to derive closed products
>>> (or setup cloud services based on derived versions of the software
>>> that are kept "hidden" to users of such cloud services). It has
>>> been typically chosen by owners who claim that third parties who
>>> modify the software should contribute back to the community in return.
>>>
>>>
>>> In both cases, a clear message to deliver is that
>>> applications/services developed based on the FIWARE GEris will not need
>>> to be distributed as open source. In other words, they are not
>>> "contaminated" by the open source nature of FIWARE GEris.
>>>
>>> We would kindly ask FIWARE GEri owners to bring an update of the info
>>> about their FIWARE GEris that was available at the following URL
>>> (particularly the Open Source license currently adopted):
>>>
>>> https://docs.google.com/spreadsheets/d/1nl02hcZ79WC5i_sYbL1jV_aLyF1swcES0P4VQgP-csE/edit?usp=sharing
>>>
>>>
>>> We would also kindly ask owners of FIWARE GEs which are not
>>> distributed under any of the above mentioned open source licenses to
>>> confirm they would agree to adopt one of the two (in which case we ask
>>> them to specify which one in a new column titled "revised open source
>>> license" we have added to the shared google docs spreadsheet). If not,
>>> we will ask them to reply Miguel and me what would be the rationale behind.
>>>
>>> Deadline for gathering the info will be January 8th.
>>>
>>> Best regards,
>>>
>>> -- Juanjo
>>>
>>> ______________________________________________________
>>>
>>> Coordinator and Chief Architect, FIWARE platform
>>> CTO Industrial IoT, 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-chapter-leaders mailing list
>>> Fiware-chapter-leaders at lists.fiware.org
>>> https://lists.fiware.org/listinfo/fiware-chapter-leaders
>>>
>
>
> ------------------------------------------------------------------------
>
> 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
--
-------------------------------------------------------------------------
Deutsches Forschungszentrum für Künstliche Intelligenz (DFKI) GmbH
Trippstadter Strasse 122, D-67663 Kaiserslautern
Geschäftsführung:
Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender)
Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
Prof. Dr. h.c. Hans A. Aukes
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973, Steuernummer: 19/673/0060/3
---------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: philipp_slusallek.vcf
Type: text/x-vcard
Size: 441 bytes
Desc: not available
URL: <https://lists.fiware.org/private/fiware-chapter-leaders/attachments/20151230/dda69192/attachment.vcf>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy