Webmink In Draft

A Note On Who To Pay

Wed, 27 Nov 2024 23:00:00 +0000

In the context of my earlier essays about volunteering and social framing, the question recently arose of who should get paid when an open source project receives donations. The short answer is “people who make it happen but wouldn't get paid otherwise” but the thinking behind that is more complex than you might expect.

Open source is not meant to be free of charge. It is just meant to have no internal ledger (everyone contributor bears their own costs and derives their own benefit from the greater work) – but since open source has to make no distinction (internal=external) that also resolves as no external ledger, by accident. (Aside: This by the way is a major issue legislatively, where the “internal” development of open source code ends up regulated much more than that of proprietary code.)

But that's unfortunately led to a worldview that wants to treat all engagement with open source as philanthropic, denying those engaging in supporting roles any means of compensation and guilt-tripping anyone who needs support into silence. I call that “dictating other people's sacrifices” – it happens all over the charity sector too, where people seem to think skilled workers should work for peanuts “because it's a charity”. I try to make sure that all the places where I have a say pay as many people as they can all they should, and then leave it up to those people how to spend (or donate) the resulting income.

Tags, Links and Mentions

#OpenSource #Community #Sustaining #PayTheMaintainers #FreeSoftware #SoftwareFreedom #Governance #Notes

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.

Standards and the Presumption of Conformity

Tue, 26 Nov 2024 15:23:52 +0000

This post has graduated to the OSI Blog.

Access to the law includes access to the harmonised standards it predicates. But is it right that those standards can include royalty-due patents (SEPs)?

If you have been following the progress of the Cyber Resilience Act (CRA), you may have been intrigued to hear that the next step following publication of the Act as law in the Official Journal is the issue of a European Standards Request (ESR) to the three official European Standards Bodies (ESBs). What is that about? Well, a law like the CRA is extremely long and complex and conforming to it will involve a detailed analysis and a lot of legal advice.

Rather than forcing everyone individually to do that, the ESBs are instead sent a list of subjects that need proving and are asked to recommend a set of standards that, if observed, will demonstrate conformity with the law. This greatly simplifies things for everyone and leads to what the lawmakers call a “presumption of conformity”. You could go comply with the law based on your own research, but realistically that's impossible for almost everyone so you will instead choose to observe the harmonised standards supplied by the ESBs.

This change of purpose for standards is very significant. They have evolved from merely being a vehicle to promote interoperability in a uniform market – an optional tool for private companies that improves their product for their consumers – to being a a vehicle to prove legal compliance – a mandatory responsibility for all citizens and thus a public responsibility. This new role creates new challenges as the standards system was not originally designed with legal conformance in mind. Indeed, we are frequently reminded that standardisation is a matter for the private sector.

So for example, the three ESBs (ETSI, CENELEC and CEN) all have “IPR rules” that permit the private parties who work within them to embed in the standards steps that are patented by those private companies. This arrangement is permitted by the European law that created the mechanism, Regulation 1025/2012 (in Annex II §4c). All three ESB's expressly tolerate this behaviour as long as the patents are then licensed to implementors of the standards on “Fair, Reasonable and Non Discriminatory” (FRAND) terms. None of those words is particularly well defined, and the consequence is that to implement the standards that emerge from the ESBs you may well need to retain counsel to understand your patent obligations and enable you to enter into a relationship with Europe's largest commercial entities to negotiate a license to those patents.

Setting aside the obvious problems this creates for open source software (where the need for such relationships broadly inhibits implementation), it is also a highly questionable challenge to our democracy. At the foundation of our fundamental rights is the absolute requirement that first, every citizen may know the law that governs them and secondly every citizen is freely able to comply if they choose. The Public.Resource.Org case shows us this principle also extends to standards that are expressly or effectively necessary for compliance with a given law.

