Hi. The HTML export has JavaScript that LibreJS does not recognize as free. My first attempt at an workaround (inspired by the Org Mode mailing list) was merely encoding the ampersand in the magnet link, but that *did not make LibreJS happy*. Then I checked LibreJS manual and saw this excerpt: https://www.gnu.org/software/librejs/manual/librejs.html#Free-Licenses-Detection-1 Public domain is not a license (see https://www.gnu.org/licenses/license-list.html#PublicDomain). If you want to release your work to the public domain, the FSF recommends using CC0. Then I came up with a successful workaround. I included the following code in my Org Mode customization file: ;; [2021-04-16 sex]: HACK Work around a bug that confuses LibreJS (with-eval-after-load 'ox-html (setq org-html-scripts (string-replace "\ // @license magnet:?xt=urn:btih:e95b018ef3580986a04669f1b5879592219e2a7a&dn=public-domain.txt Public Domain" "\ // @license magnet:?xt=urn:btih:90dc5c0be029de84e523b9b3922520e79e0e6f08&dn=cc0.txt CC0-1.0" org-html-scripts))) This works; it makes LibreJS happy. Thank you for your work in Org Mode! Regards Emacs : GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0) Package: Org mode version 9.4.5 (9.4.5-16-g94be20-elpaplus @ /home/jorge/.config/emacs/elpa/org-plus-contrib-20210412/) -- - <https://stallmansupport.org> "In Support of Richard Stallman" - If an email of mine arrives at your spam box, please notify me. - Please adopt free/libre formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z. - Free/libre software for Replicant, LineageOS and Android: https://f-droid.org - [[https://www.gnu.org/philosophy/free-sw.html][What is free software?]]
Jorge P. de Morais Neto writes: > Hi. The HTML export has JavaScript that LibreJS does not recognize as > free. Thanks for noting this. That's certainly not ideal. > My first attempt at an workaround (inspired by the Org Mode mailing > list) was merely encoding the ampersand in the magnet link, but that > *did not make LibreJS happy*. Then I checked LibreJS manual and saw > this excerpt: > > https://www.gnu.org/software/librejs/manual/librejs.html#Free-Licenses-Detection-1 > > Public domain is not a license (see > https://www.gnu.org/licenses/license-list.html#PublicDomain). If > you want to release your work to the public domain, the FSF > recommends using CC0. > > Then I came up with a successful workaround. I included the following > code in my Org Mode customization file: Hmm, the public domain switched happen with 471054136 (ox-html.el: Use classList and put in the public domain, 2020-09-05) and the associated thread is https://orgmode.org/list/20200617002335.l4lg3slfxm74vx3h@silver/ (+cc author and committer) > ;; [2021-04-16 sex]: HACK Work around a bug that confuses LibreJS > (with-eval-after-load 'ox-html > (setq org-html-scripts > (string-replace "\ > // @license magnet:?xt=urn:btih:e95b018ef3580986a04669f1b5879592219e2a7a&dn=public-domain.txt Public Domain" > "\ > // @license magnet:?xt=urn:btih:90dc5c0be029de84e523b9b3922520e79e0e6f08&dn=cc0.txt CC0-1.0" > org-html-scripts))) > > This works; it makes LibreJS happy. Okay. Anthony/Bastien/others, thoughts on using CC0 instead?
Kyle Meyer <kyle@kyleam.com> writes:
> Jorge P. de Morais Neto writes:
>
>> Hi. The HTML export has JavaScript that LibreJS does not recognize as
>> free.
>
> Thanks for noting this. That's certainly not ideal.
>
>> My first attempt at an workaround (inspired by the Org Mode mailing
>> list) was merely encoding the ampersand in the magnet link, but that
>> *did not make LibreJS happy*. Then I checked LibreJS manual and saw
>> this excerpt:
>>
>> https://www.gnu.org/software/librejs/manual/librejs.html#Free-Licenses-Detection-1
>>
>> Public domain is not a license (see
>> https://www.gnu.org/licenses/license-list.html#PublicDomain). If
>> you want to release your work to the public domain, the FSF
>> recommends using CC0.
>>
>> Then I came up with a successful workaround. I included the following
>> code in my Org Mode customization file:
>
> Hmm, the public domain switched happen with 471054136 (ox-html.el: Use
> classList and put in the public domain, 2020-09-05) and the associated
> thread is
>
> https://orgmode.org/list/20200617002335.l4lg3slfxm74vx3h@silver/
>
> (+cc author and committer)
>
>> ;; [2021-04-16 sex]: HACK Work around a bug that confuses LibreJS
>> (with-eval-after-load 'ox-html
>> (setq org-html-scripts
>> (string-replace "\
>> // @license magnet:?xt=urn:btih:e95b018ef3580986a04669f1b5879592219e2a7a&dn=public-domain.txt Public Domain"
>> "\
>> // @license magnet:?xt=urn:btih:90dc5c0be029de84e523b9b3922520e79e0e6f08&dn=cc0.txt CC0-1.0"
>> org-html-scripts)))
>>
>> This works; it makes LibreJS happy.
>
> Okay. Anthony/Bastien/others, thoughts on using CC0 instead?
The error from libreJS is correct - public domain is not a valid
license.
As this is a GNU project and correct licensing is important, I don't
think there is any option other than to change the line to reference the
CC license (or any appropriate free license). If 'public domain' was
used due to some other issue, either we have to verify the code is
covered by a free (not just open source) license or replace it with code
that is and is acceptable by the FSF.
--
Tim Cross
Hi all. Thanks for the note. I took a look at the LibreJS docs to try to understand the problem. My analysis: LibreJS is a web filtering plugin. Users are making a decision to block content which is not explicitly licensed in the LibreJS syntax, including public domain works marked in that syntax. Apparently LibreJS is working as designed. I don't think we should attempt to work around a user's web filtering software. My understanding is that authors who want to get through the web filter should include an approved LibreJS license notice at the top of their page, and a separate license in a <script> when it conflicts with their chosen license. Practically speaking, the script included by org-mode is in the public domain, so it could never conflict with whatever license the author chooses. Therefore, we should remove the LibreJS tag from the <script>, perhaps leaving behind the public domain notice in the <script> comment. With that tag removed, the LibreJS web filter should respect whatever LibreJS license the document's author includes, if any. -- Anthony Carrico
On 4/20/21 12:55 AM, Tim Cross wrote: > The error from libreJS is correct - public domain is not a valid > license. Everyone is licensed to use public domain works (except to obtain a copyright on them). I think you mean that libreJS is working by design when it blocks them, which is apparently the case. > As this is a GNU project and correct licensing is important... Emacs is a GNU project, but org-mode export is a document processor, and the goal here was to avoid including licensed content in an Author's exported documents. -- Anthony Carrico
Anthony Carrico <acarrico@memebeam.org> writes: > On 4/20/21 12:55 AM, Tim Cross wrote: >> The error from libreJS is correct - public domain is not a valid >> license. > > Everyone is licensed to use public domain works (except to obtain a copyright on > them). I think you mean that libreJS is working by design when it blocks them, > which is apparently the case. What I meant is that Public Domain is not a license - it means the content cannot be copyrighted, which effectively means it is compatible with a free license, but the content lacks a formal license. The CCO also puts the content into the public domain, but also includes a formal license as a fallback, which can be beneficial in some jurisdictions. > >> As this is a GNU project and correct licensing is important... > > Emacs is a GNU project, but org-mode export is a document processor, and the > goal here was to avoid including licensed content in an Author's exported > documents. Appreciate the intention. Perhaps we need to clarify what exactly we are licensing here - the content or the Javascript added to the content to facilitate presentation. The content should be covered by whatever license the author prefers. The Javascript on the other hand, if generated by Org, should probably be covered by the GPL as it is 'created' by org. If the document author has not written the Javascript, I'm not sure they have the right to set the license on it, especially if it was generated as part of software covered by the GPL. The CC0 is appropriate for content which is in the public domain. It is essentially equivalent to public domain, but with a fallback trivial free license, which can be a useful addition in some jurisdictions. However, it is less suitable for software (i.e. Javascript) because it lacks any protection from patent trolling. -- Tim Cross
On 4/22/21 5:20 PM, Tim Cross wrote:
> Appreciate the intention. Perhaps we need to clarify what exactly we are
> licensing here
I'm sorry, I didn't realize that you were missing the context; it is a
tiny <script> tag. In a previous patch, a buggy GPL(3?) script was
replaced with an unlicensed public domain script to avoid inserting
licensed content into author's documents. This is similar to how GCC
avoids inserting licensed content into object files.
--
Anthony Carrico
On 4/22/21 4:29 PM, Anthony Carrico wrote:
> Practically speaking, the script included by org-mode is in the public
> domain, so it could never conflict with whatever license the author
> chooses. Therefore, we should remove the LibreJS tag from the <script>,
> perhaps leaving behind the public domain notice in the <script> comment.
> With that tag removed, the LibreJS web filter should respect whatever
> LibreJS license the document's author includes, if any.
I sent a patch to the mailing list to this effect, if it seems appropriate.
--
Anthony Carrico
Hi Anthony, thanks for your explanations around this issue. I made a mistake when applying your patch here: https://code.orgmode.org/bzg/org-mode/commit/471054136 https://orgmode.org/list/20200617002335.l4lg3slfxm74vx3h@silver/ The original Javascript lines were written by Carsten 12 years ago (time flies) with a4d72cbda, published under GPLv3+ by him. Because these lines were under GPLv3+, they needed to be advertized as such within the generated HTML, so adding the GPLv3+ license here was correct but my mistake was not to ask Carsten if he was okay releasing the lines in the public domain, since he was the author (sorry!) My current stand on this, is that publishing these lines under GPLv3+ is okay: it does not imply that the author of the generated HTML has any constraint regarding the license he wants to publish his contents under, because his contents is not a "derivative work" of these few Javascript lines. With respect to your example, the generated HTML (+js) page is not the result of including the Javascript code in a compilation process, and it's easy enough to separate the contents from these few lines. I reverted your initial patch in maint (29d21ea6). Still, the code enhancements you proposed there are still valid: would you be okay to place submit them again in another patch?
Hi all! Em [2021-04-22 qui 16:29:15-0400], Anthony Carrico escreveu: > Hi all. Thanks for the note. I took a look at the LibreJS docs to > try to understand the problem. I also took a look at the LibreJS docs, the linked article "The JavaScript Trap", and the text of the CC0. > LibreJS is a web filtering plugin. Users are making a decision to > block content which is not explicitly licensed in the LibreJS syntax, > including public domain works marked in that syntax. Apparently > LibreJS is working as designed. I don't think we should attempt to > work around a user's web filtering software. The purpose of LibreJS, from the Overview section of its manual, is to detect and block *nonfree* nontrivial JavaScript. Then the article [1] in the gnu.org website says "Please ensure these licenses are free and GPL-compatible." So if some script in a webpage is free software, then LibreJS users want it to run without issue, especially if its license is also GPL-compatible. Therefore, when a verifiably public domain script is blocked by LibreJS, LibreJS users (like me) get unhappy; this ought to be solved. 1: https://www.gnu.org/software/librejs/free-your-javascript.html "GNU Project - Releasing your JavaScript as Free Software" > My understanding is that authors who want to get through the web > filter should include an approved LibreJS license notice at the top of > their page, and a separate license in a <script> when it conflicts > with their chosen license. But document processors like Org Mode are supposed to automate everything than can reliably be automated. In fact, many document authors, having only partial existing technical knowledge about Org Mode and LibreJS, may find it nontrivial to fix the situation manually and therefore postpone (as I did) or ignore it. In fact I suppose the most common course of action would be ignoring it, because LibreJS unfortunately has too few users for most web authors to care. In fact, many will even be *unaware* of the issue. Yet this is important to us---the GNU community---because LibreJS is a fellow GNU project and because we adhere to free software ethics. And finally, from a pragmatic standpoint: simply "licensing" the script into the CC0 would make the users of GNU LibreJS happy and I really cannot see any downside or difficulty. In fact, I put "licensing" in quotes because it wouldn’t actually change the (absence of) terms of use; it would in fact only /clarify/ them. Did you read the text of the CC0[2]? It simply puts the work into the public domain, and then, as a /fallback/ for jurisdictions that would not recognize the public domain dedication, it provides a license that lets the user do anything she wants with the work. It does not even mandate that the license text be included with the work, not even with the source code (as copyfree software licenses usually require). Therefore, in my view, CC0 is *more* reliably public domain than an informal dedication that may not be legally valid everywhere. 2: https://creativecommons.org/publicdomain/zero/1.0/legalcode Regards -- - <https://stallmansupport.org> "In Support of Richard Stallman" - I am Brazilian. I hope my English is correct and I welcome feedback. - Free Software Supporter: <https://www.fsf.org/free-software-supporter> - If an email of mine arrives at your spam box, please notify me.
Hi Jorge,
Jorge P. de Morais Neto <jorge+list@disroot.org> writes:
> Therefore, when a verifiably public domain script
> is blocked by LibreJS, LibreJS users (like me) get unhappy; this ought
> to be solved.
this has just been resolved - see my other message today.
Legally, one could dispute the fact that these lines are copyrightable
because the code here is trivial and hardly qualifies as "orginal".
So I understand Anthony's willingness to put them in the public domain
and your proposal to put them under CC0, which is also valid. But I'd
rather stick to the GPLv3+, because there is no real issue about this
licensing of these lines.
I hope both you and Anthony agree with this, or at least recognize
that the current solution is acceptable.
I've trimmed the CC's, and condensed my answers to the various threads below: To Bastien: You are doing a good job respecting the code. Thank you. The original implementation flip-flops between cached and normal classes (six statements removed in the original patch), whereas my clone adds and removes a class name from the classList (three statements inserted in the original patch). I did intend to make a material change which would create a new public domain implementation of the original API. I did not intended to disrespect Carsten's work or to detract from it, and I apologize to anyone who did not consider it to be a good-faith gesture. I did honestly believe that the org-mode code base would welcome a public domain clone of the script functionality to resolve the issue at hand. To the other participants in the thread: To answer your questions, I have been around for the evolution of the FSF, the Open Source movement, and the Creative Commons. I did follow Lawrence Lessig's creation of CC0. I do understand its role. I have Richard Stallman's book on my shelf signed "Happy Hacking, Richard Stallman", and I understand that emacs is his baby. Next are Jessica Litman's and Clay Shirky's, and I also own Lawrence Lessig's and Siva Vaidhyanathan's (missing, somewhere...). I did attend Richard Stallman's lecture at Saint Michael's College, as well as Siva V.'s lecture at Middlebury College. I value the contributions of all these philosophers. I have attempted to look for solutions that would solve both bug reports (license insertion + LibreJS incompatibility) without advocating or offering opinions on the broader philosophical issues. I hope my technical contributions are valued, even if they are not accepted. I did offer an opinion on license insertion: My opinion is that org-export is a means to save an org-mode file in html format, and that org-mode authors don't view their documents as derivative works of the org-export markup. I still believe inserting a license into exported documents is a mistake. The FSF encourages authors to choose an approved license for their work, but my impression is that the FSF is also anxious to avoid the notion that their products will do so unintentionally. There is a danger that such an impression would erode their market share, and therefore their ability to advocate for their mission. This stance is apparent in the FSF signalling around project pairs like GCC/LLVM, etc., and I imagine it would apply to equally to emacs, so I think it would be wise to fix both issues if possible. Bastien: You certainly have my permission to use my CodeHighlightOn/CodeHighlightOff implementation as you see fit, including licensing it under the GPLv3+, and that is a reasonable choice for you to make. If you happen to agree with the notion that the org-export output should be license-free, and you want to avoid using a clone of these functions, a third option would be to remove the script in question: The functionality is pretty unusual for a document to trigger, and might not be missed in exchange for a javascript-free export, but I yield to your ultimate decision. Thank you -- Anthony Carrico
Hi Bastien Em [2021-04-26 seg 18:57:19+0200], Bastien escreveu: > I hope both you and Anthony agree with this, or at least recognize > that the current solution is acceptable. Yes, I find acceptable to license Anthony’s code under the GPLv3+, if that is what you meant. If you want to keep Carsten’s original code, that is acceptable too. And unfortunately I lack sufficient JavaScript knowledge to opine on which code is better---I studied Electronic Engineering, which didn’t include web development. Regards -- - <https://stallmansupport.org> "In Support of Richard Stallman" - If an email of mine arrives at your spam box, please notify me. - Please adopt free/libre formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z. - Free/libre software for Replicant, LineageOS and Android: https://f-droid.org - [[https://www.gnu.org/philosophy/free-sw.html][What is free software?]]
Hi Anthony, Anthony Carrico <acarrico@memebeam.org> writes: > The original implementation flip-flops between cached and normal > classes (six statements removed in the original patch), whereas my > clone adds and removes a class name from the classList (three > statements inserted in the original patch). Thanks - I replayed this change with commit dcd7b576b in maint. > I did intend to make a > material change which would create a new public domain implementation > of the original API. I did not intended to disrespect Carsten's work > or to detract from it, and I apologize to anyone who did not consider > it to be a good-faith gesture. I did honestly believe that the > org-mode code base would welcome a public domain clone of the script > functionality to resolve the issue at hand. Absolutely no need to apologize here! Sorry if my message was read as a reproach, it was definitely not. > I did offer an opinion on license insertion: My opinion is that > org-export is a means to save an org-mode file in html format, and > that org-mode authors don't view their documents as derivative works > of the org-export markup. I still believe inserting a license into > exported documents is a mistake. FWIW I also think inserting Javascript in HTML export is wrong. Commit bb24248b8 turns `org-html-head-include-scripts' to nil by default, I advertized the change in etc/ORG-NEWS. > Bastien: You certainly have my permission to use my > CodeHighlightOn/CodeHighlightOff implementation as you see fit, > including licensing it under the GPLv3+ Done, thanks for explicitely permitting this. In general, I tend to agree that we should get rid of this small Javascript snippet and that the feature provided is not critical, but let's keep it until someone shows that he can reactivate it with some existing Javascript library. Thanks, -- Bastien