Idea for achieving the goel of sponsorlink without email and/or connection

[jelkevanhoorn]

What if:

• sponsorlink would check on repository level not on developer level (typically there is the choice made for the dependency)
• sponsorlink would only read a file e.g. .sponsorlink. This file could contain package names and the last date a donation is made.on behalf of the repository. E.g.

ThisAssmbly 2023-7-1
GitInfo 2023-6-9
Moq 2022-5-18

• all sponserlink does is check this file for the package name during the build. If it is not included or the date is not within the past year it will witte a message/reminder to sponsor (this message should NOT be a build warning. Otherwise you will get sudden build breaks with Warn=Error).
• Now developers have to ignore the message or yearly update the date(s) in the file.

If it would be like this it is clearly comply with everything. It is just reading a file (as is any buildsystem). Of course it is circumvented trivially, but I suspect developers will have a hard time updating these dates in commercial projects for packages that are heavily depending upon. If the project is rightly maintained with reviews etc., the issue will be discussed and morally people will know what is right and hopefully raise the issue within the company.

Bottomline, I suggest to have faith in fellow developers and just create a simple (yearly) reminder for each repository to do what is right. I am confident that will in the long run be much more effective than try to enforce this in any way. People will loose trust and/or find themself be blocked and find a workaround and forget about it.

Note: maybe it is even possible to add to the license that is is forbidden to add the package into the .sponsorlink file without making a donation for commercial projects. Then the legal implications will help developers arguing their proposal to donate within a company.

[kzu]

Thanks for the write-up @jelkevanhoorn. Good ideas! Please take a look at the current proposal which is very much along these lines.

The initial goal in that issue is to have a similar thing to your .sponsorlink proposal, but where the file contains a JWT that is signed by SL so that the check runs always locally/offline but can still verify the authenticity (and expiration) of it, all using a standard mechanism.

If you feel that adequately addresses most of your suggestions, feel free to close this issue and chime in on the other one!

I don't think it's even feasible to make not sponsoring have "legal implications" unless you change the project license to something non-OSS, which I'm trying my best to avoid.

Thanks again!

[jelkevanhoorn]

I think no install should be necessary, and it should work "out of the box" for a new developer working on a project. So maybe an ID could be added into the file to identify the sponsorship. But I would keep clear of the desire to be able to really check the sponsorship and play more on the morality of the developers. Morality and checks combined does not work as effective, i'm afraid.
My take is that is should be fixed easily on "project level" but the necessity to think about it should come back once in while (that's why I suggested yearly)
I'm not sure if it would become non-OSS when it is free to use with informational message during the build, and allow only to say that you sponsored when you really sponsored. But I do not have a legal background :)

Feel free to close the issue, all I wanted to say is that it can be done much more easily when you decide to trust the intentions of fellow developers and just create a way to generate friendly reminders.

[kzu]

play more on the morality of the developers

Hm, good point. So you think if this was way simpler and just honor-based, it would be enough to make oss sustainable? If so, why hasn't appealing to honor worked in npm where folks seem ok to just ignore the ask to sponsor whenever they build? Honest question. Perhaps it's an implementation issue (build message, nothing in-IDE). It seems that (at least on that ecosystem), folks aren't too bothered by messages requesting donations and simply ignore them.

[jelkevanhoorn]

I understand. However, if there is a cost free way to remove the messages, but with (possible) legal implications. I think the discussion within companies have a higher chance of being conducted. You need to motivate developers to start this discussion to be able to donate within a company. (they are not doing this themselves, too many projects and total costs (and frankly not their costs))
However, if it is too difficult to show why donating should be done (within a company). or if there is a way to fix and forget, nothing will happen. Otherwise, if it is too hard to comply (too many checks in place) developers will find a way around and are proud they found this way (instead of feeling the moral obligation to start the discussion about donation), or will just find another way and not use the package.

[kzu]

I've moved to an offline-checked manifest that hopefully fixes raised issues.