But when these standards are allowed to have patents intentionally embodied within them by private actors for their own profit, citizens find themselves unable to practically conform to the law without specialist support and a necessary private relationship with the patent holders. While some may have considered this to be a tolerable compromise when the goal of standards was merely interoperability, it is clearly an abridgment of fundamental rights to condition compliance with the law on identifying and negotiating a private licensing arrangement for patents, especially those embedded intentionally in standards.

Just as Regulation 1025/2012 will need updating to reflect the court ruling on availability of standards, so too should it be updated to require that harmonised standards will only be accepted from the ESBs if they are supplied on FRAND terms where all restrictions on use are waived by the contributors.

Links, Tags & Mentions

CRA Standards Request Draft Published

Sun, 28 Apr 2024 10:58:44 +0100

This article now forms part of an OSI position.

The European Commission recently published a public draft of the standards request associated with the Cyber Resilience Act (CRA). Anyone who wants to comment on it has until May 16, after which comments will be considered and a final request to the European Standards Organisations (ESOs) will be issued. This process is all governed by regulation 2012/1025, of which more in a future post.

This development is important for every entity that will have duties under the CRA (“manufacturers” and “software stewards”). Conformance with the harmonised standards that emerge from this process will allow manufacturers to CE-mark their software on the presumption it complies with the requirements of the CRA, without taking further steps.

For those who depend on incorporating or creating open source software, there is an encouraging new development found here. For the first time in a European standards request, there is an express requirement to respect the needs of open source developers and users. Recital 10 tells each standards organisation that

“where relevant, particular account should be given to the needs of the free and open source software community”

and that is made concrete in Article 2 which specifies:

The work programme shall also include the actions to be undertaken to ensure effective participation of relevant stakeholders, such as small and medium enterprises and civil society organisations, including specifically the open source community where relevant

and that requirement is made concrete in article 3 which requires proof that effective participation has been facilitated. The community is going to have to step up to help the ESOs satisfy these requirements – or have corporates masquerading as community do it instead.

Notes, Tags and Mentions

#Policy #CRA #OpenSource #FreeSoftware #SoftwareFreedom

Openly Shared

Thu, 25 Apr 2024 09:17:43 +0100

This article has moved to the OSI Blog.

The definition of “open source” in the most recent version (article 2(48)) of the Cyber Resilience Act (CRA) goes beyond the Open Source Definition (OSD) managed by OSI. It says:

“Free and open-source software is understood as software the source code of which is openly shared and the license of which provides for all rights to make it freely accessible, usable, modifiable and redistributable.”

The addition of “openly shared” was a considered and intentional addition by the co-legislators – they even checked with community members that it did not cause unintended effects before adding it. While open source communities all “openly share” the source code of their projects, the same is not true of some companies, especially those with “open core” business models.

For historical reasons, it is not a requirement either of the OSD or of the FSF's Free Software Definition (FSD) and the most popular open source licenses do not require it. Notably, the GPL does not insist that source code be made public – only that those receiving the binaries must be able to request the corresponding source code and enjoy it however they wish (including making it public).

For most open source projects and their uses, the CRA's extra requirement will make no difference. But it complicates matters for companies that either restrict source availability to paying customers (such as Red Hat) or make little distinction between available and non-available source (such as ForgeRock) or withhold source to certain premium elements.

A similar construct^{1} is used in the AI Act (recital 102) and I anticipate this trend will continue through other future legislation. Personally I welcome this additional impetus to openness.

Notes, Tags and Mentions

#CRA, #OpenSource, #Policy, #Europe, #FreeSoftware, #SoftwareFreedom
{1} The mention in the AI Act has a different character to that in the CRA. In the AI Act it is more narrative, restricted to a recital and is a subset of attributes of the license. In this form it actually refers to virtually no OSI-approved licenses. In the CRA the wording part of the formal definition in an Article, so much more impactful, and adds an additional requirement over the basic requirements of licensing.

Blasts From Pasts

Sat, 30 Mar 2024 11:52:47 +0000

On the recent surge of single-vendor open source projects switching to non-compete licensing

