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

2023-01-30 Thread Gedare Bloom 
On Mon, Jan 30, 2023 at 8:33 AM Sebastian Huber
 wrote:
>
>
>
> On 30.01.23 16:11, Gedare Bloom wrote:
> > 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.
>
> These are commits from third-party sources, for example FreeBSD.
>

OK, thanks. And I think just some of the commits from Karel.

I would revive this to see if we can make a resolution.

In academic publishing it is quite common to have something like
"Acknowledgement of Funding Source" -- This is not ambiguous what it
means to "support" or whatever. However it is in academic publishing
an obligation usually to report funding sources (for ethical
considerations).

If the resolution is to prohibit acknowledgements of non-technical
contributions (funding), we should document it.

Gedare
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

2023-01-30 Thread Sebastian Huber 



On 30.01.23 16:11, Gedare Bloom wrote:

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.


These are commits from third-party sources, for example FreeBSD.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
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/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

2023-01-30 Thread Gedare Bloom 
On Fri, Oct 1, 2021 at 6:11 PM Chris Johns  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
> >>  >> > 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

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

2021-10-01 Thread 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
>> > > 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
>>

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

2021-10-01 Thread Chris Johns 
On 30/9/21 5:33 pm, Thomas DOERFLER wrote:
> Am 30.09.21 um 02:23 schrieb Chris Johns:
>> On 29/9/21 6:38 pm, Christian MAUDERER wrote:
>>>
>>> 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.
> 
> Surely this must be considered, but OTOH RTEMS code is definitively a project
> which combines non-profit and with-profit people to create and maintain code,
> especially since the birth of the project was with-profit.
> 
> So if it comes to contributions e.g. from our company: Yes, they are created
> with profit.

This is fine. An organisation and their tax system have well established
processes to audit and collect the related tax. Contributing to a non-profit to
complete task X or any directed task then claiming that payment as a tax
deduction is not allowed. That loop hole was closed many years ago.

> Certain areas are handled non-profit. Maybe the question then is, how to
> properly distinguish them.

For a non-profit it is the role of that organisation and not this project. It
would be concerning if the project started to take on that role. The rules
around a non-profit and it's sponsors are for it to administer.

>>> 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.
>>
> I agree that a "sponsored by RTEMS Foundation" entry wouldn't make sense,
> because the whole idea of the Foundation is to maintain RTEMS.
> 
> But, regarding the "sponsored by" entry, I wouldn't talk about fairness. 

Maybe fairness is not a good word in this case.

> In the
> past we always had the question "who is using RTEMS" and in many cases had to
> shrug shoulders because we either don't know or shouldn't tell. If RTEMS user
> companies officially ask to be visible, I think this is something we should 
> push
> and not block, right?

I welcome a user placing a "power by RTEMS" on their box or in there marketing
or documentation.

>> I have to say I not entirely comfortable with this happening and I will not 
>> be
>> encouraging additions. If Thomas wishes to discuss this further I suggest he
>> reaches out to me personally.
> 
> That makes sense, I will try next week when being back at work.

Thanks and please do.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

2021-09-30 Thread Thomas DOERFLER 

Hi Chris,

Am 30.09.21 um 02:23 schrieb Chris Johns:

On 29/9/21 6:38 pm, Christian MAUDERER wrote:


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.


Surely this must be considered, but OTOH RTEMS code is definitively a 
project which combines non-profit and with-profit people to create and 
maintain code, especially since the birth of the project was with-profit.


So if it comes to contributions e.g. from our company: Yes, they are 
created with profit.


Certain areas are handled non-profit. Maybe the question then is, how to 
properly distinguish them.



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.



I agree that a "sponsored by RTEMS Foundation" entry wouldn't make 
sense, because the whole idea of the Foundation is to maintain RTEMS.


