1. Enable the Linux subsystem and AppImage support
2. In the Linux folder, create a folder called Applications
3. Download the AppImage build of LibreOffice into the folder

That's it! ChromeOS will (probably) do the rest. Go to the applications menu (press the search button on the keyboard) and look in the “Linux Applications” group to launch LibreOffice. It's as easy as a Mac!

In more detail:

To enable the Linux subsystem:

ChromeOS is running on a Linux kernel but uses a container to sandbox locally-installed app. That capability is off by default.

1. Go to Settings (there are various routes you can take – the easiest is via the Settings icon on the app menu)
2. In the left navigation, click Advanced and select Developers
3. Enable the Linux Development Environment from this menu

To enable AppImage

1. AppImage uses the FUSE file system to access, so install FUSE.

To create the Applications folder:

This is optional – you could just put all your AppImage files into the Linux folder, but I find it easier to separate them out into their own folder. Linux apps can only see the Linux folder and its contents, so you can't put AppImage files anywhere else. Your documents will also need to live in or below the Linux folder.

1. Open the Files app
2. Under “My Files” in the left navigation, click on “Linux files”
3. Create a new folder (for example by pressing Ctrl+E) and name it Applications

To download the AppImage

1. On the LibreOffice web site, go to https://www.libreoffice.org/download/appimage/
2. For most people, the “Fresh, Standard” image is the best choice to download.
3. Place the download in your new Applications folder under the Linux folder.
4. If you have not previously installed Java you will probably have install a JRE.

ChromeOS should spot the AppImage file, create an icon for the application on the applications menu and connect it to the supported file types. If it does not, sorry – you will have to make the AppImage executable and run it from a command prompt.

I'm working on instructions for the “hard” things in this list, which I had overlooked because my ChromeBook was already set up suitably.

Notes, Tags and Mentions

• #Linux #OpenSource #LibreOffice #Desktop #OpenOffice #FOSS #FLOSS
• @libreoffice@fosstodon.org
• It's possible that my instructions miss a step or are affected by other AppImage tools I have installed. If so, please let me know and I'll fix it!
• I have a number of other desktop apps installed via this route, and then use AppImage Updater to keep them current (as long as the metadata in the package is correct).

Follow @webmink@the.webm.ink to be informed of new posts. To discuss this post please reply from Mastodon etc. (search for the URL) & include @webmink@meshed.cloud as WriteFreely still doesn't display replies. More.

What has powered open source to become part of 75% of all software and drive nearly €100 bn of GDP in Europe? Reuse, yes. But that was always possible. Collaboration, definitely. But repositories existed for years before open source was coined in 1998. The software freedom philosophy. Absolutely, but that went 15 years without triggering a software revolution. I suggest it's something less measurable and observable — developer confidence — and that the effects involved are stochastic, not deterministic.

No Confidence

As a result of the automatic global ownership of copyright by the authors of any software, no developer — even if supplied with the source code — may make much use of software written by others without being granted permission to do so. There are basically two ways such permission is granted:

• With a 1:1 contract — usually connected to a license fee or ongoing subscription fee but sometimes formed through agreement with the terms of an End User License Agreement (EULA).
• Through the terms of a general license available to the public at large, contingent on acceptance of the conditions in the license but without executing a contract.

Gaining the confidence to proceed in both cases involves studying the terms, understanding what is and is not permitted and understanding what duties must be performed. For most people, gaining confidence to proceed involves obtaining legal advice, which usually means paying for it. For most of us, that means not reaching a position of confidence.

It's Software Freedom All The Way Down

In large part this is addressed by the philosophy of Software Freedom that evolved from Richard Stallman's early experiences. Software Freedom ensures all uses are expressly permitted (with conditions) by having the author(s) grant permission in advance, with the goal of every recipient of the software being self-sovereign. But the philosophy needs a vehicle to become real.

The software license does that. It leverages the need for a copyright license to create an opportunity to deliver all the rights necessary to “enjoy” the software. By enjoy, I mean the rights to use, improve, share and monetise the software, for any purpose, in any place and in any combination, subset or superset. All necessary rights are assumed to be granted unless stated otherwise.

Uncertain About Freedoms

