You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 2, 2021. It is now read-only.
I’d prefer to give a specific, standard place to look as the default - Contributors.txt or some such. If that’s not present, then fall back on the current language.
This gives some guidance to new developers as to how they might use it, and gives a standard place to make at least a first look for those who have to comply.
The text was updated successfully, but these errors were encountered:
There is precedent for declaring a "magic file name" in a license. We've seen Suppfile.txt, license.txt, NOTICES, lrgrwrks.txt, the_framework_license.txt, manifest.txt, EXCEPTION, and so on.
But none of those file conventions have caught on as general conventions. There is still no reliable uniformity in which file contains the license terms to begin with, or if they appear in a file at all.
The @polyformproject does something a bit more generic, for notices:
Notices
You must ensure that anyone who gets a copy of any part of the software from you also gets a copy of these terms or the URL for them above, as well as copies of any plain-text lines beginning with Required Notice: that the licensor provided with the software. For example:
Polyform doesn't expect its own magic file, or files at all. That's far more technology-independent.
I won't pretend they're used uniformly, but a number of package managers already have well established metadata fields for author and contributor names. I'm not sure I want to pick a fight with existing conventions for expressing the same information, for largely the same reason. But I would like to offer more uniformity than "do what you know".
I’d prefer to give a specific, standard place to look as the default - Contributors.txt or some such. If that’s not present, then fall back on the current language.
This gives some guidance to new developers as to how they might use it, and gives a standard place to make at least a first look for those who have to comply.
The text was updated successfully, but these errors were encountered: