OFL-1.1 standard license header #451
Comments
Also from the FAQ, emphasis added:
Doesn't look to me as if the copyright/license/reserved font notices above the license text are intended to be used as a standalone header. |
|
I agree, and think they intend the full copyright+license in |
|
Ah, that's what you were saying already with "is the same as the license text". I didn't read closely enough! |
|
(Of course that's also how MIT/ISC/BSD are sometimes used as headers too, with header==full license.) |
|
On Sat, Oct 21, 2017 at 09:44:03PM +0000, Mike Linksvayer wrote:
Of course that's also how MIT/ISC/BSD are sometimes used as headers
too, with header==full license.
Good point. Any mechanism we use for “the standard license header is
the same as the license text” should get used for them as well, even
if that mechanism is “copy/paste the whole template under each tag”.
And on the “under each tag” front, I'd like to land #452 before we
start doing lots of XML-referencing or copy/pasting ;).
|
|
Can someone with push access re-open this? #491 did not address this issue. |
|
Re-opened as unaddressed. Does this need to be fixed for immediate release (next license list)? |
Not having the standard header marked up for these licenses reduces their usefullness. But we've never had their headers before, so I don't see a problem with punting to a later release. |
|
I think we'll punt to later release, esp. since this question affects many short licenses where the "header" might be the whole license. Not sure we need to declare anything for that case, as then you just have a license-text match, no? In ay event we can figure this out after the next license-list release. |
|
On Tue, Dec 19, 2017 at 09:51:02PM +0000, Bradlee H. Edmndson wrote:
Not sure we need to declare anything for that case, as then you just
have a license-text match, no?
Ah, I hadn't considered that angle. I'm ok with that, but if we go
that route I'd really like to see it called out in the documentation
(which is currently in [1], although I'd like to see documentation
that's local to this repo #495).
[1]: https://spdx.org/spdx-license-list/license-list-overview
|
|
As per the field description in https://spdx.org/spdx-license-list/license-list-overview
The Standard Header field is intentionally narrowly defined. There are, of course, lots of variations and there has been discussion of trying to capture some of those - perhaps in a different field so as not to confuse with what the license actually suggests. We have also discussed the idea of adding the SPDX-License-Identifier notice as has getting increased use (see https://github.com/ARM-software/arm-trusted-firmware/blob/master/bl1/bl1_fwu.c for example) and which is recommended in the spec, Appendix V. But for the time being, I think we will be consistent with our definition. |
|
From a consumer standpoint, there may also be a distinction between "upstream recommends you put the whole license in the header" and "upstream makes no recomendation about the header". So I'm back to thinking we'll (eventually) need some sort of explicit markup for this. |
Two changes here:
* Rename 'standardLicenseHeader' -> 'header'. We don't have other
header types to distinguish from, so we can use a shorter,
more-generic name.
* Make the header element a descendant of the text element (it used to
be a sibling). We may restore the possibility of siblings later,
but for now, the ancestor requirement makes it easy to enforce [1]:
F) Standard License Header
* Should only include text intended to be put in the header of
source files or other files as specified in the license or
license appendix when specifically delineated
...
* Leave this field blank if there is no standard header as
specifically defined in the license
This also makes it easy to cover licenses where the license text and
header are identical (e.g. the BSDs and the OFL [2]), because you
can use:
<text>
<header>
...
</header>
<text>
[1]: https://spdx.org/spdx-license-list/license-list-overview#fields
[2]: spdx#451
Two changes here:
* Rename standardLicenseHeader -> fileGrant. "License" is redundant
as long as we only include these for licenses, and would be
incorrect if/when we start supplying these for exceptions.
"standard" is also redundant as long as we are requiring these to
come from the license text itself (more on that below). "header"
alone might be confused with <h1>, etc., and is about where the
content shows up. fileGrant, on the other hand, is about what the
content *is*. In fact, the GPL family grants are generic enough to
be applied at the program level (as well as per-file), but the
file-specific "fileGrant" is more specific for licenses like
Apache-2.0 whose text only makes sense in a per-file context.
* Make the fileGrant element a descendant of the text element (it used
to be a sibling). We may restore the possibility of siblings later,
but for now, the ancestor requirement makes it easy to enforce [1]:
F) Standard License Header
* Should only include text intended to be put in the header of
source files or other files as specified in the license or
license appendix when specifically delineated
...
* Leave this field blank if there is no standard header as
specifically defined in the license
This also makes it easy to cover licenses where the license text and
fileGrant are identical (e.g. the BSDs and the OFL [2]), because you
can use:
<text>
<fileGrant>
...
</fileGrant>
<text>
[1]: https://spdx.org/spdx-license-list/license-list-overview#fields
[2]: spdx#451
Two changes here:
* Rename standardLicenseHeader -> fileGrant. "License" is redundant
as long as we only include these for licenses, and would be
incorrect if/when we start supplying these for exceptions.
"standard" is also redundant as long as we are requiring these to
come from the license text itself (more on that below). "header"
alone might be confused with <h1>, etc., and is about where the
content shows up. fileGrant, on the other hand, is about what the
content *is*. In fact, the GPL family grants are generic enough to
be applied at the program level (as well as per-file), but the
file-specific "fileGrant" is more specific for licenses like
Apache-2.0 whose text only makes sense in a per-file context.
* Make the fileGrant element a descendant of the text element (it used
to be a sibling). We may restore the possibility of siblings later,
but for now, the ancestor requirement makes it easy to enforce [1]:
F) Standard License Header
* Should only include text intended to be put in the header of
source files or other files as specified in the license or
license appendix when specifically delineated
...
* Leave this field blank if there is no standard header as
specifically defined in the license
This also makes it easy to cover licenses where the license text and
fileGrant are identical (e.g. the BSDs and the OFL [2]), because you
can use:
<text>
<fileGrant>
...
</fileGrant>
<text>
[1]: https://spdx.org/spdx-license-list/license-list-overview#fields
[2]: spdx#451
Two changes here:
* Rename standardLicenseHeader -> fileGrant. "License" is redundant
as long as we only include these for licenses, and would be
incorrect if/when we start supplying these for exceptions.
"standard" is also redundant as long as we are requiring these to
come from the license text itself (more on that below). "header"
alone might be confused with <h1>, etc., and is about where the
content shows up. fileGrant, on the other hand, is about what the
content *is*. In fact, the GPL family grants are generic enough to
be applied at the program level (as well as per-file), but the
file-specific "fileGrant" is more specific for licenses like
Apache-2.0 whose text only makes sense in a per-file context.
* Make the fileGrant element a descendant of the text element (it used
to be a sibling). We may restore the possibility of siblings later,
but for now, the ancestor requirement makes it easy to enforce [1]:
F) Standard License Header
* Should only include text intended to be put in the header of
source files or other files as specified in the license or
license appendix when specifically delineated
...
* Leave this field blank if there is no standard header as
specifically defined in the license
This also makes it easy to cover licenses where the license text and
fileGrant are identical (e.g. the BSDs and the OFL [2]), because you
can use:
<text>
<fileGrant>
...
</fileGrant>
<text>
[1]: https://spdx.org/spdx-license-list/license-list-overview#fields
[2]: spdx#451
Two changes here:
* Rename standardLicenseHeader -> fileGrant. "License" is redundant
as long as we only include these for licenses, and would be
incorrect if/when we start supplying these for exceptions.
"standard" is also redundant as long as we are requiring these to
come from the license text itself (more on that below). "header"
alone might be confused with <h1>, etc., and is about where the
content shows up. fileGrant, on the other hand, is about what the
content *is*. In fact, the GPL family grants are generic enough to
be applied at the program level (as well as per-file), but the
file-specific "fileGrant" is more specific for licenses like
Apache-2.0 whose text only makes sense in a per-file context.
* Make the fileGrant element a descendant of the text element (it used
to be a sibling). We may restore the possibility of siblings later,
but for now, the ancestor requirement makes it easy to enforce [1]:
F) Standard License Header
* Should only include text intended to be put in the header of
source files or other files as specified in the license or
license appendix when specifically delineated
...
* Leave this field blank if there is no standard header as
specifically defined in the license
This also makes it easy to cover licenses where the license text and
fileGrant are identical (e.g. the BSDs and the OFL [2]), because you
can use:
<text>
<fileGrant>
...
</fileGrant>
<text>
[1]: https://spdx.org/spdx-license-list/license-list-overview#fields
[2]: spdx#451
Two changes here:
* Rename standardLicenseHeader -> fileGrant. "License" is redundant
as long as we only include these for licenses, and would be
incorrect if/when we start supplying these for exceptions.
"standard" is also redundant as long as we are requiring these to
come from the license text itself (more on that below). "header"
alone might be confused with <h1>, etc., and is about where the
content shows up. fileGrant, on the other hand, is about what the
content *is*. In fact, the GPL family grants are generic enough to
be applied at the program level (as well as per-file), but the
file-specific "fileGrant" is more specific for licenses like
Apache-2.0 whose text only makes sense in a per-file context.
* Make the fileGrant element a descendant of the text element (it used
to be a sibling). We may restore the possibility of siblings later,
but for now, the ancestor requirement makes it easy to enforce [1]:
F) Standard License Header
* Should only include text intended to be put in the header of
source files or other files as specified in the license or
license appendix when specifically delineated
...
* Leave this field blank if there is no standard header as
specifically defined in the license
This also makes it easy to cover licenses where the license text and
fileGrant are identical (e.g. the BSDs and the OFL [2]), because you
can use:
<text>
<fileGrant>
...
</fileGrant>
<text>
[1]: https://spdx.org/spdx-license-list/license-list-overview#fields
[2]: spdx#451
|
Given the discussion above, and given the recommendation of the OFL stewards that the whole OFL text should be included in a font file, I'm inclined to say that it's correct that no standard license header is included here. Note also that the OFL identifiers were updated to include separate copyright notice formats for Reserved Font Names vs. not. Given all that, I would suggest closing this issue. |
|
Discussed on 2021-12-09 legal team call, agreed that no standard license header section should be added. |
We currently don't declare
standardLicenseHeaderfor the OFL-1.1, but they define one in their license document (above the title):And they also discuss their recommendations for using it in their FAQ:
The first point suggests they intend the full copyright/license to be used as you'd use the GPL-3.0 license text (for example), by dropping it in a project level file.
The “Also add this information to any other components (build scripts…” in the second point suggests they intend the full copyright/license to also be their standard license header. Our current XML schema doesn't provide an easy way to declare that the
standardLicenseHeaderis the same as the license text, but maybe it should? Perhaps via some generic XML reference mechanism? Otherwise we're going to have to duplicate this information in both places.The text was updated successfully, but these errors were encountered: