remove nor & put names of languages in same order throughout
It's "not HTML, Javascript or CSS" (not nor - the initial negative carries through to all the enumerated elements. Garner, B. The Oxford Dictionary of American Usage and Style, Oxford University Press, 2000, pp. 230.) You should probably switch "Javascript" and "CSS" so all three are always in the same order.
Parity with two phrases already used in AGPLv3's main body.
AGPLv3§2 uses the phrase "output from running a covered work", so we use the same phrase here. §6(e) already uses the phrase "general public", and of course "propagate" is a defined term from AGPLv3§0.
This reworked definition of "Covered Output" better normalizes its definition to fit the standard terminology of AGPLv3, and also removes the 'deployed on a website'. We actually don't want to create the idea that deploying on the website is the only way to be eligible for the additional permission. The key issue is to assure that any items that receive the additional permission are distributed to the general public, as we want "one last step" of Affero requirement for the Covered Output, which only once available to the public can then be combined with other software more liberally.
Ditch the idea of "Package"; makes it all simpler.
The idea of being able to apply this to part of a repository was nice, but it complicates drafting by requiring us to define a term "Package" that is somehow a subset of the "Program" and "unmodified Program", which are terms already used in AGPLv3.
Perhaps later someone can find a way to extend this exception to work that way, but not today.
Defined term "Output" should be "Covered Output" instead.
The word "output" (undefined) is used quite a bit in the body of AGPLv3. Since an additional permission is read as part of the license itself, I don't think we should define the term (notwithstanding the apparent case sensitivity) -- particularly since some defined terms in AGPLv3 are not capitalized.
Furthermore, this reinforces that we're primarily concerned about Output that is a derived/derivative/combined work with a covered work under the License.
Wordsmith of Primary grant for Output under Output Licenses.
Clarify what comprises the Output that is under Output Licenses, giving a better bifurcation of the two types of works that can comprise it. We'll want flexibility for any content that didn't come for the Program, or has no reason to otherwise be a covered work.
Use "covered work", the defined term from AGPLv3 where possible.
AGPLv3 defines the term "covered work" already, which becomes the core phrase of strong copyleft throughout the existing License.
Using this term allows for various simplifications to the permission statement.
Furthermore, there is no reason that the licensor can (or really, should try to) grant or copyright permissions for works that aren't covered works.
Pam Chestek originally gave me this idea by making her change to §2¶2, pointing out that "works" was problematic there.
Finally, the use of the word "file" and "files" was already problematic. Most of the CSS/Javascript/HTML might not be in "files" of its own -- it may for example be inside print statements strewn throughout the covered work. Referring to them as "files" gave the wrong impression to start, something Eric Schultz had raised earlier in drafting.
Merge permission for modified/unmodified & expand permission scope
I don’t see any reason why unmodified and modified require different clauses, particularly since the first one also contemplates modifying (“modify any unmodified Output”). The second paragraph is correct and complete for both modified and unmodified.
The CC0 theoretically gives rights beyond propagating, conveying and modifying. These terms would be read as a limitation on the greater rights under the CC0, which I don't think is what's intended.
Finally, the added content may not be copyrightable, in which case they don’t get the additional permission under the prior revision.
Moved defined term to front, as is standard for a section called “Definitions”. This is stylistically consistent with the AGPL eliminates repetitiveness of second sentence.
Allow use exception in less than full package distribution.
Allows for more discrete use (i.e., less than the full distribution) and with more flexibility in how the additional permission is conveyed. Original sentence was verbose and definition of the term “Package” was in the wrong place.
Since Karen felt we needed to repeat the names of the licenses in the modified version paragraph, I've instead pulled that out as a defined term and used it throughout.
Add suspenders in addition to the belt to assure that even if the other text fails to contain the additional permission, the additional permission is at least contained to only Javascript, HTML and CSS.
Merge permission for modified Output into single permission
Based on feedback from Eric Shultz, I've merged the Javascript/CSS permission to work the same way as the HTML permission.
The goal is to give permission for downstream to incorporate unmodified HTML/CSS/Javascript with their own works, but assure that they don't copy parts of the otherwise AGPLv3'd codebase into that Output.
This redraft attempts to relicense all HTML, Javascript and CSS code, but in confined ways. I'm not sure if this solution will work, as it's an entirely different approach to the problem.
The Web Template Output Additional Permission for AGPLv3
This is the first draft of the Web Template Output Additional Permission for AGPLv3. The goal is to create an additional permission that will allow an otherwise AGPLv3'd work to output HTML, Javascript and CSS that is under different licenses.