* Re: Bug: JavaScript in HTML export not recognized by LibreJS as free [9.4.5 (9.4.5-16-g94be20-elpaplus @ /home/jorge/.config/emacs/elpa/org-plus-contrib-20210412/)]
2021-04-22 20:29 ` Anthony Carrico
@ 2021-04-23 1:42 ` Anthony Carrico
2021-04-26 12:43 ` Bastien
2021-04-26 12:45 ` Jorge P. de Morais Neto
2 siblings, 0 replies; 14+ messages in thread
From: Anthony Carrico @ 2021-04-23 1:42 UTC (permalink / raw)
To: Kyle Meyer, Jorge P. de Morais Neto; +Cc: Bastien, emacs-orgmode
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Bug: JavaScript in HTML export not recognized by LibreJS as free [9.4.5 (9.4.5-16-g94be20-elpaplus @ /home/jorge/.config/emacs/elpa/org-plus-contrib-20210412/)]
2021-04-22 20:29 ` Anthony Carrico
2021-04-23 1:42 ` Anthony Carrico
@ 2021-04-26 12:43 ` Bastien
2021-04-26 20:36 ` Anthony Carrico
2021-04-26 12:45 ` Jorge P. de Morais Neto
2 siblings, 1 reply; 14+ messages in thread
From: Bastien @ 2021-04-26 12:43 UTC (permalink / raw)
To: Anthony Carrico; +Cc: Kyle Meyer, emacs-orgmode, Jorge P. de Morais Neto
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?
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Bug: JavaScript in HTML export not recognized by LibreJS as free [9.4.5 (9.4.5-16-g94be20-elpaplus @ /home/jorge/.config/emacs/elpa/org-plus-contrib-20210412/)]
2021-04-26 12:43 ` Bastien
@ 2021-04-26 20:36 ` Anthony Carrico
2021-05-01 9:30 ` Bastien
0 siblings, 1 reply; 14+ messages in thread
From: Anthony Carrico @ 2021-04-26 20:36 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Bug: JavaScript in HTML export not recognized by LibreJS as free [9.4.5 (9.4.5-16-g94be20-elpaplus @ /home/jorge/.config/emacs/elpa/org-plus-contrib-20210412/)]
2021-04-26 20:36 ` Anthony Carrico
@ 2021-05-01 9:30 ` Bastien
0 siblings, 0 replies; 14+ messages in thread
From: Bastien @ 2021-05-01 9:30 UTC (permalink / raw)
To: Anthony Carrico; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Bug: JavaScript in HTML export not recognized by LibreJS as free [9.4.5 (9.4.5-16-g94be20-elpaplus @ /home/jorge/.config/emacs/elpa/org-plus-contrib-20210412/)]
2021-04-22 20:29 ` Anthony Carrico
2021-04-23 1:42 ` Anthony Carrico
2021-04-26 12:43 ` Bastien
@ 2021-04-26 12:45 ` Jorge P. de Morais Neto
2021-04-26 16:57 ` Bastien
2 siblings, 1 reply; 14+ messages in thread
From: Jorge P. de Morais Neto @ 2021-04-26 12:45 UTC (permalink / raw)
To: Anthony Carrico, Kyle Meyer; +Cc: Bastien, emacs-orgmode
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Bug: JavaScript in HTML export not recognized by LibreJS as free [9.4.5 (9.4.5-16-g94be20-elpaplus @ /home/jorge/.config/emacs/elpa/org-plus-contrib-20210412/)]
2021-04-26 12:45 ` Jorge P. de Morais Neto
@ 2021-04-26 16:57 ` Bastien
2021-04-27 17:57 ` Jorge P. de Morais Neto
0 siblings, 1 reply; 14+ messages in thread
From: Bastien @ 2021-04-26 16:57 UTC (permalink / raw)
To: Jorge P. de Morais Neto; +Cc: emacs-orgmode, Kyle Meyer, Anthony Carrico
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Bug: JavaScript in HTML export not recognized by LibreJS as free [9.4.5 (9.4.5-16-g94be20-elpaplus @ /home/jorge/.config/emacs/elpa/org-plus-contrib-20210412/)]
2021-04-26 16:57 ` Bastien
@ 2021-04-27 17:57 ` Jorge P. de Morais Neto
0 siblings, 0 replies; 14+ messages in thread
From: Jorge P. de Morais Neto @ 2021-04-27 17:57 UTC (permalink / raw)
To: Bastien; +Cc: emacs-orgmode, Kyle Meyer, 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?]]
^ permalink raw reply [flat|nested] 14+ messages in thread