But, regarding the "sponsored by" entry, I wouldn't talk about fairness. 
In the past we always had the question "who is using RTEMS" and in many 
cases had to shrug shoulders because we either don't know or shouldn't 
tell. If RTEMS user companies officially ask to be visible, I think this 
is something we should push and not block, right?



I have to say I not entirely comfortable with this happening and I will not be
encouraging additions. If Thomas wishes to discuss this further I suggest he
reaches out to me personally.


That makes sense, I will try next week when being back at work.

Thomas.


Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel



--
embedded brains GmbH
Herr Thomas DOERFLER
Dornierstr. 4
82178 Puchheim
Germany
email: thomas.doerf...@embedded-brains.de
phone: +49-89-18 94 741 - 12
fax:   +49-89-18 94 741 - 09

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

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

2021-09-30 Thread Christian MAUDERER 

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
mailto:christian.maude...@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

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

2021-09-29 Thread 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
 >>> > 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.

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.

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

> 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

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

2021-09-29 Thread Christian MAUDERER 

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
mailto:christian.maude...@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 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.


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.

What kind or order would we use? Just chronological? 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?


Same rules like for the sources: No contact information and only a name?



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.


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




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

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

2021-09-28 Thread 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
>> > > 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. 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.

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.

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.

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.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

2021-09-28 Thread Christian MAUDERER 

Hello Joel,

Am 28.09.21 um 14:48 schrieb Joel Sherrill:



On Tue, Sep 28, 2021, 1:40 AM Christian MAUDERER 
> 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?


Best regards

Christian



 >
 >
 > On Mon, Sep 27, 2021, 9:49 AM Christian Mauderer
 > mailto:christian.maude...@embedded-brains.de>
 > >> wrote:
 >
 >     This adds some rules how an attribution for sponsored
development should
 >     look like.
 >     ---
 >
 >     Note: This patch is more or less an early draft. See the
following
 >     discussion
 >     for more background:
 >
 >
https://lists.rtems.org/pipermail/devel/2021-September/069465.html

 >   
  >

 >
 >     Points that need discussion:
 >
 >     * Are there some areas where we don't want to have
attribution lines
 >     (Chris
 >        asked about score in the linked discussion). From my point of
 >     view: If there
 >        is a big contribution and the sponsor wants his name in the
 >     (changed) files,
 >        that's OK.
 >
 >     * Do we want attributions in documentation sources? I'm not sure
 >     whether they
 >        might end in HTML comments in the distributed documentation.
 >
 >
 > So far, not enough small has been submitted to matter.
 >
 > I'm happy with a master list

So for documentation it would be one SUPPORTERS file that isn't
processed in any way?

 >
 >
 >     * What kind of format do we want in the documentation?
Restructured Text
 >        documentation suggests that the two dots should be on a
separate
 >     line to avoid
 >        interpreting the comment as directive:
 >
https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#comments


 >   
  >

 >
 >     * Do we need some kind of "signed off" from the sponsor (or
similar)
 >     in the
 >        commits that add attribution so that we can later tell who
said
 >     that it is OK
 >        that we mention the sponsor?
 >
 >
 > We've done this on trust for a long time but wouldn't git blame
tell us
 > the same? If it is a manager without git, then what?
 >

Hm. Good questions.

What I wanted to tell is: Do we need to document who allowed us to
mention the company name?

"git blame" won't tell the same. It would only tell who added the line
"sponsored by Some Company". In most cases that will be the developer
working on it

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

2021-09-28 Thread Joel Sherrill 
On Tue, Sep 28, 2021, 1:40 AM Christian MAUDERER <
christian.maude...@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.