These freedoms definitely provided a foundation for developers to have confidence they had code they could reuse and collaborate over. But the freedoms were only definitely available under the GPL family of licenses – any others needed an opinion from a gatekeeper who worked opaquely. Using only the GPL family was controversial because of the “copyleft” provisions that seemed to some who had been working in the open for decades to force adherence to an ideology with which they did not identify. So people tried their hand at writing other licenses.

In the late 1990s, more and more products were claiming they were using “free software licenses” but there was no way to be sure they objectively delivered software freedom in your own circumstances, at least until the FSF had commented. Even then legal advice would likely be necessary given the monochrome view FSF tended to have. Worse, the “free software” term was being used casually in support of proprietary models accompanied by custom licenses, so the risks were not imaginary.

Grey Areas

What drove creation of new licenses? Every software project and its anticipated usage has its own context, so even the simplest licenses work in different ways for different people. In particular, some users prefer to take software that has been freely offered to them and use it as the basis of software that is offered restrictively to others, perhaps even avoiding attributing their work to its original authors. But away from that extreme, there are many dimensions to consider and, wise or not, there's a license embodying each of them.

Having many licenses may be a source of choice and diversity, but in every case the key question a developer will ask is “can I use that code?” There are licenses that are highly burdensome to comply with, licenses that use copyleft in a way that is incompatible with the way it's used by other licenses, licenses that lack clear patent grants, and many more. Which licenses deliver software freedom under conditions you can accept?

Not everyone has a lawyer (or easy access to a software freedom guru), and of course even people with a lawyer may not really want to ask every single time they see a new license. So, lacking confidence to proceed, developers avoid new licenses. This lack of developer confidence had a chilling effect and held back a wave of open collaborative development which in turn meant software freedom remained the privilege of an elite rather than a benefit for all.

Stochastic Confidence

Open source succeeded not by making things black-and-white but by clearing enough shades of grey to make things feel OK to the majority. It created stochastic confidence – enough confidence they had the freedom to reuse, collaborate and innovate for a critical mass of developers to gather and do so.

Collaborative evaluation against the Open Source Definition (OSD) was sufficient to give many people confidence there was a low probability of further permission-seeking. Crystalised and recorded by OSI, it created sufficient developer confidence to re-use code downstream from elsewhere. Yes, there were still uncertainties – but not enough to poison the network effect. OSI thus catalysed a network effect of collaboration and reuse by creating an open mechanism to create stochastic confidence in developer communities.

Compatible licensing also provides a vehicle for shared rights upstream. The level playing field of open licensing makes it possible to contribute improvements – making open source lower maintenance while remaining highly maintained collectively. Communities operating under a “license in = license out” basis see a free flow of code.

So the answer to why open source worked ultimately is a brew of factors that is hard to acknowledge for those with direct-causal minds – consensus on licenses, confidence about IPR grants, upstream contribution enablement and more. None of these factors alone is sufficient to trigger the network effect of open source development, reuse and collaboration. Neither is any factor alone sufficient to stop the effect if removed. Rather, it is a matter of moving members of the fourth sector from a fog of uncertainty to a point where they are confident to reuse, improve, contribute and innovate. Open source works via a stochastic effect that is hard to quantify yet undeniable.

Antipatterns

So what will break open source? Nothing so crude as a ban. Anything that lowers the stochastic confidence level below the point where the network effect works in a given context will do the job. Some causes of lower confidence/needing further permission:

• The need to license patents, especially in relation to standards
• DRM
• Geographical embargoes
• Contributor License Agreements (even a DCO will reduce adoption)
• Uncertainty in the interpretation of a license
• Licenses that have not been OSI approved
• Restrictions in the license. Conditions may be problematic if you don't want to comply with them but that's not a restriction. All OSI-approved licenses are permissive. All have conditions. None require negotiation – that would be a restriction.
• Compliance certification requirements
• Developer certification requirements

This is not to say all these things are certain to prevent an open source network effect triggering. Rather, each thing reduces the average level of confidence of part of the potential adoption community. This is the reality overlooked by corporations following their usual path to optimising short-term gains.

Notes, Tags and Mentions

• From a keynote address at FOSS-North, Gothenburg, April 2023
• According to Oxford Languages, stochastic means “having a random probability distribution or pattern that may be analysed statistically but may not be predicted precisely.”
• #OpenSource #FOSS #FLOSS #FreeSoftware #SoftwareFreedom #Causality
• The photo is my own, taken in the Everglades and actually a colour photo not B&W!