Two concepts from my early career seem mostly disregarded today in the wake of the popularisation of free software by the open source movement. One is software reuse; the other is source-available proprietary software.

Software reuse was a major thrust at IBM when I joined in 1990. IBM wanted its developers to reuse the work of others, but few developers were interested in learning to use someone else's approach to solving part of their problem even assuming they could find and be allowed access to the code that did it. Even within a single company, reuse without community was unwelcome; it is all the more so in a context where you may also need to negotiate rights.

I remember source-available from visits to data centres working for Burroughs (now Unisys) in the late 80s. Big piles of tapes (and later CDs) stood in the corner of machine rooms, mostly unopened. Having the source code may help some users fix their own installations, but generally the point of a paid service contract is to have experts do that for you. It seems contradictory to try to charge the people who want source – it flies in the face of the time-weathered wisdom of Mårten Mickos:

To make money on open source, you give it for free to those with more time than money, and you charge a fee from those with more money than time.

Both reuse and source-available faded from focus once open source software became dominant in the early days of the millennium. The only people mentioning either were those trying to pretend they were offering open source when their licensing said otherwise.

Blowing In From The Past

So who is interested in them today? Not software developers, who now expect the flexibility that comes from being given all the rights necessary to use, improve, share and monetise a piece of software without seeking further permission or even clarification from the copyright holders. Not software users, who want those same freedoms so they are protected from vendor control and gouging.

No, they have been rediscovered as values by rights-ratcheters looking for a sheepskin for their late-stage wolf. As well as enabling innovation and liberating users from lock-in, open source does an excellent job of driving adoption of good software. Developers will reuse it as part of their solutions and go on to fix bugs and add new capabilities. Users will deploy it with confidence and are more likely than not to spend money with experts to configure, deploy and extend it.

But that strength is open to abuse. When the control of the copyright becomes concentrated (either because a simple non-reciprocal license like MIT or BSD is in use or a copyright assignment is used by a single vendor), when the core committers are employees of a single vendor and (most importantly) when the company involved is running using borrowed money, there is a great risk that the rights-ratchet model will come into play.

Pioneered about 15 years ago by a company called SugarCRM, the rights ratchet model sees software taken through a seven stage process from fully open to fully closed, with just a ratchet-click of reduced freedoms and withdrawn rights at each step. With a flurry of new companies using open source to drive adoption at the turn of the first decade, we might expect there to have been a number of companies reaching the late stages of this model about now. Indeed, that is what has happened, with companies of that era such as MongoDB, Elastic, HashiCorp and now Redis reaching stage 6 and switching licenses in a way not generally benefiting the community. It's less a trend than an expected evolution that will pass with the model.

It is a detectable marker of the presence of the rights-ratchet model that its exploiters are keen to wrap themselves in “open” credentials. So they raise ideas from the past and attempt to re-animate them. Some even try to argue they are somehow “redefining open source”. A favourite sheepskin is the argument that they are just making open source sustainable and forcing freeloaders to pay fair shares of the cost of development.

Fair Shares?

That last argument is seductive – we all think the worker should be paid for their work, and have our own job and household as a model. But it's a mistaken view in most of these cases, just as is the political trope of comparing the budgeting of a national economy to a household budget. The whole point of open source, from day one, is that users are free to do what they want with the code and everyone involved is solely responsible for the dynamic and economics of their own involvement.

A company using an adoption-led business model understands this viscerally, and will always have a plan to accommodate it. None of the examples cited above has shown any indication of lacking sufficient funds to maintain, improve or even create a cash surplus from the project in question. Rather, every one of them has reached a point of success where they want to move on towards the next stage for their investors. After all, investors don't invest in products, they invest in exits.

So do we need a new model for open source that accommodates non-compete restrictions, as the apologists for each of these rights-ratchet changes assert? No, of course not. What we need is a way to help people know the ratchet is closing in on them so they can fork earlier.

No "Big Tech" in Europe

Thu, 01 Feb 2024 12:12:21 +0000

