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

Christian MAUDERER christian.mauderer at embedded-brains.de
Thu Sep 30 06:55:37 UTC 2021


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

> 
>> 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.

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

>>> 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.

>> 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.

> 
>>> 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?

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).

Best regards

Christian

 > If Thomas wishes to discuss this further I suggest he
 > reaches out to me personally.
> 
> Chris
> 

-- 
--------------------------------------------
embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/


More information about the devel mailing list