Hi Evan, Thanks - I really appreciate you taking the time to summarise the situation.
On Tue, Mar 15, 2016 at 01:14:39PM +0000, Evan Lloyd wrote: > I recently submitted some patches with fixes and improvements > derived from our work on the Juno platform. > Laszlo very politely queried my "sign off" of the patches which bore > Sami's name as author and gracefully suggested the proper "S-o-b" > style. Others have since queried my consequent strategy of > appending sign-offs from the whole team. > > The position is that Sami did the task of extracting changes from > our internal (offline) Subversion repository and merging them into a > Tianocore clone from GitHub. The Git "author" shows only that. (As > it happens, Sami was the producer of most of the changes, but that > is incidental.) We have neither time, nor inclination, to delve in > 4 years of offline development history simply to unravel the > original author and all contributors for each line of code. > > The main point is that as part of our contracts of employment we > assign all of our IP rights in the code to ARM. I assume other > companies have similar contractual terms over IP (everywhere I have > ever worked had). As tech lead I am tasked with evaluating the > team's code and submitting what is suitable to Tianocore, so ARM > effectively delegates the authority to release that (ARM) IP to me. > That is, ARM owns the code and gifts it to Tianocore; an individual > employee is only involved as a paid agent of ARM. Obviously > commits and submissions from an ARM e-mail address cannot be > personal contributions, so residual rights as author are not > relevant. > > However, the current "S-o-b" semantics on the list seems to be based > on purely personal contributions. That takes no account of work > done by a team within an organisation, or the fact that not > everybody in a team need interact directly with Git. > > So, can we come to some agreement about how that (corporate) sign > off is to be indicated, and what it is intended to achieve, anyway, > given that EDK2 contributors are members of UEFI? > > (NOTE: This is not about an author's right to the IP, which is > retained. It is about the meaning of authorship and sign-off by an > individual, of code generated at the expense of an organisation.) So, I think we have two separate items to resolve: 1) What is the appropriate sign-off for patches being exported from a previously not upstreamed internal development track. 2) What is the appropriate way for new developments to be contributed. Clearly the former should be given some leeway regardless of what the consensus for 2) is. I cannot believe this is an unusual situation, and it would be good to have a clearly defined (and agreed on) way to handle upstreaming of code previously maintained in internal repositories over an extended period. For what it's worth, I don't strongly oppose your view, but it looks unusual, so I do understand Laszlos reaction (my instinctive one was similar). The default Contribution.txt copied across the different modules does not appear to contradict your view, but I fear it may be possible to read it either way depending on your expectations. What I'm really looking for is (as I've hinted before on the list) some better codification of the development model used in this community. So I would appreciate input from more people. Regards, Leif _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
