[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