updated rss

- also added a new mpost

3 files changed, 13 insertions, 6 deletions

diff --git a/microposts/gpl-or-later.org b/microposts/gpl-or-later.org
index c76575c..cb439bd 100644
--- a/microposts/gpl-or-later.org
+++ b/microposts/gpl-or-later.org
@@ -10,7 +10,7 @@ The article says:
 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 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 future GPLv4'd programs.
 
 The article continues:
 
@@ -45,11 +45,13 @@ 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:
+On the other hand, GPLv3-or-later, as its name implies, offers a *choice*.  The recipient of a program under this license can choose to apply GPLv3, or a future version e.g. GPLv4, and if the future version is bad all is not lost:
 
 <https://www.gnu.org/licenses/gpl-faq.html#VersionThreeOrLater>
 
 #+begin_quote
+Suppose a program says “Version 3 of the GPL or any later version” and a new version of the GPL is released. If the new GPL version gives additional permission, that permission will be available immediately to all the users of the program. But if the new GPL version has a tighter requirement, it will not restrict use of the current version of the program, because it can still be used under GPL version 3. When a program says “Version 3 of the GPL or any later version”, users will always be permitted to use it, and even change it, according to the terms of GPL version 3---even after later versions of the GPL are available.
+
 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.
@@ -61,7 +63,7 @@ Continues on the original article:
 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.
+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-only.
 
 #+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.
diff --git a/microposts/ombudsman-border.org b/microposts/ombudsman-border.org
new file mode 100644
index 0000000..474fd45
--- /dev/null
+++ b/microposts/ombudsman-border.org
@@ -0,0 +1,5 @@
+#+title: Ombudsman finds Victoria border permit system 'unjust'
+
+#+date: <2021-12-09>
+
+[[https://www.theage.com.au/politics/victoria/ombudsman-border-permits-were-downright-unjust-even-inhumane-20211206-p59fat.html][Link]]. Not the first time the Ombudsman has such findings about [[https://www.bbc.com/news/world-australia-55342990][pandemic measures taken by the Victorian Government]].
diff --git a/microposts/streaming-emacsconf.org b/microposts/streaming-emacsconf.org
index 70342a3..6e4a8b0 100644
--- a/microposts/streaming-emacsconf.org
+++ b/microposts/streaming-emacsconf.org
@@ -12,7 +12,7 @@ ffmpeg -re -i ./video.webm -codec copy -content_type video/webm icecast://source
 
 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.
+1. Not all videos can be concatenated.  In fact, in most of my 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:
@@ -27,7 +27,7 @@ Problem 2 can be fixed by utilising the fallback mountpoint with fallback-overri
 
 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.
+Unfortunately not all videos can move smoothly between the main and 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.
 
@@ -41,7 +41,7 @@ Inspired by [[https://libremiami.org][LibreMiami]]'s watch party, I decided to t
 
 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.
+How about streaming to BBB with screen share + monitor system audio as source?  A test with [[https://zaeph.net/][Leo Vivier]] showed that it has a similar performance to owncast.  The downside with BBB is that it 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]]):