An interesting repeated motif in the anti-trust conference I attended yesterday in Brussels was the assertion that there is no big tech in Europe like there is in America and that Europe is sandwiched between big country (China) and big tech. The question I kept wanting to ask is “why is there nothing you recognise as 'big tech' in Europe?”

I did ask a few of the speakers this question and they seemed slightly bemused by it. The most stupid answer was someone who should know better saying Europe had spent all its energy on regulation and none of it on innovation – you may guess that was someone from the merger industry!

It's not like Europe has never had big tech. The dominant technologies in mobile phones arose from a European context and I can think of several other examples of world-monopolising technologies which have arisen in Europe in previous generations. I don't think it's overregulation either, although I defer to subject experts on that.

What I do wonder is whether the legacy big tech of the mobile & consumer electronics industries has resulted in the regulatory capture of European standards by the winners of that event, and that has led to the stifling of each new technology wave as it has commenced in Europe. What innovation has happened has then moved elsewhere to avoid the problem, usually by acquisition.

#Notes #Policy #BigTech

Una visión para LibreOffice

Sun, 17 Dec 2023 23:32:51 +0000

(English)

Me presento de nuevo a la reelección para la junta de The Document Foundation (TDF) como candidato independiente. Lo más importante que necesita TDF es una visión unificadora para el futuro de #LibreOffice, la principal herramienta de preparación de documentos #OpenSource. He aquí el esbozo de una visión que propondría a los Administradores y a la Junta Directiva en caso de ser elegido, obviamente evolucionada en colaboración con ellos.

¿Hacia dónde elegimos ir?

TDF existe para servir al público globalmente, no a las necesidades de ninguna corporación. En consecuencia, TDF no debería destinar el dinero donado a ofrecer a ninguna empresa una alternativa a Microsoft Office, ni a ningún proveedor de servicios una alternativa a Google Docs, ni a subvencionar innecesariamente a las empresas que se benefician de cada una de ellas.
Las actuales herramientas ofimáticas en línea son un servicio para los proveedores de la nube y los usuarios corporativos, pero tienen un valor limitado al servicio de la misión de TDF porque está fuera del alcance de casi cualquier usuario implantarlo por sí mismo. En lugar de animarnos a depender de los proveedores de servicios (incluso de buena fe), TDF debería limitar el compromiso con las versiones de servidor a desplegar una copia de Collabora Online como un peldaño para la evolución de TDF.
Sin embargo, LibreOffice de Escritorio debe ser capaz de interoperar con él, tanto a través del formato de archivo como en tiempo real.

P2P LibreOffice

Lo que más necesitamos es la colaboración peer-to-peer integrada en LibreOffice Desktop sin necesidad de un proveedor en la nube.
Lo ideal sería que también fuera interoperable con Collabora Online™, a través de una conexión en tiempo real
Necesitamos una plataforma neutral para que todas las versiones sean interoperables.
También deberíamos empezar a mirar más allá del paradigma del “documento”. Incluso los archivos adjuntos al correo electrónico son cada vez más raros; debemos tener en cuenta los sistemas de archivos distribuidos, los sistemas fediverse y otros contenedores de contenido.
Así que, como mínimo, también necesitamos soporte dentro de LibreOffice para sistemas de archivos distribuidos como IPFS, de modo que no dependamos de un sistema de archivos alojado para la colaboración.
También tiene que ser accesible sólo con un navegador, tal vez a través de un cliente Javascript ligero.
TDF debería estar gastando directamente su importante saldo de efectivo donado para hacer de LibreOffice una herramienta accesible y a prueba de futuro para todos los ciudadanos en todos los países y todos los idiomas, no en licitaciones a proveedores corporativos para arreglar errores que se necesitan arreglar pero que se no pueden arreglar económicamente.

Posibles caminos hacia el P2P

