adding two more microposts

3 files changed, 137 insertions, 0 deletions

diff --git a/assets/e21stream.png b/assets/e21stream.png
new file mode 100644
index 0000000..ca63df9
--- /dev/null
+++ b/assets/e21stream.png
diff --git a/microposts/gpl-or-later.org b/microposts/gpl-or-later.org
new file mode 100644
index 0000000..c76575c
--- /dev/null
+++ b/microposts/gpl-or-later.org
@@ -0,0 +1,78 @@
+#+title: The useful GPL "or later" clause
+
+#+date: <2021-12-06>
+
+Ariadne Conill wrote a piece on GPL "or later" clause.  I made a comment about two weeks ago, which was under moderation but has not appeared as of today.  So I decided to publish it below (with some minor edits).
+
+The article says:
+
+#+begin_quote
+The primary motive for the version upgrade clause, at the time, was quite simple: the concept of using copyright to enforce software freedom, was, at the time, a new and novel concept, and there was a concern that the license might have flaws or need clarifications. 
+#+end_quote
+
+The main purpose of the -or-later clause is compatibility.  Any two (strong) copyleft licenses are incompatible.  If a program is licensed under GPLv2-only, it is incompatible with GPLv3.  Same goes for version 3: a GPLv3'd program will likely not be combinable with GPLv4'd programs.
+
+The article continues:
+
+#+begin_quote
+However, for all of the success of the GPLv3 drafting process, it must be noted that the GPL is ultimately published by the Free Software Foundation, an organization that many have questioned the long-term viability of lately.
+#+end_quote
+
+What long-term viability? According to <https://www.fsf.org/news/fsf-board-frequently-asked-questions-faq#FSFfinancialstatus>:
+
+#+begin_quote
+The FSF is in good financial health. As is the case with many organizations, the pandemic affected the FSF, impacting donors, making it impossible to host or attend in-person events, and disrupting operations. Fortunately, conservative financial planning over the years provided the FSF with sufficient reserves to weather these difficulties.
+
+The rating organization Charity Navigator recently gave the FSF its 8th consecutive 4-star rating and, for the first time ever, a perfect overall score: https://www.fsf.org/news/free-software-foundation-awarded-perfect-score-from-charity-navigator-plus-eighth-consecutive-four-star-rating.
+
+The FSF does not depend on large single sources of funding. It accepts and appreciates support from corporations who want to give back by contributing to the development and advocacy for free software, but direct corporate support accounted for less than 3% of FSF revenue in its most recently audited fiscal year.
+
+The vast majority of FSF’s financial support comes from individuals -- many, but not all, of whom choose to become associate members. At this moment, the FSF has more associate members than at any time in its history.
+#+end_quote
+
+The original article continues:
+
+#+begin_quote
+And this is ultimately the problem: what happens if the FSF shuts down, and has to liquidate? What if an intellectual property troll acquires the GNU copyright assignments, or acquires the trademark rights to the FSF name, and publishes a new GPL version? There are many possibilities to be concerned about, but developers can do two things to mitigate the damage.
+#+end_quote
+
+It is baked into GPL terms that future versions of the license have to be similar to the current version in spirit, see Section 14 of GPLv3 text, which protects GPL from the FSF:
+
+#+begin_quote
+The Free Software Foundation may publish revised and/or new versions of
+the GNU General Public License from time to time. Such new versions will
+be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+#+end_quote
+
+On the other hand, GPLv3-or-later, as its name implies, offer a *choice*.  The recipient of a program under this license can choose to apply GPLv3, or a future version e.g. GPLv4, if the future version is bad:
+
+<https://www.gnu.org/licenses/gpl-faq.html#VersionThreeOrLater>
+
+#+begin_quote
+If a tighter requirement in a new version of the GPL need not be obeyed for existing software, how is it useful? Once GPL version 4 is available, the developers of most GPL-covered programs will release subsequent versions of their programs specifying “Version 4 of the GPL or any later version”. Then users will have to follow the tighter requirements in GPL version 4, for subsequent versions of the program.
+
+However, developers are not obligated to do this; developers can continue allowing use of the previous version of the GPL, if that is their preference.
+#+end_quote
+
+Continues on the original article:
+
+#+begin_quote
+First, they can stop using the “or later” clause in new GPL-licensed code.
+#+end_quote
+
+This is a bad idea and likely harmful to the free software movement, because programs licensed under newer GPL will not be compatible with programs licensed under GPLv3-or-later.
+
+#+begin_quote
+Second, they can stop assigning copyright to the FSF. In the event that the FSF becomes compromised, for example, by an intellectual property troll, this limits the scope of their possible war chest for malicious GPL enforcement litigation. As we have learned from the McHardy cases involving Netfilter, in a project with multiple copyright holders, effective GPL enforcement litigation is most effective when done as a class action. In this way, dilution of the FSF copyright assignment pool protects the commons over time from exposure to malicious litigation by a compromised FSF.
+#+end_quote
+
+The copyright assignment enables the FSF as the copyright holder to enforce GPL effectively.
+
+The assignment contract safeguards the future of assigned work <https://www.fsf.org/bulletin/2014/spring/copyright-assignment-at-the-fsf>:
+
+#+begin_quote
+But the most important element of the assignment contract is the promise we make to every contributor and community member: We promise to always keep the software free. This promise extends to any successors in the copyright, meaning that even if the FSF were to go away the freedom of all users to share in the contributions wouldn't.
+#+end_quote
+
+Finally, note there is a difference between Creative Commons licenses and GPL regarding the -or-later variants.  GPL offers people the choice to use -only or -or-later, though FSF recommends the latter.  Contrast that with Creative Commons licenses where -or-later is built-in, and the recipient has no choice.
diff --git a/microposts/streaming-emacsconf.org b/microposts/streaming-emacsconf.org
new file mode 100644
index 0000000..70342a3
--- /dev/null
+++ b/microposts/streaming-emacsconf.org
@@ -0,0 +1,59 @@
+#+title: EmacsConf 2021 alternate streaming solution
+
+#+date: <2021-12-08>
+
+[[https://libreau.org][LibreAustralia]] hosted an [[https://libreau.org/past.html#emacsconf21][alternate EmacsConf 2021 stream for APAC timezones]] on 28th November.  It was a fun event to organise.
+
+How to stream an event like this with a fully free software stack?  Initially I envisioned a server streaming solution like I did with the inaugural event, by using ffmpeg to feed a local video file to icecast:
+
+#+begin_src sh
+ffmpeg -re -i ./video.webm -codec copy -content_type video/webm icecast://source:password@localhost:8000/live.webm
+#+end_src
+
+This works very well with one video, but with multiple videos one will need to [[https://trac.ffmpeg.org/wiki/Concatenate][concatenate them]].  The concat idea has two problems:
+
+1. Not all videos can be concatenated.  In fact, in most of the experiments, the output video could not play after the the portion corresponding to the first input video.
+2. There's absolutely no control of the playback.  Once the stream started, the whole event is scripted, and to adjust the schedule one has to kill the stream first.
+
+Problem 2 can be fixed by utilising the fallback mountpoint with fallback-override:
+
+#+begin_src xml
+<mount>
+  <mount-name>/live.webm</mount-name>
+  <fallback-mount>/fallback.webm</fallback-mount>
+  <fallback-override>1</fallback-override>
+</mount>
+#+end_src
+
+This way the stream never dies, provided a standby video plays on on the fallback mountpoint.
+
+Unfortunately not all videos can work smoothly between main the fallback mountpoints.  Some transitions cause unpleasant visual artefacts lasting for a dozen seconds, others (even worse) with audio turning into high-pitch scratching noise and never recovering.  For certain videos these problems even occur when a video transitions to itself.
+
+It may be possible to use ffmpeg to reencode videos that transitions smoothly, which is something to figure out for the future.
+
+That's pretty much a deadend in server streaming.
+
+On to desktop streaming, which offers the ultimate flexibility of playback control, but is heavier on bandwidth and computing resources.  One idea was OBS Studio, which unfortunately does not have icecast as one of its /streaming/ options, but rather requires a hack to /recording/ to an icecast mountpoint.
+
+I experimented with a setup from [[https://kelar.org/~bandali/][Amin Bandali]], which seems to me like using OBS Studio as an ffmpeg wrapper.  Unfortunately I would get segfault unless the stream is done with a minimal resolution.
+
+Inspired by [[https://libremiami.org][LibreMiami]]'s watch party, I decided to try out [[https://owncast.online/][Owncast]].  It was extremely easy to set up, and I could get an acceptable streaming performance with some low settings.
+
+However, as pointed out by Amin, owncast uses rtmp as the streaming protocol, which probably encodes to mp4, [[https://audio-video.gnu.org/docs/formatguide.html][a patent encumbered format]].
+
+How about streaming to BBB with screen share + monitor system audio as source?  It has a similar performance to owncast, but BBB requires javascript and is less accssible than icecast for viewers.
+
+What worked, in the end, was an direct ffmpeg to icecast streaming (thanks to [[https://sachachua.com][Sacha Chua]]):
+
+#+begin_src sh
+ffmpeg -loglevel 0 -ar 48000 -i default -re -video_size 1280x720 -framerate 25 -f x11grab -i :0.0+0,20  -cluster_size_limit 2M -cluster_time_limit 5100 -content_type video/webm -c:v libvpx -b:v 1M -crf 30 -g 125 -deadline good -threads 4  -f webm  icecast://source:pass@host:8000/live.webm
+#+end_src
+
+The captured area is shifted by 20 pixels in order not to grab the title bar of the player and emacs window.
+
+The performance of this approach was better than any of the other desktop streaming solutions, probably due to its bare ffmpeg setup without any bells and whistles.
+
+I also used an [[https://www.gnu.org/software/emms/][EMMS]] playlist to interlace the talk videos with standby music tracks.  If the buffer times between talks were not so short, the whole event could have been autopiloted with elisp [[https://www.gnu.org/software/emacs/manual/html_node/elisp/Timers.html][=run-at-time=]]!
+
+#+caption: Standby emacs session during the stream
+[[../assets/e21stream.png]]