Monthly Archives: August 2020

Thinking about a license change to GPL for Tsugi

I have been rolling around an idea a switch to GPL as the core license of Tsugi and am curious as to what you think.
This is definitely a switch in direction – the Apereo Foundation (and Sakai Foundation before that) – has historically been very pro Apache (and its second cousin once removed ECL).
I have done some writing over the years that is not particular friendly to GPL:
But I have been GPL-curious for a long time:
Here is my 2020 summary of how we got here and where we might go from here:
– In 2003, GPL felt a lot more like an “infection” – commercial companies were scared to go near it in case the the GPL infection might spread to their proprietary products (i.e. like in the Ring movie – if you look at GPL code you are forever marked).   IBM built staffing firewalls where those who touched GPL code never interacted with “real” IBM engineers.
– Because of this, there was a notion that if you did GPL, companies would neither adopt nor help you.  Hence Sakai was militant pro Apache in 2004.
– In the by 2008, we kind of understood that modern companies were not afraid of GPL.  And frankly if a company was afraid of GPL – perhaps that was an indication that the company had a slightly different set of values w.r.t. open source.   And it turns out that one company back in 2004 that was the most vocal against GPL *did* have some big plans that were not entirely shared with us.  Thankfully that company is no longer in existence – due in part because their strategy was not as profitable as they had hoped :)
– In the early days, when we spent a lot of time “transferring copyright ownership” to the Foundation, using the Apache / ECL license felt better to a lot of folks.  But for “organically grown” code like Tsugi – and the new github world where collaborators flow in – it really does not matter.
If you look at my most blistering attack on GPL:
It is less an attack on GPL per se and more an attack on “who owns copyright”.
What has happened in the past decade is a change in approach to copyright “ownership”.  In the old days, Apache and Sakai/Apereo transferred “ownership” of the code to the Foundation.  And for the early part of Moodle – Martin Dougiamas owned all the code and any contributions were given to him.
Things are different today.  The Apache Foundation and Moodle lets contributors keep the copyright on their contributions and simply provide a non-expiring no limitations right to use.
This means that Moodle is no longer 100% owned by Martin.  It might be 80% owned by Martin (legacy) but 20% is owned but other people.  It is 100% *licensed* to the Moodle community and those licenses cannot be revoked.
This is a super important distinction as it has to do with the danger of someone like Martin or the Apereo Foundation going evil and selling their interest to some third party.   Yes this is unlikely that Apereo will go evil – but if there was a complete turnover of the board – we Apereo could quit-claim their interest to some proprietary company.
But with multiple “owners” like Moodle has, Martin can only “quit claim” 80% of the code.   The other 100 or so contributors also need to quit claim.  This effectively insures Martin can’t really do a meaningful quit claim.
Once the “who owns the code” and “who works on the code” is resolved – the difference between GPL and Apache is that GPL is harder to fork and go proprietary.  It is trivial to fork and go open source.
And the key *advantage* of GPL is that GPL is seen as an “activist” open source license.  Apache is pretty passive – there is little brand value to being Apache.  The Apache brand is about being very boring.  There *is* brand value being GPL because of the Free Software Foundation’s promotion of your product:
Sakai and Tsugi are not “open enough” to qualify as software that protects user freedom.
This might seem insignificant – but if by switching to GPL – we gain marketing and lose nothing – then why not.
Thoughts welcome.

Styling Tsugi / Koseu Lessons

I am developing a version of Lessons that can be heavily tweaked through CSS.  To do this I am revising the HTML output of Lessons to be more basic and semantic and therefore more easily tweaked by CSS.  The new default look and feel of Lessons looks like this (go into a lesson):
You can see some examples of how you can tweak the look and feel here (go into a lesson):
First you will notice that the carousel is gone.  It is actually not exactly gone – but if you put “videos” in a module it renders like the above two sites.  You can go back to the carousel by changing all of the “videos” keys in your lessons.json to “carousel” and poof the carousel will reappear.
There are two new features in lessons.json – take a look:
"headers": [
    "<link href=\"{apphome}/css/lessons.css\" rel=\"stylesheet\">"
],
"settings": {
    "prev-next": "right"
},
The headers is an array of text lines to add the the <head> part of lessons pages.  The {apphome} expands to the top URL for the site.  You can do a bunch of fun stuff here.  I load up some CSS.
You can see that I have added some classes to the tags in the Lessons module output that should let you get a handle on the markup and tweak it.
In my lessons.css I add a image based icon and a fontawesome based icon as well as tweak the list styles.
There is also a new settings area that allows us to tweak the UI here and there.  The first setting is whether you want the prev/next aligned right or full width.  The useful values for this are “right” and “full” – the default is “full” as you can see on WA4E.
This is a start to provide more options and a lot of flexibility without requiring a bunch of code changes every time folks want things to look different.