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.maude...@embedded-brains.de >>>>>> <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 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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