> >
> >
> > On Mon, Sep 27, 2021, 9:49 AM Christian Mauderer
> >  > > wrote:
> >
> > This adds some rules how an attribution for sponsored development
> should
> > look like.
> > ---
> >
> > Note: This patch is more or less an early draft. See the following
> > discussion
> > for more background:
> >
> > https://lists.rtems.org/pipermail/devel/2021-September/069465.html
> > 
> >
> > Points that need discussion:
> >
> > * Are there some areas where we don't want to have attribution lines
> > (Chris
> >asked about score in the linked discussion). From my point of
> > view: If there
> >is a big contribution and the sponsor wants his name in the
> > (changed) files,
> >that's OK.
> >
> > * Do we want attributions in documentation sources? I'm not sure
> > whether they
> >might end in HTML comments in the distributed documentation.
> >
> >
> > So far, not enough small has been submitted to matter.
> >
> > I'm happy with a master list
>
> So for documentation it would be one SUPPORTERS file that isn't
> processed in any way?
>
> >
> >
> > * What kind of format do we want in the documentation? Restructured
> Text
> >documentation suggests that the two dots should be on a separate
> > line to avoid
> >interpreting the comment as directive:
> >
> https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#comments
> > <
> https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#comments
> >
> >
> > * Do we need some kind of "signed off" from the sponsor (or similar)
> > in the
> >commits that add attribution so that we can later tell who said
> > that it is OK
> >that we mention the sponsor?
> >
> >
> > We've done this on trust for a long time but wouldn't git blame tell us
> > the same? If it is a manager without git, then what?
> >
>
> Hm. Good questions.
>
> What I wanted to tell is: Do we need to document who allowed us to
> mention the company name?
>
> "git blame" won't tell the same. It would only tell who added the line
> "sponsored by Some Company". In most cases that will be the developer
> working on it and not the one from "Some Company" who said that we can
> add the name.
>
> You are right that a manager without git has problems adding the signed
> off line in the "official" git form. But git comments are free text
> anyway. I think a "signed off" line is based on trust like everything
> else in git. It more or less means: The one who pushes the patch has
> some when asked the person whether the patch is OK. We can also add it
> as a free text comment like "Some Company added with friendly permission
> by Some Person".
>
> I'm not sure whether it's an advantage to add something like that or
> whether it's unnecessary bureaucracy.
>
> Best regards
>
> Christian
>
> >
> > I'm sure there are some more points. Please feel free to ask. Again:
> > This is a
> > draft.
> >
> > Best regards
> >
> > Christian
> >
> >   eng/coding-file-hdr.rst | 48
> +
> >   1 file changed, 48 insertions(+)
> >
> > diff --git a/eng/coding-file-hdr.rst b/eng/coding-file-hdr.rst
> > index 3167670..da6f702 100644
> > --- a/eng/coding-file-hdr.rst
> > +++ b/eng/coding-file-hdr.rst
> > @@ -2,6 +2,7 @@
> >
> >   .. Copyright (C) 2018, 2020 embedded brains GmbH
> > (http://www.embedded-brains.de )
> >   .. Copyright (C) 2018, 2020 Sebastian Huber
> > +.. Copyright (C) 2021 Christian Mauderer
> >
> >   .. _FileTemplates:
> >
> > @@ -74,6 +75,28 @@ Check the top-level :file:`COPYING` file of the
> >

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

2021-09-28 Thread Christian MAUDERER 

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.





On Mon, Sep 27, 2021, 9:49 AM Christian Mauderer 
> wrote:


This adds some rules how an attribution for sponsored development should
look like.
---

Note: This patch is more or less an early draft. See the following
discussion
for more background:

https://lists.rtems.org/pipermail/devel/2021-September/069465.html


Points that need discussion:

* Are there some areas where we don't want to have attribution lines
(Chris
   asked about score in the linked discussion). From my point of
view: If there
   is a big contribution and the sponsor wants his name in the
(changed) files,
   that's OK.

* Do we want attributions in documentation sources? I'm not sure
whether they
   might end in HTML comments in the distributed documentation.


So far, not enough small has been submitted to matter.

I'm happy with a master list


So for documentation it would be one SUPPORTERS file that isn't 
processed in any way?





* What kind of format do we want in the documentation? Restructured Text
   documentation suggests that the two dots should be on a separate
line to avoid
   interpreting the comment as directive:
https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#comments



* Do we need some kind of "signed off" from the sponsor (or similar)
in the
   commits that add attribution so that we can later tell who said
that it is OK
   that we mention the sponsor?


We've done this on trust for a long time but wouldn't git blame tell us 
the same? If it is a manager without git, then what?




Hm. Good questions.

What I wanted to tell is: Do we need to document who allowed us to 
mention the company name?


"git blame" won't tell the same. It would only tell who added the line 
"sponsored by Some Company". In most cases that will be the developer 
working on it and not the one from "Some Company" who said that we can 
add the name.


You are right that a manager without git has problems adding the signed 
off line in the "official" git form. But git comments are free text 
anyway. I think a "signed off" line is based on trust like everything 
else in git. It more or less means: The one who pushes the patch has 
some when asked the person whether the patch is OK. We can also add it 
as a free text comment like "Some Company added with friendly permission 
by Some Person".


I'm not sure whether it's an advantage to add something like that or 
whether it's unnecessary bureaucracy.


Best regards

Christian



I'm sure there are some more points. Please feel free to ask. Again:
This is a
draft.

Best regards

Christian

  eng/coding-file-hdr.rst | 48 +
  1 file changed, 48 insertions(+)

diff --git a/eng/coding-file-hdr.rst b/eng/coding-file-hdr.rst
index 3167670..da6f702 100644
--- a/eng/coding-file-hdr.rst
+++ b/eng/coding-file-hdr.rst
@@ -2,6 +2,7 @@

  .. Copyright (C) 2018, 2020 embedded brains GmbH
(http://www.embedded-brains.de )
  .. Copyright (C) 2018, 2020 Sebastian Huber
+.. Copyright (C) 2021 Christian Mauderer

  .. _FileTemplates:

@@ -74,6 +75,28 @@ Check the top-level :file:`COPYING` file of the
repository.  If you are a new
  copyright holder, then add yourself to the top of the list.  If
your last year
  of a substantial contribution changed, then please update your
copyright line.

+.. _FileAttributionSponsor:
+
+Attribution for Sponsored Development
+-
+
+A lot of development in RTEMS is sponsored by some users. If the
sponsor wants
+to be mentioned in the code, apply the following rules:
+
+* The attribution has to be a separate comment block below the
copyright

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

2021-09-27 Thread 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.


On Mon, Sep 27, 2021, 9:49 AM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> This adds some rules how an attribution for sponsored development should
> look like.
> ---
>
> Note: This patch is more or less an early draft. See the following
> discussion
> for more background:
>
> https://lists.rtems.org/pipermail/devel/2021-September/069465.html
>
> Points that need discussion:
>
> * Are there some areas where we don't want to have attribution lines (Chris
>   asked about score in the linked discussion). From my point of view: If
> there
>   is a big contribution and the sponsor wants his name in the (changed)
> files,
>   that's OK.
>
> * Do we want attributions in documentation sources? I'm not sure whether
> they
>   might end in HTML comments in the distributed documentation.
>

So far, not enough small has been submitted to matter.

I'm happy with a master list

>
> * What kind of format do we want in the documentation? Restructured Text
>   documentation suggests that the two dots should be on a separate line to
> avoid
>   interpreting the comment as directive:
>
> https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#comments
>
> * Do we need some kind of "signed off" from the sponsor (or similar) in the
>   commits that add attribution so that we can later tell who said that it
> is OK
>   that we mention the sponsor?
>

We've done this on trust for a long time but wouldn't git blame tell us the
same? If it is a manager without git, then what?


> I'm sure there are some more points. Please feel free to ask. Again: This
> is a
> draft.
>
> Best regards
>
> Christian
>
>  eng/coding-file-hdr.rst | 48 +
>  1 file changed, 48 insertions(+)
>
> diff --git a/eng/coding-file-hdr.rst b/eng/coding-file-hdr.rst
> index 3167670..da6f702 100644
> --- a/eng/coding-file-hdr.rst
> +++ b/eng/coding-file-hdr.rst
> @@ -2,6 +2,7 @@
>
>  .. Copyright (C) 2018, 2020 embedded brains GmbH (
> http://www.embedded-brains.de)
>  .. Copyright (C) 2018, 2020 Sebastian Huber
> +.. Copyright (C) 2021 Christian Mauderer
>
>  .. _FileTemplates:
>
> @@ -74,6 +75,28 @@ Check the top-level :file:`COPYING` file of the
> repository.  If you are a new
>  copyright holder, then add yourself to the top of the list.  If your last
> year
>  of a substantial contribution changed, then please update your copyright
> line.
>
> +.. _FileAttributionSponsor:
> +
> +Attribution for Sponsored Development
> +-
> +
> +A lot of development in RTEMS is sponsored by some users. If the sponsor
> wants
> +to be mentioned in the code, apply the following rules:
> +
> +* The attribution has to be a separate comment block below the copyright
> block.
> +
> +* Only the name of the sponsoring company / person should be mentioned. No
> +  contact details like URLs, email, phone numbers or street addresses
> should be
> +  added.
> +
> +* To avoid unnecessary commits, the name of a sponsor is not updated if
> (for
> +  example) the name of a company changes. The only reasonable change
> would be if
> +  a sponsor continues to pay for bigger changes in that file anyway.
> +
> +* Sponsor names are only added to files which contain relevant amounts of
> +  sponsored work. As a rule of thumb: If the work justifies adding a
> copyright
> +  line, it also justifies adding a sponsor line.
> +
>  .. _CCXXHeaderFileTemplate:
>
>  C/C++ Header File Template
> @@ -96,6 +119,8 @@ Use the following guidelines and template for C and C++
> header files (here
>  * Separate the Doxygen comment block from the copyright and license, so
> that
>the copyright and license information is not included in the Doxygen
> output.
>
> +* If there is a sponsor: Add it as a separate comment block.
> +
>  * For C++ header files discard the ``extern "C"`` start and end sections.
>
>  .. code-block:: c
> @@ -137,6 +162,12 @@ Use the following guidelines and template for C and
> C++ header files (here
>   * POSSIBILITY OF SUCH DAMAGE.
>   */
>
> +/*
> + * Initial foo bar implementation sponsored by Example Inc.
> + *
> + * Baz feature sponsored by Some LLC.
> + */
> +
>  #ifndef _FOO_BAR_BAZ_H
>  #define _FOO_BAR_BAZ_H
>
> @@ -204,6 +235,12 @@ and  placeholders see
> :ref:`FileHeaderCopyright`.
>   * POSSIBILITY OF SUCH DAMAGE.
>   */
>
> +/*
> + * Initial foo

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

2021-09-27 Thread Christian Mauderer 
This adds some rules how an attribution for sponsored development should
look like.
---

Note: This patch is more or less an early draft. See the following discussion
for more background:

https://lists.rtems.org/pipermail/devel/2021-September/069465.html

Points that need discussion:

* Are there some areas where we don't want to have attribution lines (Chris
  asked about score in the linked discussion). From my point of view: If there
  is a big contribution and the sponsor wants his name in the (changed) files,
  that's OK.

* Do we want attributions in documentation sources? I'm not sure whether they
  might end in HTML comments in the distributed documentation.

* What kind of format do we want in the documentation? Restructured Text
  documentation suggests that the two dots should be on a separate line to avoid
  interpreting the comment as directive:
  https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#comments

* Do we need some kind of "signed off" from the sponsor (or similar) in the
  commits that add attribution so that we can later tell who said that it is OK
  that we mention the sponsor?

I'm sure there are some more points. Please feel free to ask. Again: This is a
draft.

Best regards

Christian

 eng/coding-file-hdr.rst | 48 +
 1 file changed, 48 insertions(+)

diff --git a/eng/coding-file-hdr.rst b/eng/coding-file-hdr.rst
index 3167670..da6f702 100644
--- a/eng/coding-file-hdr.rst
+++ b/eng/coding-file-hdr.rst
@@ -2,6 +2,7 @@
 
 .. Copyright (C) 2018, 2020 embedded brains GmbH 
(http://www.embedded-brains.de)
 .. Copyright (C) 2018, 2020 Sebastian Huber
+.. Copyright (C) 2021 Christian Mauderer
 
 .. _FileTemplates:
 
@@ -74,6 +75,28 @@ Check the top-level :file:`COPYING` file of the repository.  
If you are a new
 copyright holder, then add yourself to the top of the list.  If your last year
 of a substantial contribution changed, then please update your copyright line.
 
+.. _FileAttributionSponsor:
+
+Attribution for Sponsored Development
+-
+
+A lot of development in RTEMS is sponsored by some users. If the sponsor wants
+to be mentioned in the code, apply the following rules:
+
+* The attribution has to be a separate comment block below the copyright block.
+
+* Only the name of the sponsoring company / person should be mentioned. No
+  contact details like URLs, email, phone numbers or street addresses should be
+  added.
+
+* To avoid unnecessary commits, the name of a sponsor is not updated if (for
+  example) the name of a company changes. The only reasonable change would be 
if
+  a sponsor continues to pay for bigger changes in that file anyway.
+
+* Sponsor names are only added to files which contain relevant amounts of
+  sponsored work. As a rule of thumb: If the work justifies adding a copyright
+  line, it also justifies adding a sponsor line.
+
 .. _CCXXHeaderFileTemplate:
 
 C/C++ Header File Template
@@ -96,6 +119,8 @@ Use the following guidelines and template for C and C++ 
header files (here
 * Separate the Doxygen comment block from the copyright and license, so that
   the copyright and license information is not included in the Doxygen output.
 
+* If there is a sponsor: Add it as a separate comment block.
+
 * For C++ header files discard the ``extern "C"`` start and end sections.
 
 .. code-block:: c
@@ -137,6 +162,12 @@ Use the following guidelines and template for C and C++ 
header files (here
  * POSSIBILITY OF SUCH DAMAGE.
  */
 
+/*
+ * Initial foo bar implementation sponsored by Example Inc.
+ *
+ * Baz feature sponsored by Some LLC.
+ */
+
 #ifndef _FOO_BAR_BAZ_H
 #define _FOO_BAR_BAZ_H
 
@@ -204,6 +235,12 @@ and  placeholders see 
:ref:`FileHeaderCopyright`.
  * POSSIBILITY OF SUCH DAMAGE.
  */
 
+/*
+ * Initial foo bar implementation sponsored by Example Inc.
+ *
+ * Baz feature sponsored by Some LLC.
+ */
+
 #ifdef HAVE_CONFIG_H
 #include "config.h"
 #endif
@@ -251,6 +288,10 @@ block. RTEMS uses ``"""`` for Python docstrings.
 # ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF 
THE
 # POSSIBILITY OF SUCH DAMAGE.
 
+# Initial foo bar implementation sponsored by Example Inc.
+#
+# Baz feature sponsored by Some LLC.
+
 If the Python source file is a command line command add the following as the
 first line of the file:
 
@@ -302,6 +343,10 @@ accept a ``#``-style comment block. For the , 
, and
 # ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF 
THE
 # POSSIBILITY OF SUCH DAMAGE.
 
+# Initial foo bar implementation sponsored by Example Inc.
+#
+# Baz feature sponsored by Some LLC.
+
 reStructuredText File Template
 --
 
@@ -314,3 +359,6 @@ Use the following template for reStructuredText (reST) 
source files.  For the
 .. SPDX-License-Identifier: CC-BY-SA-4.0
 
 ..