Legal Discuss
  1. Legal Discuss
  2. LEGAL-124

Are license headers really mandatory in every source file?

    Details

    • Type: Question Question
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Labels:
      None

      Description

      The Release FAQ says "Every source file must contain the appropriate ASF License text." http://www.apache.org/dev/release.html#which-files-contain-license

      The question often comes up if that really means MUST and if it means every single file in SVN or with a source distribution when a release is being made.

      I can't find any links now but thought i remember being told some years ago on legal-discuss was that the top level LICENSE file covers everything anyway so the individual license headers aren't strictly necessary especially for source files without significant IP. Could we get a opinion here on if thats true? So for example things like short README files perhaps don't need a license header or files without significant IP where the header can be problematic for some reason.

      Any opinions here either way?

        Activity

        Hide
        Henri Yandell added a comment -

        My first thought on a README is to have nothing. It's not valuable to us. Its purpose is to be a simple and easy to read overview.

        My second is that if it does need a notice, it should have the minimal one at the bottom of the README (and not the top). In the same way that we don't put website copyright notices at the top of the page. HTML documentation on the other hand can have comments that are visible in source form but not 'binary' (ie: when rendered in a browser).

        That would be covered by your approach, though I'm not sure if we'd have the same focus on only the docs that cover how to modify.

        Perhaps:

        • Text file - minimal notice at end of file.
        • Word & similar files - minimal notice in footnote.
        • HTML - License comment at top of file.
        Show
        Henri Yandell added a comment - My first thought on a README is to have nothing. It's not valuable to us. Its purpose is to be a simple and easy to read overview. My second is that if it does need a notice, it should have the minimal one at the bottom of the README (and not the top). In the same way that we don't put website copyright notices at the top of the page. HTML documentation on the other hand can have comments that are visible in source form but not 'binary' (ie: when rendered in a browser). That would be covered by your approach, though I'm not sure if we'd have the same focus on only the docs that cover how to modify. Perhaps: Text file - minimal notice at end of file. Word & similar files - minimal notice in footnote. HTML - License comment at top of file.
        Hide
        Lawrence Rosen added a comment -

        Craig, thanks for those clarifications. One minor change:

        No License Header is required for small files that have little creativity or little
        value, or when a License Header would detract from the usability of the file.

        Henri, does a README file get a full copyright notice and license header? In my own licenses, I use the following definition that includes a limited set of "documentation" :

        The term "Source Code" means the preferred form of the Original Work for making
        modifications to it and all available documentation describing how to modify the
        Original Work.

        /Larry

        Show
        Lawrence Rosen added a comment - Craig, thanks for those clarifications. One minor change: No License Header is required for small files that have little creativity or little value, or when a License Header would detract from the usability of the file. Henri, does a README file get a full copyright notice and license header? In my own licenses, I use the following definition that includes a limited set of "documentation" : The term "Source Code" means the preferred form of the Original Work for making modifications to it and all available documentation describing how to modify the Original Work. /Larry
        Hide
        Craig L Russell added a comment - - edited

        To summarize my opinion:

        No. License Headers are Not Mandatory in Every Source File.

        License Headers are required for source files in most cases.

        A short License Header can be used instead of the full License Header for small files with significant creativity, where the size of the License Header would detract from the usability of the file.

        No License Header is required for small files that have little creativity or little value, and a License Header would detract from the usability of the file.

        Wordsmithing the above will need a more focused discussion in a different forum.

        To Larry's 1: See above for my recommendation.
        To Larry's 2: I'm not suggesting dropping copyright notices from distributions. But please note that an ICLA is not an assignment of copyright to Apache. But Apache does claim a copyright on the work as a whole.
        To Larry's 3: Downstream users still have all the licenses, notices, and copyrights they used to have. We are only talking about the relaxing the rule under current policy that the 16 line header file must be included in all source files.
        To Larry's 4: The decision in 2006 was to move copyright notices from source files, leaving a License Header behind. Not remove them. We still require downstream users to be able to see all relevant copyright and license notices and licenses, including notices and licenses from works that projects choose to include in our distributions.

        Show
        Craig L Russell added a comment - - edited To summarize my opinion: No. License Headers are Not Mandatory in Every Source File. License Headers are required for source files in most cases. A short License Header can be used instead of the full License Header for small files with significant creativity, where the size of the License Header would detract from the usability of the file. No License Header is required for small files that have little creativity or little value, and a License Header would detract from the usability of the file. Wordsmithing the above will need a more focused discussion in a different forum. To Larry's 1: See above for my recommendation. To Larry's 2: I'm not suggesting dropping copyright notices from distributions. But please note that an ICLA is not an assignment of copyright to Apache. But Apache does claim a copyright on the work as a whole. To Larry's 3: Downstream users still have all the licenses, notices, and copyrights they used to have. We are only talking about the relaxing the rule under current policy that the 16 line header file must be included in all source files. To Larry's 4: The decision in 2006 was to move copyright notices from source files, leaving a License Header behind. Not remove them. We still require downstream users to be able to see all relevant copyright and license notices and licenses, including notices and licenses from works that projects choose to include in our distributions.
        Hide
        Henri Yandell added a comment -

        Larry: On #1 - 'source file' is a vague description and the reason for this issue report is because of that (the example in the summary is of a README, which is documentation and not source). I don't think you can answer this precisely, instead you give the PMCs the boundaries and weightings and allow them to make the call.

        On #3 - no one officially speaks for them. I'm here as a Commons committer for example. That said, there's a lot of knowledge of their use cases and requirements hovering around. In terms of Black Duck and Palamida - neither need the copyright statement in a file. The license information is much more critical, and without that they still have file checksums and code fingerprinting that allows them to match files.

        Craig - I'd go with:

        full Statement: the default, to be used in the vast majority of cases.
        mini Statement: small files for which the full Statement is overkill but there is creativity or the full statement would be a performance issue (eg: CSS + JavaScript).
        no Statement: small files for which any Statement is a distraction and there is no creativity or little value.

        Show
        Henri Yandell added a comment - Larry: On #1 - 'source file' is a vague description and the reason for this issue report is because of that (the example in the summary is of a README, which is documentation and not source). I don't think you can answer this precisely, instead you give the PMCs the boundaries and weightings and allow them to make the call. On #3 - no one officially speaks for them. I'm here as a Commons committer for example. That said, there's a lot of knowledge of their use cases and requirements hovering around. In terms of Black Duck and Palamida - neither need the copyright statement in a file. The license information is much more critical, and without that they still have file checksums and code fingerprinting that allows them to match files. Craig - I'd go with: full Statement: the default, to be used in the vast majority of cases. mini Statement: small files for which the full Statement is overkill but there is creativity or the full statement would be a performance issue (eg: CSS + JavaScript). no Statement: small files for which any Statement is a distraction and there is no creativity or little value.
        Hide
        Lawrence Rosen added a comment -

        Craig Russell wrote:
        > IMHO this JIRA is not the place to re-argue whether we need a copyright notice
        > in every file. That is a resolved issue as of 2006. To reopen it I'd suggest legal internal.

        FWIW, I'm -0 on your suggestion. But since, with the Berne Convention, the U.S. has eliminated most formalities associated with copyright, whatever copyright notices you omit won't generally matter, I'll not obstruct progress on this JIRA Legal-124.

        For the record, I'll make 4 additional comments:

        1. The question actually posed by this JIRA Legal-124 is: "Are license headers really mandatory in every source file." You are now narrowing the question to discuss specifically non-source files. You make unwelcome assumptions about the relationship between "creativity" and "source file". The terms "distraction" and "performance issues" are (perhaps intentionally?) vague. So I am not convinced that you have actually answered the question asked. How will you proceed to document your decision precisely?

        2. The legal value of a copyright notice, while slight, is not zero. See 17 USC 401(d) {"Evidentiary Weight of Notice"].

        3. Craig said he agrees that "the Statement is intended as a service to our downstream consumers...." Yet nobody here has discussed what policy our downstream consumers might prefer. Who here speaks for them? I will note that many consumers of Apache software ultimately run application security validators (such as Black Duck or Palamida), and without copyright notices they will know virtually nothing about those "source files"; I represent clients who rely on copyright notices to understand the provenance of the code and data that they use.

        4. I agree in general with the "stare decisis" philosophy, and Apache decisions taken in 2006 must be given respect. But I was not a member in those days, and I participated only in general discussions about this at ASF but then I was not welcomed to participate in that decision. I remember arguing very strongly then that copyright notices in source code ought to be both preserved and diligently written. For example, my own OSL 3.0 license contained the following requirement:

        You must retain, in the Source Code of any Derivative Works that You create,
        all copyright, patent, or trademark notices from the Source Code of the Original
        Work, as well as any notices of licensing and any descriptive text identified therein
        as an "Attribution Notice." You must cause the Source Code for any Derivative Works
        that You create to carry a prominent Attribution Notice reasonably calculated to inform
        recipients that You have modified the Original Work.

        So although you shouldn't expect me to support the 2006 Apache decision simply because it was then decided, nor will I object to your continuing to apply that decision in your response to this JIRA Legal-124.

        /Larry

        Show
        Lawrence Rosen added a comment - Craig Russell wrote: > IMHO this JIRA is not the place to re-argue whether we need a copyright notice > in every file. That is a resolved issue as of 2006. To reopen it I'd suggest legal internal. FWIW, I'm -0 on your suggestion. But since, with the Berne Convention, the U.S. has eliminated most formalities associated with copyright, whatever copyright notices you omit won't generally matter, I'll not obstruct progress on this JIRA Legal-124. For the record, I'll make 4 additional comments: 1. The question actually posed by this JIRA Legal-124 is: "Are license headers really mandatory in every source file." You are now narrowing the question to discuss specifically non-source files. You make unwelcome assumptions about the relationship between "creativity" and "source file". The terms "distraction" and "performance issues" are (perhaps intentionally?) vague. So I am not convinced that you have actually answered the question asked. How will you proceed to document your decision precisely? 2. The legal value of a copyright notice, while slight, is not zero. See 17 USC 401(d) {"Evidentiary Weight of Notice"]. 3. Craig said he agrees that "the Statement is intended as a service to our downstream consumers...." Yet nobody here has discussed what policy our downstream consumers might prefer. Who here speaks for them? I will note that many consumers of Apache software ultimately run application security validators (such as Black Duck or Palamida), and without copyright notices they will know virtually nothing about those "source files"; I represent clients who rely on copyright notices to understand the provenance of the code and data that they use. 4. I agree in general with the "stare decisis" philosophy, and Apache decisions taken in 2006 must be given respect. But I was not a member in those days, and I participated only in general discussions about this at ASF but then I was not welcomed to participate in that decision. I remember arguing very strongly then that copyright notices in source code ought to be both preserved and diligently written. For example, my own OSL 3.0 license contained the following requirement: You must retain, in the Source Code of any Derivative Works that You create, all copyright, patent, or trademark notices from the Source Code of the Original Work, as well as any notices of licensing and any descriptive text identified therein as an "Attribution Notice." You must cause the Source Code for any Derivative Works that You create to carry a prominent Attribution Notice reasonably calculated to inform recipients that You have modified the Original Work. So although you shouldn't expect me to support the 2006 Apache decision simply because it was then decided, nor will I object to your continuing to apply that decision in your response to this JIRA Legal-124. /Larry
        Hide
        Craig L Russell added a comment -

        Larry,

        IMHO this JIRA is not the place to re-argue whether we need a copyright notice in every file. That is a resolved issue as of 2006. To reopen it I'd suggest legal internal.

        Henri,

        I like your idea of having three types of files, at the discretion of the project leadership (PMC). I trust the PMC to decide which of the three is appropriate for each file, with some small bit of guidance:

        full Statement: the default
        Mini Statement: small files for which the full Statement is overkill but there is some creativity and a statement is desirable
        no Statement: small files for which any Statement is a distraction or a performance issue, or if the creativity is questionable

        Show
        Craig L Russell added a comment - Larry, IMHO this JIRA is not the place to re-argue whether we need a copyright notice in every file. That is a resolved issue as of 2006. To reopen it I'd suggest legal internal. Henri, I like your idea of having three types of files, at the discretion of the project leadership (PMC). I trust the PMC to decide which of the three is appropriate for each file, with some small bit of guidance: full Statement: the default Mini Statement: small files for which the full Statement is overkill but there is some creativity and a statement is desirable no Statement: small files for which any Statement is a distraction or a performance issue, or if the creativity is questionable
        Hide
        Henri Yandell added a comment -

        Craig: I like your mini-statement. No problem with the 'trivial creativity' position, but I don't think we should block ourselves by limiting it to whether we can claim copyright (and thus license) a file or not. There will be times where even the one liner is a distraction. Some of those could be resolved by putting the license at the foot of the file, others would need it not there (test data/conf files).

        Show
        Henri Yandell added a comment - Craig: I like your mini-statement. No problem with the 'trivial creativity' position, but I don't think we should block ourselves by limiting it to whether we can claim copyright (and thus license) a file or not. There will be times where even the one liner is a distraction. Some of those could be resolved by putting the license at the foot of the file, others would need it not there (test data/conf files).
        Hide
        Lawrence Rosen added a comment -

        Craig,

        I was suggesting that we put at minimum a 1-line copyright notice and licensing statement in (almost) every source code file. I apologize if that notice is a few words longer than the current recommended text, but I repeat my full suggestion anyway:

        Copyright (C) 2012 The Apache Software Foundation. Subject to Apache License 2.0.

        I think a copyright notice in source code files is both legally and practically useful. And a licensing statement is also very useful.

        Perhaps the term "source code" is understood too broadly. I certainly don't mean test data files; data bases; code that is intended to be executed directly; the text of bug reports; JIRA questions and responses; or any other small file whose author intends not to claim any copyright because she believes it to be too small or trivial.

        If you wish to give greater guidance than that, I'd like to review it first to see if it is overly prescriptive. It seems to me that a certain amount of judgment should be allowed as long as the intended goal is understood, namely to provide notice in (almost all) source code that The Apache Software Foundation claims a copyright.

        /Larry

        Show
        Lawrence Rosen added a comment - Craig, I was suggesting that we put at minimum a 1-line copyright notice and licensing statement in (almost) every source code file. I apologize if that notice is a few words longer than the current recommended text, but I repeat my full suggestion anyway: Copyright (C) 2012 The Apache Software Foundation. Subject to Apache License 2.0. I think a copyright notice in source code files is both legally and practically useful. And a licensing statement is also very useful. Perhaps the term "source code" is understood too broadly. I certainly don't mean test data files; data bases; code that is intended to be executed directly; the text of bug reports; JIRA questions and responses; or any other small file whose author intends not to claim any copyright because she believes it to be too small or trivial. If you wish to give greater guidance than that, I'd like to review it first to see if it is overly prescriptive. It seems to me that a certain amount of judgment should be allowed as long as the intended goal is understood, namely to provide notice in (almost all) source code that The Apache Software Foundation claims a copyright. /Larry
        Hide
        Craig L Russell added a comment -

        Larry,

        I'm surprised you are talking about putting copyright notices back into source files. We abandoned that practice years ago (November 1, 2006). We now only require in individual files a Statement (not a copyright notice, and not a license) that the file is distributed under the terms of the Apache License. http://www.apache.org/legal/src-headers.html#headers

        That Statement is 14 lines and seems wildly inappropriate for the files we're talking about, which comprise several lines of example code that is used to glue an application together. The files defy a rational definition of creative content.

        I agree with your comments that regardless of the inclusion or not of a copyright notice in each file, the work as a whole is able to be copyrighted, and in fact is copyrighted as a whole.

        I'm now reading between the lines...

        I agree with you that the Statement is intended as a service to our downstream consumers to give them confidence that they can include the source files in their own distributions by following the conditions of the referenced license http://apache.org/licenses/LICENSE-2.0

        If a project wants to omit the Statement in each trivial example file it's fine with me. It would be nice to give guidance to our projects that trivial example files or files with a minimum of creative content do not need to include the Statement in each file.

        If we're open to a "one liner" that can be used in place of the Statement, I'd offer this Mini Statement:

        /* Licensed under the terms of http://www.apache.org/licenses/LICENSE-2.0 */

        And I continue to suggest that it is appropriate in many cases to omit the Statement or Mini Statement for files that in the consensus opinion of the project have trivial creativity.

        Show
        Craig L Russell added a comment - Larry, I'm surprised you are talking about putting copyright notices back into source files. We abandoned that practice years ago (November 1, 2006). We now only require in individual files a Statement (not a copyright notice, and not a license) that the file is distributed under the terms of the Apache License. http://www.apache.org/legal/src-headers.html#headers That Statement is 14 lines and seems wildly inappropriate for the files we're talking about, which comprise several lines of example code that is used to glue an application together. The files defy a rational definition of creative content. I agree with your comments that regardless of the inclusion or not of a copyright notice in each file, the work as a whole is able to be copyrighted, and in fact is copyrighted as a whole. I'm now reading between the lines... I agree with you that the Statement is intended as a service to our downstream consumers to give them confidence that they can include the source files in their own distributions by following the conditions of the referenced license http://apache.org/licenses/LICENSE-2.0 If a project wants to omit the Statement in each trivial example file it's fine with me. It would be nice to give guidance to our projects that trivial example files or files with a minimum of creative content do not need to include the Statement in each file. If we're open to a "one liner" that can be used in place of the Statement, I'd offer this Mini Statement: /* Licensed under the terms of http://www.apache.org/licenses/LICENSE-2.0 */ And I continue to suggest that it is appropriate in many cases to omit the Statement or Mini Statement for files that in the consensus opinion of the project have trivial creativity.
        Hide
        Henri Yandell added a comment - - edited

        Even the one liner is unnatural Larry; though it is nicer for many cases. The one case you cover, that of 'source file' is most of the time utterly unarguable (web artifacts like CSS and JavaScript aside). It's all the other use cases that get fun.

        Treating all authored files as 'source files' means that lines of test data will lead to tests that have to skip the first line, html pages that will end up with half a dozen copyright statements as they're built from many snippets and readmes that start with a copyright statement.

        The one liner you suggest is nice for JavaScript files or for configuration files (assuming the config file supports comments).

        Perhaps create a table with three options:

        • Full source header
        • One line source header
        • None needed

        Then fill in the use cases on the RHS. Note that LICENSE.txt is one of the None needed items

        As you say it's a convenience to downstream users (and so accidental copying is more clearly wrong), so doing unnatural things should be avoided.

        Show
        Henri Yandell added a comment - - edited Even the one liner is unnatural Larry; though it is nicer for many cases. The one case you cover, that of 'source file' is most of the time utterly unarguable (web artifacts like CSS and JavaScript aside). It's all the other use cases that get fun. Treating all authored files as 'source files' means that lines of test data will lead to tests that have to skip the first line, html pages that will end up with half a dozen copyright statements as they're built from many snippets and readmes that start with a copyright statement. The one liner you suggest is nice for JavaScript files or for configuration files (assuming the config file supports comments). Perhaps create a table with three options: Full source header One line source header None needed Then fill in the use cases on the RHS. Note that LICENSE.txt is one of the None needed items As you say it's a convenience to downstream users (and so accidental copying is more clearly wrong), so doing unnatural things should be avoided.
        Hide
        Lawrence Rosen added a comment -

        At this point this JIRA thread has morphed so far that I'm confused about the original question. Fundamentally, isn't this really what you are asking:

        Is the following one-line license header the minimum necessary in every source file?

        Copyright (C) 2012 The Apache Software Foundation. Subject to Apache License 2.0.

        I'd suggest, "yes".

        Additional license headers can either be in the source file itself or in a separate LICENSE file. Based on Sebb's last sub-question, to avoid unnecessary parsing of source files that are meant to be interpreted or compiled each time they are executed, I'd suggest that we move such additional information to a separate LICENSE file. Otherwise, if it doesn't harm execution efficiency, put in longer license headers directly in source files.

        As for Craig's sub-question, whether some source files have such minimal creativity that their authors don't even want to waste time putting in a copyright notice: Right on! Some written works (such as this JIRA comment of mine!) don't need or deserve a copyright notice. That doesn't determine whether they are or are not copyrighted; the Berne Convention and US law eliminated all formalities of copyright long ago without eliminating copyright itself. Certainly nobody here is going to force me to put in my own copyright notices every time I write some contribution to Apache!

        It is primarily as a convenience to downstream licensees that we put at least the above Apache copyright notice in every Apache-distributed source file unless someone really can justify that it isn't worth wasting a single source file comment on the above notice.

        Beyond that, our goal is to pass on any important IP information that might be useful to downstream licensees of Apache software in the place(s) they are most likely to find it.

        /Larry

        Show
        Lawrence Rosen added a comment - At this point this JIRA thread has morphed so far that I'm confused about the original question. Fundamentally, isn't this really what you are asking: Is the following one-line license header the minimum necessary in every source file? Copyright (C) 2012 The Apache Software Foundation. Subject to Apache License 2.0. I'd suggest, "yes". Additional license headers can either be in the source file itself or in a separate LICENSE file. Based on Sebb's last sub-question, to avoid unnecessary parsing of source files that are meant to be interpreted or compiled each time they are executed, I'd suggest that we move such additional information to a separate LICENSE file. Otherwise, if it doesn't harm execution efficiency, put in longer license headers directly in source files. As for Craig's sub-question, whether some source files have such minimal creativity that their authors don't even want to waste time putting in a copyright notice: Right on! Some written works (such as this JIRA comment of mine!) don't need or deserve a copyright notice. That doesn't determine whether they are or are not copyrighted; the Berne Convention and US law eliminated all formalities of copyright long ago without eliminating copyright itself. Certainly nobody here is going to force me to put in my own copyright notices every time I write some contribution to Apache! It is primarily as a convenience to downstream licensees that we put at least the above Apache copyright notice in every Apache-distributed source file unless someone really can justify that it isn't worth wasting a single source file comment on the above notice. Beyond that, our goal is to pass on any important IP information that might be useful to downstream licensees of Apache software in the place(s) they are most likely to find it. /Larry
        Hide
        Sebb added a comment -

        I think that might lead to a lot of arguments about script and other files that are used in their source form, because the header would need to be parsed each time.
        For example css, javascript.

        Show
        Sebb added a comment - I think that might lead to a lot of arguments about script and other files that are used in their source form, because the header would need to be parsed each time. For example css, javascript.
        Hide
        Henri Yandell added a comment -

        Talking about creativity is very legal (yeah I know, we're on the legal JIRA).

        My suggestion would be to focus more on the impact:

        "Add license headers to all files unless it impacts the value of that file. Some examples of impacted files would be READMEs, test data, website includes. "

        Show
        Henri Yandell added a comment - Talking about creativity is very legal (yeah I know, we're on the legal JIRA). My suggestion would be to focus more on the impact: "Add license headers to all files unless it impacts the value of that file. Some examples of impacted files would be READMEs, test data, website includes. "
        Hide
        ant elder added a comment -

        Does anyone disagree with what was said here http://apache.markmail.org/message/ngxzn545hi22habw about not requiring license headers in things like README files? If not I'd like to do an update to make that more clear.

        Show
        ant elder added a comment - Does anyone disagree with what was said here http://apache.markmail.org/message/ngxzn545hi22habw about not requiring license headers in things like README files? If not I'd like to do an update to make that more clear.
        Hide
        Greg Stein added a comment -

        Translating Craig's extra sentence: "Files small that the license are deemed to be non-creative, so are not protectable."

        I don't think that is entirely correct, or preferable.

        (and yes, I do realize that the developer can say "it is short but important, so I'm gonna put in the header anyways"; we're talking about how lax we want the default rule)

        Show
        Greg Stein added a comment - Translating Craig's extra sentence: "Files small that the license are deemed to be non-creative, so are not protectable." I don't think that is entirely correct, or preferable. (and yes, I do realize that the developer can say "it is short but important, so I'm gonna put in the header anyways"; we're talking about how lax we want the default rule)
        Hide
        Craig L Russell added a comment -

        Reading the examples provided gives me the idea that there is little creativity. Most of the content is required by the xml formatting rules. Look at the files after removing the xml: result collapsible ID TITLE detail.

        That said, the rule is absolute. I'd prefer to have as policy a rule that changes:

        "A file without any degree of creativity in either its literal elements or its structure is not protected by copyright law; therefore, such a file does not require a license header. If in doubt about the extent of the file's creativity, add the license header to the file."

        to:

        "A file without any degree of creativity in either its literal elements or its structure is not protected by copyright law; therefore, such a file does not require a license header. Small files without significant creativity may omit the license if the license is more text than the source itself. If in doubt about the extent of the file's creativity, add the license header to the file."

        Show
        Craig L Russell added a comment - Reading the examples provided gives me the idea that there is little creativity. Most of the content is required by the xml formatting rules. Look at the files after removing the xml: result collapsible ID TITLE detail. That said, the rule is absolute. I'd prefer to have as policy a rule that changes: "A file without any degree of creativity in either its literal elements or its structure is not protected by copyright law; therefore, such a file does not require a license header. If in doubt about the extent of the file's creativity, add the license header to the file." to: "A file without any degree of creativity in either its literal elements or its structure is not protected by copyright law; therefore, such a file does not require a license header. Small files without significant creativity may omit the license if the license is more text than the source itself. If in doubt about the extent of the file's creativity, add the license header to the file."
        Hide
        Ate Douma added a comment -

        Thanks Sebb.

        That indeed was also my interpretation, that the #faq-exceptions only applies to very few cases, and only when there is no IP value to defend or explain.
        And the #faq-whyheader really is the more important paragraph on this, thanks for highlighting it!

        Show
        Ate Douma added a comment - Thanks Sebb. That indeed was also my interpretation, that the #faq-exceptions only applies to very few cases, and only when there is no IP value to defend or explain. And the #faq-whyheader really is the more important paragraph on this, thanks for highlighting it!
        Hide
        Sebb added a comment -

        @Ate
        That para only applies to files with no creativity. For example, a CSS file containing the single line:

        @import url("maven.css");

        would presumably be exempt.

        I think the quoted examples are more involved than that, and do involve creativity.

        ==

        @Ant: The paragraph here: http://www.apache.org/legal/src-headers.html#faq-whyheader explains why (almost) all files should have AL headers.

        Show
        Sebb added a comment - @Ate That para only applies to files with no creativity. For example, a CSS file containing the single line: @import url("maven.css"); would presumably be exempt. I think the quoted examples are more involved than that, and do involve creativity. == @Ant: The paragraph here: http://www.apache.org/legal/src-headers.html#faq-whyheader explains why (almost) all files should have AL headers.
        Hide
        Ate Douma added a comment -

        Seems to me this already has been asked and answered before: http://www.apache.org/legal/src-headers.html#faq-exceptions

        If not or incorrect, the above linked explanation also would need updating.

        Show
        Ate Douma added a comment - Seems to me this already has been asked and answered before: http://www.apache.org/legal/src-headers.html#faq-exceptions If not or incorrect, the above linked explanation also would need updating.
        Hide
        Scott Wilson added a comment -

        Just to add to this a concrete example: Wookie has a HTML templating system with a number of very simple HTML template source files for headers, footers etc that are concatenated into the final HTML page. If these include the full ASL header the end result is a lot of duplication.

        Examples:

        http://svn.apache.org/repos/asf/incubator/wookie/trunk/widgets/templates/browse/content_primary.html
        http://svn.apache.org/repos/asf/incubator/wookie/trunk/widgets/templates/browse/item_template.html
        http://svn.apache.org/repos/asf/incubator/wookie/trunk/widgets/templates/browse/item_summary_template.html

        Show
        Scott Wilson added a comment - Just to add to this a concrete example: Wookie has a HTML templating system with a number of very simple HTML template source files for headers, footers etc that are concatenated into the final HTML page. If these include the full ASL header the end result is a lot of duplication. Examples: http://svn.apache.org/repos/asf/incubator/wookie/trunk/widgets/templates/browse/content_primary.html http://svn.apache.org/repos/asf/incubator/wookie/trunk/widgets/templates/browse/item_template.html http://svn.apache.org/repos/asf/incubator/wookie/trunk/widgets/templates/browse/item_summary_template.html

          People

          • Assignee:
            Unassigned
            Reporter:
            ant elder
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:

              Development