Follow @webmink@the.webm.ink to be informed of new posts. To discuss this post please reply from Mastodon etc. (search for the URL) & include @webmink@meshed.cloud as WriteFreely still doesn't display replies. More.

License compliance is a major and costly issue for proprietary software users, who must keep track of every use of the proprietary software they are licensing in order to avoid severe consequences should their supplier choose to conduct an audit. The license involved in that case is an End User License Agreement (EULA), not a source license delivering extensive liberties. When we compare like-for-like, we discover open source software has negligible issues by comparison. End-users do not need to have a license management server, do not need to hold audits, do not need to fear contract enforcement raids.

Open Source License Compliance Is A Marginal Issue

Do we need to worry about license compliance? Obviously respecting authors, following license terms and obeying the law are important, but for most of us the answer is probably that there are bigger things to worry about. Open source software comes with a set of liberties commonly called “the four freedoms“. Any software under an open source license may be used, studied, adapted, shared (both in the origonal and modified form) and monetised for any purpose, as long as the license is obeyed.

• As a user of the software, there are no conditions of any kind set on your use; you are free to use it for any purpose. There is no compliance requirement, even for the GPL. Pause and reflect on that for a moment. Open source does not place a compliance burden on the end user, does not mandate acceptance of an end-user license agreement, does not subject you to para-police action from the BSA. That is a significant advantage, and there’s no wonder that proprietary vendors want to hide it from you and make you think open source licensing is somehow complex, burdensome or risky. If all you want to do is use the software – which is all you are allowed to do with proprietary software as the other three freedoms are entirely absent – then open source software carries significantly less risk.
• If you move beyond use of the software and study the source code, there is also no compliance burden. There is no risk associated with using the knowledge you gain for other purposes. You do not become “tainted” in some way, and there is no need to create a “clean room” environment when you build related software using that knowledge. Those actions are related to trade secrets and public code is by definition not secret.
• If you move beyond studying the code and actually adapt it for your own use, there is unlikely to be a compliance burden. You are free to use the modified version in any way you wish, both personally and within your business. There is no need to account for your use, no need to send your improvements somewhere else, no requirement that you participate in the community. Of course, if you don’t you won’t get all the benefits associated from joining the community, but all the same the choice remains yours.
• If you move beyond modifying the code and decide to share your modified version, that is the point at which there will most commonly be compliance issues with the open source license. You only need to check you are passing on the same rights to others as you received with the original code. Even then, not all open source licenses place significant responsibilities on you. Licenses like the Apache, BSD, MIT and X11 licenses are extremely easy to comply with and licenses like the Mozilla license involve negligible housekeeping if you are participating in an open source community – simply committing code back to the community repository is likely to be enough. Only reciprocal licenses like the GPL family truly need an audit process, and even there it’s no more burdensome for most of us than the sort of tracking we would do anyway in our version control system.
• When it comes to the tiny minority who monetise open source software per se by shipping products containing it, there are issues that companies need to keep in mind, but in my view they are no more complex and burdensome than the issues arising from shipping proprietary software. It’s important to make sure you know you have the necessary rights to everything you ship, and when you ship code made from proprietary elements you naturally do so because the contract both requires it and enables sanctions if you don't. Only sloppy developers fail to do this.

Software Freedom Is Not About Licenses

The result of making it seem otherwise is that the more subtle opponents of open source are able to raise Fears about compliance, attaching Uncertainties soluble only via extra costs that aren’t really applicable to the majority of uses and thus seeding Doubts that the bother is really worth it. This has all the classic hallmarks of FUD, projecting the weakness of proprietary software and license enforcement “audits” and by implication tarring open source with them. We should reject the frame.

Ultimately, software freedom is not about licenses; they are a fundamental and essential part of the mechanics, but not the goal. The goal is for every software user to be self-sovereign in their software. It is about the liberty to enjoy software unhindered, and we are free to use that liberty as little or as much as we want without interference. Allowing ourselves to be distracted from the liberty which is the source of all of the benefits individuals and business gain from open source is a mistake. Don’t let the forces of proprietary software do it to you.  Reject the frame and revel in your liberty!

Tags, Notes and Mentions

• #OpenSource #SoftwareFreedom #FOSS #FLOSS
• Original version published November 2010

Follow @webmink@the.webm.ink to be informed of new posts. To discuss this post please reply from Mastodon etc. (search for the URL) & include @webmink@meshed.cloud as WriteFreely still doesn't display replies. More.

