[PATCH rtems-docs] eng: Add rules for attribution

[Chris Johns]

On 30/9/21 4:55 pm, Christian MAUDERER wrote:
> Am 30.09.21 um 02:23 schrieb Chris Johns:
>> On 29/9/21 6:38 pm, Christian MAUDERER wrote:
>>> Am 29.09.21 um 02:40 schrieb Chris Johns:
>>>> On 28/9/21 11:11 pm, Christian MAUDERER wrote:
>>>>> Hello Joel,
>>>>>
>>>>> Am 28.09.21 um 14:48 schrieb Joel Sherrill:
>>>>>>
>>>>>>
>>>>>> On Tue, Sep 28, 2021, 1:40 AM Christian MAUDERER
>>>>>> <christian.mauderer at embedded-brains.de
>>>>>> <mailto:christian.mauderer at embedded-brains.de>> wrote:
>>>>>>
>>>>>>       Hello Joel,
>>>>>>
>>>>>>       Am 28.09.21 um 01:12 schrieb Joel Sherrill:
>>>>>>        > The Microblaze port is interesting for attribution. I did initial
>>>>>>       work
>>>>>>        > on it. Hesham added to that and got Hello on a board. Alex is
>>>>>>       close to
>>>>>>        > submitting the port in a nice state.
>>>>>>        >
>>>>>>        > This is almost seven years across three developers.. The original
>>>>>>       work
>>>>>>        > predates source code reorganisation. Alex deleted the autoconf
>>>>>>       support
>>>>>>        > and created waf. Hesham and I agreed to convert to BSD-2.
>>>>>>        >
>>>>>>        > When submitted, we decided it was best for Alex to submit a Joel
>>>>>>       patch,
>>>>>>        > then Hesham, then Alex to finish it off. This keeps git blame
>>>>>>       working.
>>>>>>        >
>>>>>>        > Not quite the same topic but related to credit due.
>>>>>>
>>>>>>       But maybe an important extension. Should we replace "sponsored" with
>>>>>>       "sponsored or supported"? That would allow to mention anyone who helps
>>>>>>       in any way, regardless whether it's financial, with information, with
>>>>>>       hobby time or with whatever else.
>>>>>>
>>>>>>
>>>>>> I usually use the word sponsored. Support implies commercial activities the
>>>>>> way I/we tend to use it.
>>>>>>
>>>>>
>>>>> Seems that I picked the wrong word then. Maybe you can help me finding the
>>>>> correct term:
>>>>>
>>>>> The one case is clear: Someone pays that someone else develops for example a
>>>>> driver. I think for that "sponsored" is a good term.
>>>>>
>>>>> Another similar case could be the following: You get help with writing a
>>>>> driver
>>>>> for example with information or some other form of help that doesn't result
>>>>> in a
>>>>> copyright for that person or company. It doesn't involve money or some other
>>>>> form of payment (T-shirts, pizza, ...) so it's not really sponsoring. Despite
>>>>> that it might would be nice to mention them if they want to be mentioned. I
>>>>> think the right location would be the same place like the one we just discuss
>>>>> for sponsoring. What would be a good term for that?
>>>>
>>>> I think we should take baby steps with this.
>>>
>>> OK. I'll concentrate only on the case where some work is really sponsored with
>>> money. I think a lot of work on RTEMS falls in that category. Most of the times
>>> the sponsors don't want to appear with a name but in my case that caused this
>>> discussion they do.
>>
>> I appreciate the customer may want this however my role is to ensure the process
>> makes sense for the whole community. I am still not sure.
>>
> 
> I fully agree that you should discuss it from a community point of view here. I
> can't take that role in this discussion.
> 
>> It will be your customer's decision to have the changes merged and for the repo
>> to absorb them and maintain them. They always have the right to hold on to the
>> changes and maintain them if they do not agree with the outcome of this process.
>>
> 
> Of course.
> 
>>>> I have some reservation on where
>>>> this could go and the long term effects. If too widely spread and embedded in
>>>> the source it could be difficult to remove or change if we find an issue in
>>>> doing this.
>>>>
>>>
>>> Understood.
>>>
>>>> In a private chat on the subject Gedare suggested a "Supporters" file? This
>>>> could list those who have provided support and wish to be listed. I am avoiding
>>>> sponsorship and other words here on purpose for now. I have no idea what works
>>>> legally around the world.
>>>
>>> To be honest: If sponsored work is a legal problem, we have that with or without
>>> a note in the files. It's only more visible with a note in the files. I don't
>>> think that a legal problem would be avoidable just by not mentioning it.
>>
>> That is not the legal aspect I have in mind. There exists constraints about
>> payments for work done in relation to tax law and this varies around the world.
>> A notice could be taken as evidence. For example a functioning non-profit such
>> as the RTEMS Foundation can accept donations and how that money is spent is up
>> to the foundation. The contributor has no input on that process otherwise it is
>> tax avoidance. This area is strict and the governance is important. I will let
>> you consider the relationship between fair attribution for the whole community
>> and those contributing to a non-profit.
>>
>> I also have other legal concerned I do not wish to discussion here.
> 
> OK. Still not sure whether it really makes a difference whether the notes are in
> a "Supporters" file, in the sources directly or not mentioned at all. But maybe
> I use a too intuitive view here. Legal systems are often not based on what feels
> correct (including the German one). So you are right: We have to be careful.
> 
>>
>>> You mentioned a "Supporters" file as an alternative. That's OK for me too. How
>>> would that look? Something like
>>>
>>>      * 2020: BSP for FOO chip supported by "Some corp"
>>>
>>>      * September 2021: "Some corp" supported development of feature X
>>>
>>>      * 1995 to 2021: Continuous support of development by company "Some corp"
>>>
>>> Not sure whether "supported" is the right term in all cases.
>>
>> Close, I would remove the "extra" words. Maybe:
>>
>>    * May 2020
>>      - FOO Friers LLC
>>      - BSP for FOO Chip
>>
>> Key is adding what is needed while keeping the info minimal.
> 
> Looks a bit like YAML. In that case we maybe should take care that it is fully
> YAML compatible (in case we some-when want to parse it into another format):
> 
>     # Some explanation
>     # what this file is
> 
>     - 2020-05
>         - FOO Friers LLC
>         - BSP for FOO Chip
> 