Esto podría lograrse adaptando la capacidad de acceso remoto de Collabora Online e integrándola en el Libreoffice de escritorio.
Se necesitaría un rediseño para que funcione para los usuarios normales sin intervención técnica, posiblemente utilizando librerías IPv6 como LibreCast.
Si estuviera disponible una versión accesible desde el navegador (WASM parece posible), también podría ser factible permitir a un usuario sin LibreOffice instalado colaborar peer-to-peer – en respuesta a una invitación individual – con sólo un navegador.

Una vez elegido, propondría esto como punto de partida para el Patronato y trataría de trabajar con los administradores para hacerlo evolucionar hacia una dirección consensuada para la Fundación.

Para discutir este post por favor responda desde Mastodon etc. (busque la URL) e incluya @webmink@meshed.cloud ya que WriteFreely todavía no muestra las respuestas.

Many thanks to Miguel Ángel for the translation of the original.

A Vision for LibreOffice

Wed, 13 Dec 2023 23:36:09 +0000

(Español)

I am standing for re-election to the board of The Document Foundation (TDF) as an independent candidate again. The most important thing TDF needs is a uniting vision for the future of #LibreOffice, the leading #OpenSource document preparation tool. Here is the outline of a vision I would propose to the Trustees and Board if elected, obviously evolved collaboratively with them.

Where are we choosing to go?

TDF exists to serve the public globally, not the needs of any corporation. Consequently TDF should not be directing donated money to give any company an alternative to Microsoft Office, nor to give any service provider an alternative to Google Docs, nor to unnecessarily subsidise the companies benefiting from each.
Today's online office tools are a service for cloud providers and corporate users, but of limited value in serving the mission of TDF because it is beyond the means of almost any user to deploy it themselves. Rather than encouraging us to become dependent on (even good-faith) service providers, TDF should limit engagement with server versions to deploying a copy of Collabora Online as a stepping-stone for TDF's evolution.
LibreOffice Desktop needs to be able to interoperate with it however, both via file format and in real-time.

P2P LibreOffice

What we most need is peer-to-peer collaboration built in to desktop LibreOffice without the requirement for a cloud provider
Ideally it should be interoperable with Collabora Online™ too, via real-time connection
We need this on a platform-neutral basis so every version is interoperable
We should also start looking beyond the “document” paradigm. Even e-mail attachments are becoming rarer; we need to consider distributed filesystems, fediverse systems and other content containers.
So as a minimum we also need support within LibreOffice for distributed filesystems such as IPFS so we are not dependent on a hosted filesystem for collaboration.
It also needs to be accessible just with a browser, maybe via a Javascript slim client.
TDF should be directly spending its significant donated cash balance to make LibreOffice a future-proof and accessible tool for every citizen in every country and every language, not on tenders to corporate suppliers to fix bugs that they need fixed but can't fix economically.

Possible paths to P2P

This could be achieved by adapting the remote access capability from Collabora Online and integrating it into desktop Libreoffice
It would need redesign to make it work for ordinary users without technical intervention, possibly using IPv6 libraries such as LibreCast.
If a browser-accessible build were available (WASM seems possible), it might also be feasible to allow a user without LibreOffice installed to collaborate peer-to-peer — in response to an individual invitation — with just a browser.

Once elected I would propose this as a starting point for the Board and seek to work with the Trustees to evolve it to a consensus direction for the Foundation.

LibreOffice on ChromeOS

Mon, 21 Aug 2023 13:05:25 +0100

If you are using an Intel-powered Chromebook, did you know you can install LibreOffice on it, as a local app? It's extremely easy!

Enable the Linux subsystem and AppImage support
In the Linux folder, create a folder called Applications
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.

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

To enable AppImage

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.

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

To download the AppImage

On the LibreOffice web site, go to https://www.libreoffice.org/download/appimage/
For most people, the “Fresh, Standard” image is the best choice to download.
Place the download in your new Applications folder under the Linux folder.
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).

(Still) Not Using Zoom

Mon, 07 Aug 2023 14:20:58 +0100

Dear client,