The choices we make are relevant to others only to the extent that they abridge the choices of other software users. It is never OK to bully someone over their software freedom point-of-compromise.

• For choices which only affect the individual, it is polite and appropriate to start with the assumption the individual has mindfully considered their choices and to leave unspoken the differences one observes between those and one's own choices or a Utopian ideal. We can only truly know our own selfhood.
• For choices made by another person which affect oneself, it may be appropriate to politely ask why those choices are being made in such a way as to impose a loss of choice on oneself if they truly do. But in most cases where the abridgment is minor or avoidable, it is better to lead by example. It is rarely appropriate to hector and never OK to bully.
• For choices made by an organisation, it can be more appropriate to ask the organisation to justify their choices when they impose a loss of liberty on others. Even so, one should start out assuming they have considered the issue and reached a balanced compromise according to their mission and means.
• For organisations that choose to enjoy the benefits of software freedom themselves and then choose to withhold those freedoms from their customers, it is much more appropriate to question their decision and perhaps weight that decision heavily against any purchasing choices. If they pretend they are somehow open source while using licenses not generally accepted as delivering software freedom to all, public criticism is likely to be warranted – that's an abridgment too far.

What else is “an abridgment too far”? When I can only choose systems that leave me with no practical software freedoms, and when the person or organisation forcing that choice either has not considered the issue or in doing so has needlessly ignored software freedom as a key factor. In just these cases it may be reasonable to politely inquire why and then to go further if the response is unreasonable.

Tags, Notes and Mentions

• #OpenSource #FreeSoftware #SoftwareFreedom #FOSS #FLOSS #Terminology #Definition
• The image is my own, of a gull slipstreaming the air around the Manly Fast Ferry in Sydney harbour

Follow @webmink@the.webm.ink to be informed of new posts. To discuss this post please reply from Mastodon etc. (search for the URL) & include @webmink@meshed.cloud as WriteFreely still doesn't display replies. More.

But reciprocal patent licensing is very common in the software industry generally and open source in particular – it’s part of the terms of the Apache License for example – so the accusation seemed far more likely to be projection by the SEP-dependent legacy industries of Europe. One useful insight into the whispers to which DG COMP responded can be seen in the extra information AOM has added to its legal page in response to the matter. The questions they address have such obvious and innocuous answers that only express sophistry could have been behind such questions, given the sophistication of the actors involved.

This is all crucially important to open source software, and not just as an endorsement of reciprocal terms. While there are edge cases, generally open source projects avoid standards which embed royalty-due patents, not primarily because of the royalties but because of the need to submit to the control implied by privately negotiating terms with the patent holders – an obviously anti-competitive aspect for any market entrant, about which Europeans complain when others do it.

It only takes one patent aggressor to rob everyone of viable open source video, so it seems entirely reasonable to scrupulously maintain hygiene by requiring any beneficiary of AV1 to commit to waiving royalties (and thus their negotiation). AOM is creating standards expressly intended to allow implementation by open source projects, so their terms are both rational and reasonable … unless you want to keep open source out of your cozy market.

The clouds have not all dispersed. AOM’s licensing is unfortunately based on a non-OSI-approved license (for excellent reasons but still an issue). Hopefully this will become more and more unfashionable as open source expands its reach. Also significantly there are hostile patent pools which, unfathomably and without evidence their mountain of claims are actually essential, assert that the AV1 standards infringe patents in the pools.

But this is good progress and underlines that the “reciprocal” mechanisms so common in open source licenses are generally pro-competitive. Perhaps the Commission will now move on to ask why such an obviously anti-competitive arrangement as standards bodies permitting royalty-due patents in their specifications is still tolerated?

Notes, Tags & Mentions

• #OpenSource #FOSS #FLOSS #Patents #SoftwarePatents #SEPs #CODECs #AV1

Follow @webmink@the.webm.ink to be informed of new posts. To discuss this post please reply from Mastodon etc. (search for the URL) & include @webmink@meshed.cloud as WriteFreely still doesn't display replies. More.

They told me that they believed the term “free and open source software” was misunderstood² by the Commission to be two categories — proprietary software supplied without charge and software developed in the open under an OSI-approved license. They inquired and found that the team authoring the draft at the Commission very much intended to create an exception for proprietary software delivered at no charge, so have proposed this amended language to clarify the matter along with an amendment (129) defining “freeware” for absolute clarity.

