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

Gedare Bloom gedare at rtems.org
Mon Jan 30 15:11:08 UTC 2023


On Fri, Oct 1, 2021 at 6:11 PM Chris Johns <chrisj at rtems.org> wrote:
>
> 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

Ping. I think we have now some patches and process to use
"Sponsored-By: ..." in commit messages. I can't find the guidance in
the docs.

> >>
> >>> 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
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel


More information about the devel mailing list