opensource &mdash; Webmink In Draft https://the.webm.ink/tag:opensource Things cooking in the Minkiverse. They move elsewhere when the oven pings. Wed, 15 Apr 2026 04:31:20 +0100 A Note On Who To Pay https://the.webm.ink/who-to-pay <![CDATA[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. !--more-- 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. a href="/About"More/a.]]> 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.

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.

]]> https://the.webm.ink/who-to-pay Wed, 27 Nov 2024 23:00:00 +0000 Standards and the Presumption of Conformity https://the.webm.ink/patents-and-the-presumption-of-conformity <![CDATA[This post has graduated to the OSI Blog. !--more-- 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 #Patents #SEP #OpenSource #Reg1025 #Standards @carlmalamud@official.resource.org 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. a href="/About"More/a.]]> 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.

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.

]]> https://the.webm.ink/patents-and-the-presumption-of-conformity Tue, 26 Nov 2024 15:23:52 +0000 CRA Standards Request Draft Published https://the.webm.ink/cra-standards-request-draft-published <![CDATA[This article now forms part of an OSI position.!--more-- 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. !--more-- ---- Notes, Tags and Mentions #Policy #CRA #OpenSource #FreeSoftware #SoftwareFreedom 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. a href="/About"More/a.]]> 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

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.

]]> https://the.webm.ink/cra-standards-request-draft-published Sun, 28 Apr 2024 10:58:44 +0100 Openly Shared https://the.webm.ink/openly-shared <![CDATA[This article has moved to the OSI Blog.!--more-- 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 constructsupsmall{1}/small/sup 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 small{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./small 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. a href="/About"More/a.]]> 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.

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.

]]> https://the.webm.ink/openly-shared Thu, 25 Apr 2024 09:17:43 +0100 Una visión para LibreOffice https://the.webm.ink/una-vision-para-libreoffice <![CDATA[(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.!--more-- ¿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. 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. a href="/About"More/a.]]> (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.

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.

]]> https://the.webm.ink/una-vision-para-libreoffice Sun, 17 Dec 2023 23:32:51 +0000 A Vision for LibreOffice https://the.webm.ink/a-vision-for-libreoffice <![CDATA[(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.!--more-- 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. 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. a href="/About"More/a.]]> (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.

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.

]]> https://the.webm.ink/a-vision-for-libreoffice Wed, 13 Dec 2023 23:36:09 +0000 LibreOffice on ChromeOS https://the.webm.ink/libreoffice-on-chromeos <![CDATA[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! !--more-- --- 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). 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. a href="/About"More/a.]]> 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!

  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

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.

]]> https://the.webm.ink/libreoffice-on-chromeos Mon, 21 Aug 2023 13:05:25 +0100 Just Obey The Law? https://the.webm.ink/just-obey-the-law <![CDATA[A clause in a software license that says something that sounds as simple as “you must follow the law” is problematic in practice and likely to render the license unapprovable as open source. Here's why. Sign on a gate saying "Please Leave Free To Swing"!--more-- In whose opinion? The law is only certain in specific cases and with the delivery of the judgement of the final court. In which jurisdiction? Even in the USA there are multiple jurisdictions, let alone internationally. US State law is increasingly mercurial and compliance in California with law in Florida may not be desirable even if it's possible. Without a jurisdiction it's especially bad - there are laws all over the world we are all breaking all the time. When? The law changes, and without a dated requirement the license could suddenly become invalid. What's legal today may not be tomorrow - the UK is about to make end-to-end encryption illegal if it isn't back-doored for the security services, for example. Even bad law? The law may need challenging - even in the best of worlds the law is sometimes wrong and on the journey to correct it a license for software people rely on should not be invalidated. You can never know who you will be harming. Most importantly, it's not relevant. It is the duty of others to police and enforce the law in general, not of a software license. The software author certainly will not want to do so, and is most likely just trying to cleanse their own conscience at the expense of creating a risk for others. Finally, it's pointless. If someone is so motivated by a crime that the law and its sanctions don't stop them, do you seriously think they will reconsider just because you might sue them for infringement of your license? What do you think you can do about it that the state can't? So a "just obey the law" clause is likely to be discriminatory and including one in your proposed open source license will result in some serious questions from the reviewers. Might be best not to do it! --- Notes, Tags and Mentions This is not to say you should not obey the law. In the vast majority of cases that is a great idea. Just don't write about it in a license where it isn't relevant, enforceable or resolvable. #OpenSource #OSD #Licenses #Meta #Llama @osi@opensource.org 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. a href="/About"More/a.]]> A clause in a software license that says something that sounds as simple as “you must follow the law” is problematic in practice and likely to render the license unapprovable as open source. Here's why.

