W3C home > Mailing lists > Public > public-w3process@w3.org > December 2014

Re: Invited expert and CG Contributor agreements

From: Wayne Carr <wayne.carr@linux.intel.com>
Date: Thu, 18 Dec 2014 14:04:28 -0800
Message-ID: <54934F6C.3060408@linux.intel.com>
To: chaals@yandex-team.ru, "public-w3process@w3.org" <public-w3process@w3.org>

On 2014-12-18 13:33, chaals@yandex-team.ru wrote:
>
> 19.12.2014, 00:24, "Wayne Carr" <wayne.carr@linux.intel.com>:
>> On 2014-12-18 05:19, chaals@yandex-team.ru wrote:
>>>   18.12.2014, 16:15, "Olle Olsson" <olleo@sics.se>:
>>>>   On 2014-12-16 20:24, David Singer wrote:
>>>>>     [changing the subject as this is a new can of worms]
>>>>>>     On Dec 16, 2014, at 10:44 , Sam Ruby <rubys@intertwingly.net> wrote:
>>>>>>
>>>>>>     Use case: should I ever become unemployed (to be clear: my company seems happy with me, but many companies do periodic "reductions in force" with no apparent rhyme or reason), I would still be interested in working on the URL specification; and would be willing to sign a CLA like the ASF's, but would not be willing to sign the current Invited Experts agreement.
>>>>>     I assume the problematic part is this?
>>>>>
>>>>>     "The Invited Expert agrees to refrain from creating derivative works that include the Invited Expert's contributions when those derivative works are likely to cause confusion about the status of the W3C work or create risks of non-interoperability with a W3C Recommendation. «Branching» is one example of a non-permissible derivative work.”
>>>>   Is this a restriction on an Invited Expert only holding while he *is* an
>>>>   invited expert (which is role of a finite duration) or is it intended to
>>>>   be a perpetual constraint?
>>>   It is a perpetual constraint, per the section on duration and termination:
>>>   [[[
>>>   Even in the event of termination of the Invited Expert relationship sections 2.2, 2.3, 2.5 and 2.6 will persist.
>>>   ]]]
>> I'm surprised about that restriction.  If that's been in the previous
>> public draft versions, I missed it.
> It's been in the agreement since 2007 I believe
>
>> Would W3C Members apply that rule to themselves?
> No, as far as I can tell it doesn't apply to members
>
>>   I doubt it, and it
>> isn't applied to W3C Members, what use is it to apply just to IEs?
> There are many possible answers. It makes it clearer that being a member is better, it makes people take their contributions seriously, …
>
> But…
>
>> It wouldn't be surprising that some feature is useful broadly in
>> multiple contexts.
> Yes.
>
>>   Someone contributing that to W3C should not mean
>> they can't also contribute their own work elsewhere for whatever purpose
>> they choose.
> Maybe, maybe not. Let's see where the consensus is.
>
>>   That paragraph should be removed - soon.   I wouldn't
>> consider agreeing to that as an IE either.
> In my case it would depend on what I thought of and how much I trusted W3C. But there are obviously disadvantages if we're trying to get people to participate.

I was thinking about use in other contexts entirely - so not related to 
trusting W3C or not.  Like, there's some algorithm the IE writes up that 
is useful in a W3C spec, but also useful in say a Python or Java API 
where they are also working (so, not taking anything anyone else 
contributed, just their own contribution, and using it elsewhere).



>
> cheers
>
>>>   cheers
>>>>   /olle
>>>>
>>>>   --
>>>>   ------------------------------------------------------------------
>>>>   Olle Olsson   olleo@sics.se   Tel: +46 8 633 15 19  Fax: +46 8 751 72 30
>>>>             [Svenska W3C-kontoret: olleo@w3.org]
>>>>   SICS [Swedish Institute of Computer Science]
>>>>   Box 1263
>>>>   SE - 164 29 Kista
>>>>   Sweden
>>>>   ------------------------------------------------------------------
>>>   --
>>>   Charles McCathie Nevile - web standards - CTO Office, Yandex
>>>   chaals@yandex-team.ru - - - Find more at http://yandex.com
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex
> chaals@yandex-team.ru - - - Find more at http://yandex.com
>
>
>
Received on Thursday, 18 December 2014 22:06:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:51:25 UTC