No issue with that format.

>>> What kind or order would we use? Just chronological?
>>
>> Yes. We will need to generate something that is placed at the start to explain
>> the contents and any limitations and legally protects the project and other
>> contributors.
>>
> 
> OK.
> 
>>> What about companies that
>>> are actively involved in development over a long time (especially the ones that
>>> appear in the copyright lines)? Should they be mentioned?
>>
>> No.
>>
> 
> OK.
> 
>>> Same rules like for the sources: No contact information and only a name?
>>
>> Nothing at all. We should only be adding information in a single place.
>>
> 
> Sorry: Bad wording. What I meant: Should we apply the same rules that you
> suggested for the sources in the other mail thread: No contact information and
> only a name.

Ah ok and yes.

> I didn't want to say that we should have the information in the sources too. I
> fully agree to not duplicate information.

Makes sense now.

>>>> I do want a working foundation and yes I know that has stalled for reasons
>>>> beyond my control but if that path becomes active I am not sure how that works
>>>> in with this approach.
>>>
>>> A foundation wouldn't change the problem discussed here. Don't get me wrong: I
>>> would love to see the foundation. But I don't think that the foundation would be
>>> the the same as the RTEMS open source project from a legal point of view. It
>>> would only be another (much needed) sponsor of work and infrastructure.
>>
>> Sorry, a non-profit does not work that way as I stated above so no attribution
>> can happen. This makes attribution fundamentally unfair.
>>
> 
> Not sure whether I agree that a non-profit is that different at least from the
> legal point that I know. But that only strengthens your point regarding the
> difficulties with different legal system.

We could bike shed this forever and never know if we are right or wrong.

>>> So in case of a "Supporters" file, the foundation would have a separate line
>>> like
>>>
>>>      * 2021 to present: Continuous support of development and infrastructure by
>>> the RTEMS Foundation
>>
>> There are practical issues with doing this. I also see no value so this is a no
>> from me adding an RF entry. For example, who dives back into the file to edit
>> this if it changes? Who changes these entries that are no longer valid? Can we
>> even make such a change?
> 
> Yes, that should be another rule: No open time spans.

Yes.

>>>> I also acknowledge I am not sure what other open source projects do and how
>>>> they
>>>> handle this. If there are other working examples we can review I would welcome
>>>> that.
>>>
>>> I put some time into finding examples and I found ... not much.I would have
>>> expected for example a big project like the Linux kernel to have a lot of these
>>> lines and to have clear rules. But: It's only 38 lines in source files that have
>>> a "sponsored by". At least one commit has a "This patchset has been sponsored by
>>> ..." in the commit message. But I didn't find any rules.
>>
>> Yes and this is part of my concern. I prefer we do not break new ground and we
>> find there are real issues we are not aware of.
>>
>>> It's similar for FreeBSD. I found some "sponsored" in the code. Some in the
>>> commit messages. But I haven't seen any clear rules.
>>
>> Yeap
>>
>>> Maybe I used the wrong search terms?
>>
>> I do not think so, it matches what I found.
>>
>> I have to say I not entirely comfortable with this happening and I will not be
>> encouraging additions.
> 
> I assume that is also true for the "Supporters" file?

Yeap and only because I am not sure how this will actually work. For example how
do you know the person asking for the attribution has the permission to do this?
That question is a rabbit hole.

> If the outcome of this discussion is that we add a rule to not allow any
> attribution for sponsoring, that's OK too. But in that case we should document
> it somewhere too (together with the reason).

Sure.

Chris