Setting aside the challenges of using Zoom under ChromeOS and Linux, I have mostly been declining invitations to Zoom calls because of the terms they introduced from April 2023 in section 10 of their Terms of Service which seemed to force every user, with no opt-out to the Terms available and with recourse only via arbitration, to agree that Zoom could (whether they currently do or not):

Train their AI on anything uploaded or created on Zoom (including transcripts and recordings) and use the consequent model for absolutely anything;
Have indefinite and ownership-equivalent rights to do so in the future and
Be indemnified by me if it turns out someone else owns the IP or has their rights infringed (for example to confidential materials everyone on the call is entitled to review).

Following public complaints they first tried to apply “you poor children don't understand” tactics and adding to the Terms to say they wouldn't do this (but leaving the terms that said they could intact), and then when that didn't fix anything they rolled back the whole thing again as if they were not using AI and it was not their fault that the whole thing happened..

Given Zoom did this once and were essentially unapologetic, they could do it again any time without warning (meaning the terms need legal analysis every time) so I try to avoid using their service and will most likely just dial in by phone if I have to join your call.

I prefer Jitsi instead; it has equivalent functionality, is platform independent, is open source and can be self-hosted.

Details

In the terms in effect when I originally wrote this, “data, content, files, documents, or other materials” that you use in a Zoom session (“Customer Input”), as well as recordings and transcripts, and any other glitter Zoom sprinkles over them, is called “Customer Content”.

10.4(ii) then sees you granting a broad license to Customer Content “for the purpose of product and service development, marketing, analytics, quality assurance, machine learning, artificial intelligence, training, testing, improvement of the Services, Software, or Zoom’s other products, services, and software, or any combination thereof”. 10.5 explains that this may well be carried out by a third party.

If the stuff you shared belongs to someone else, 10.6 sees you agreeing “you are solely responsible for the Customer Content” and notably for getting consent from third parties and providing notices according to whatever laws happen to be applicable to the combination of people involved. Marking things as confidential doesn't help – 17.1 makes clear that “Customer Content is not Customer Confidential Information” (i.e. is not treated by Zoom as shared in confidence).

In addition to all this, in 10.6 you “represent and warrant that you have the right to upload Customer Input and for Zoom to provide, create, or make available any Customer Content to you, and that such use or provision by you, your End User, or Zoom does not violate or infringe any rights of any third party.” So according to 25(i) & (iii) you are basically indemnifying them if they train their AI with someone else's IP you happen to have – for example, a client brief you are discussing internally, or a legal case you are working on under privilege.

There is no opt-out or scope control to use in the Terms for AI training. Zoom's COO says the actual use of the AI features is opt-in, but that doesn't seem relevant as the Terms grant Zoom these permissions regardless and the Customer Content exists whether you use the AI features or not.

Conclusion

My non-lawyer read suggests this is an exceptionally risky thing for anyone to agree if they are in possession of IP or under NDA concerning someone else's secrets, and I will be avoiding Zoom (even if they revert the terms – can't take the chance on future changes like this).

Update: Around 17:00 UTC on August 7 the ToS were changed to append the following text to 10.4:

“Notwithstanding the above, Zoom will not use audio, video or chat Customer Content to train our artificial intelligence models without your consent.”

Given how easy it would have been to make that say “...will not use any Customer Input...” there is presumably still an issue here, even without the observation that “consent” is doing a lot of heavy lifting there.

Update: The ToS were once again changed on August 11 to roll back the whole AI thing and add a note saying they will not train any AI on Customer Content. Maybe it's all over? I'll be cautious about Zoom in future...

Notes, Tags & Mentions

I believe this analysis is correct as of August 16th 2023 (as updated); please contact me at once if it is not, see my hub, especially if it's because they changed the terms of use again!
Here's the immediately prior version of the terms. You can clearly see that the new section 10 has been introduced in the new version. The version in effect at the time of originally posting (dated July 27) seems to differ only in two paragraphs about tax paperwork according to Copyscape.
#Proprietary #Video #Terms #Zoom