I should add I have yet to meet anyone from the Commission who can substantiate this.

Notes, Tags and Mentions

1. The IMCO Amendments include this word in Amendment 66 and 120 and it is defined in Amendment 129.
2. My earlier article “Getting Back To A Social Frame” appears relevant here.

• #CRA #EUCRA #FOSS #FLOSS #IMCO #OpenSource #Freeware

Follow @webmink@the.webm.ink to be informed of new posts. To discuss this post please reply from Mastodon etc. (search for the URL) & include @webmink@meshed.cloud as WriteFreely still doesn't display replies. More.

When you say to a native English speaker that something is “free”, their first and dominant thought will most likely be about the price of the thing in question. “Free? I don't have to pay?” They may well go on to say “That sounds cheap – and probably inferior!” Yes, it is possible to redirect that initial impression to other ways of understanding “free” (“no, I mean free as in freedom”), but George Lakoff explained long ago that the initial linguistic “palette” from which we paint colours the interpretation of all future conceptual metaphors in the conversation – the initial metaphor sets a frame that interprets and thus constrains future discussion. Things are further complicated by the fact that, as it turns out the source code is indeed available without paying – in many cases as an installable binary – not as a goal but as a consequence of the embodied liberties.

As a result, when “free software” is invoked in English by a non-specialist, nuance concerning the liberty of the individual as self-sovereign in software is lost, and subsequent usage tends to be argued within a “price frame” not a “liberty frame”. So the dominant argument for at least a decade of the shift of free/open source to dominance was that free software is cheaper, saves money, doesn't require payment for licenses and so on. This led to emphasis on donating to projects, with even ambiguous terms like “contribute” and “give back” being understood monetarily – in terms of delivering compensatory value that is detached from social engagement or the enjoyment of software freedoms.

Even after many people switched to talking about “open source”, the frame set in early usage persisted, with people obsessed with price (“TCO”) over capability or potential. Today sustainability is seen mainly in terms of “paying the maintainers”, long after we should know better and first address the dynamics of inclusive governance. This is further magnified by actors who mostly eschew community trying to justify their sociopathy; as one community peer commented,

this is reinforced by the narratives from for-profit businesses struggling to find a successful business model, citing how users of the open-source licenced software they produced are not “giving back”.

Yet the communities in which I have participated have rarely sought money, at least initially. What they really wanted was for users to join in, for improved software to be made available to all, for the rights they enjoy to be available to others. Some seek to compel, others just to encourage, but all of these are concepts drawn from a social frame rather than from a price frame.

There's a deep irony to this, as proponents of the Free Software terminology have frequently accused proponents of the alternative phrase “open source” of losing the connection to user liberty. But in fact it does a better job setting the conceptual frame for outsiders to one where interpretation follows “open” to assume a lack of “closed”, the presence of freedoms to manipulate and use the source and the other attributes supposedly only advanced by the earlier phrase! The unintended conceptual metaphor invoked by “free” poisons whatever framing we apply and we need to consciously evade that effect.

This also reads on my reflections on volunteering. Once we are stuck in a price frame, we see participation in projects within that frame and talk about paid and unpaid volunteers as if that is the key qualification. We worry about sustainability in terms of “who is going to pay”. But the real issue with sustainability is not primarily about money, but more about the presence of skills and innovation within a community and the willingness of newcomers to stay. In turn that is frequently a function of the objective presence of software freedoms.

This is not to deny the valid criticism that the Open Source and Free Software movement has been subverted by those who want to use their liberty asocially or even antisocially in pursuit of profit. But it's just possible that the best way to cover that sociopathy is the invocation of a liberty-enhancing frame, rather than trying to work within the constraints of the price frame. We need to try harder to effectively apply social framing to open source if we are to address the issues we see around sustainability, ethical use and corporate annexation of our movement.

Tags, Notes and Mentions

• #OpenSource #Volunteer #Sustainability #FOSS #FLOSS #Terminology #Definition
• Inspired by comments in a Mastodon conversation, now auto-deleted.
• The image – of decor in a restaurant – is my own.

Follow @webmink@the.webm.ink to be informed of new posts. To discuss this post please reply from Mastodon etc. (search for the URL) & include @webmink@meshed.cloud as WriteFreely still doesn't display replies. More.