Sign on a gate saying "Please Leave Free To Swing"

  • In whose opinion? The law is only certain in specific cases and with the delivery of the judgement of the final court.
  • In which jurisdiction? Even in the USA there are multiple jurisdictions, let alone internationally. US State law is increasingly mercurial and compliance in California with law in Florida may not be desirable even if it's possible. Without a jurisdiction it's especially bad – there are laws all over the world we are all breaking all the time.
  • When? The law changes, and without a dated requirement the license could suddenly become invalid. What's legal today may not be tomorrow – the UK is about to make end-to-end encryption illegal if it isn't back-doored for the security services, for example.
  • Even bad law? The law may need challenging – even in the best of worlds the law is sometimes wrong and on the journey to correct it a license for software people rely on should not be invalidated. You can never know who you will be harming.
  • Most importantly, it's not relevant. It is the duty of others to police and enforce the law in general, not of a software license. The software author certainly will not want to do so, and is most likely just trying to cleanse their own conscience at the expense of creating a risk for others.
  • Finally, it's pointless. If someone is so motivated by a crime that the law and its sanctions don't stop them, do you seriously think they will reconsider just because you might sue them for infringement of your license? What do you think you can do about it that the state can't?

So a “just obey the law” clause is likely to be discriminatory and including one in your proposed open source license will result in some serious questions from the reviewers. Might be best not to do it!

Notes, Tags and Mentions

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.

]]> https://the.webm.ink/just-obey-the-law Thu, 20 Jul 2023 19:42:42 +0100 Open Source Is Powered by Stochastic Confidence https://the.webm.ink/open-source-is-powered-by-stochastic-confidence <![CDATA[Graduated to a Meshed Insights article !--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. A bird soars above the greyness over water in the Everglades with the water, mist and sky creating bands of greyness as if devising a scale 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. a href="/About"More/a.]]> Graduated to a Meshed Insights article

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.

A bird soars above the greyness over water in the Everglades with the water, mist and sky creating bands of greyness as if devising a scale

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

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.

]]> https://the.webm.ink/open-source-is-powered-by-stochastic-confidence Mon, 10 Jul 2023 10:11:36 +0100 On License Compliance For Users https://the.webm.ink/on-license-compliance-for-users <![CDATA[Of the many attributes of software freedom that could move to front-of-mind, it strikes me that the minimal license compliance burdens for open source software users are actually a comparative strength. Having them presented as a dangerous weakness by commercial interests in various contexts (what has been called "the compliance-industrial complex") applies a “frame” that serves only the detractors of software freedom. No wonder proprietary vendors want to divert our attention! Open source is so much easier! A woman sits strapped to the top of a bi-plane painted in US patriotic decor and about to take off!--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. a href="/About"More/a.]]> Of the many attributes of software freedom that could move to front-of-mind, it strikes me that the minimal license compliance burdens for open source software users are actually a comparative strength. Having them presented as a dangerous weakness by commercial interests in various contexts (what has been called “the compliance-industrial complex”) applies a “frame” that serves only the detractors of software freedom. No wonder proprietary vendors want to divert our attention! Open source is so much easier!

A woman sits strapped to the top of a bi-plane painted in US patriotic decor and about to take off

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

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.

]]> https://the.webm.ink/on-license-compliance-for-users Wed, 21 Jun 2023 11:32:03 +0100