Language Selection

English French German Italian Portuguese Spanish

Licensing and Tricks/Openwashing

Filed under
OSS
Legal
  • April 2020 Zeta Alliance Weekly Call Summaries

    Changes To Zimbra’s Open Source Policy
    John E. explained that Zimbra 9 introduces a change to Synacor’s open source policy for Zimbra. Starting with Zimbra 9, a binary version of Zimbra 9 will no longer be released to the community and will instead only be made available to Zimbra Network Edition customers. There are currently no plans to release the source code for Zimbra 9 to the community. Zimbra 8.8.15 will remain open source for the community and continue to be supported for the remainder of its lifecycle through December, 31, 2024 (https://www.zimbra.com/support/support- ... lifecycle/). Version 8.8.15 will also continue to receive patches during this time frame. John E. described this new model for Zimbra 9 as “open core” where the open source products on which Zimbra is built will continue to be freely available, but the Zimbra 9 product itself will not be open source. Marc G. asked if Synacor’s plans involved introducing new features to Zimbra 8.8.15, or if the focus for introducing new features will shift exclusively to version 9. John E. said that he did not have the answer to this question. John also shared that starting with Zimbra 9, a source code license will be made available to customers who are licensing Zimbra Network Edition.

    Reactions To Zimbra Open Source Policy Change
    Noah P. said that part of his customer base values that Zimbra is open source and that it has been a marketing advantage over other proprietary email platforms. Marc G. said he felt this change will be hard for the open source community to support. John E. shared his personal opinion that Zimbra has struggled for several years to engage the open source community, as the ratio of people using Zimbra, compared to the number of people contributing back to Zimbra, has been very low. He said the biggest difference currently between Zimbra 8.8.15 and 9.0 is the addition of the new, Modern UI and welcomes feedback from Zimbra partners and the open source community on this policy change. Mark S. shared that many developers he has discussed it with have said that they have found it very difficult (if not impossible) to contribute to the Zimbra project in the past, mainly due to issues with an earlier version of the contributor’s agreement, which was finally updated a couple of years ago. Randy L. mentioned that another open source project, VyOS (https://www.vyos.io/community/), overcame issues with soliciting contributions back to their open source project by making binaries available to those who could demonstrate a meaningful contribution to the project in code or documentation work and suggested that such an approach might be something that Synacor should look at too. John E. invited Zimbra partners concerned about continued open source access to make a business case explaining how the loss of open source access would have a financial business impact for Synacor.

  • Changes To Zimbra's Open Source Policy

    The Zimbra email and collaboration suite will change its open source policy. This post from the Zeta Alliance notes the changes for Zimbra 9. "John E. explained that Zimbra 9 introduces a change to Synacor's open source policy for Zimbra. Starting with Zimbra 9, a binary version of Zimbra 9 will no longer be released to the community and will instead only be made available to Zimbra Network Edition customers.

  • Free Software Legal and Licensing Workshop 2020 cancelled due to COVID-19 outbreak

    This year's FSFE's Free Software Legal and Licensing Workshop has been cancelled. The FSFE thanks our contributors and looks ahead to organizing the event next year.

    Due to the outbreak of COVID-19 currently gripping the world, in early March the FSFE had to make the difficult decision to cancel our upcoming Free Software Legal and Licensing Workshop 2020 (the "Workshop"). Originally scheduled to take place from 15 - 17 April in Barcelona, Spain, the Workshop is an annual conference held every year since 2008 for the FSFE's Legal Network, and serves as a meeting point for FOSS legal experts to discuss issues and best practices surrounding Free Software licensing.

    Many exciting sessions were scheduled for this year's Workshop, including discussions on the technological relevance of copyleft licenses, on the challenges facing Free Software with machine learning and big data, on ongoing litigation from various jurisdictions on software licensing, as well as many other talks and workshops.

  • Update from the CommunityBridge Development Team [Ed: The Linux Foundation works for Microsoft. Not for Linux;
    watch who drives this thing...]
  • TOC Welcomes Dragonfly Into CNCF Incubator

    The CNCF Technical Oversight Committee (TOC) has accepted Dragonfly as an incubation-level hosted project. Dragonfly, which was accepted into the CNCF Sandbox in October 2018, is an open source, cloud native image and file distribution system. The goal of Dragonfly is to tackle distribution problems in cloud native scenarios.

More in Tux Machines

Kernel: Virtualisation, BPF, and Btrfs

  • QEMU 5.1 Bringing Many CPU Improvements From Loongson To RISC-V To s390

    QEMU 5.1-rc0 is available as the first step towards this next feature release of this important component to the Linux virtualization stack. The QEMU 5.1-rc0 release marks the hard feature freeze for this next release. Weekly release candidates will continue until QEMU 5.1 is ready to ship around the middle of August.

  • Sleepable BPF programs

    When support for classic BPF was added to the kernel many years ago, there was no question of whether BPF programs could block in their execution. Their functionality was limited to examining a packet's contents and deciding whether the packet should be forwarded or not; there was nothing such a program could do to block. Since then, BPF has changed a lot, but the assumption that BPF programs cannot sleep has been built deeply into the BPF machinery. More recently, classic BPF has been pushed aside by the extended BPF dialect; the wider applicability of extended BPF is now forcing a rethink of some basic assumptions. BPF programs can now do many things that were not possible for classic BPF programs, including calling helper functions in the kernel, accessing data structures ("maps") shared with the kernel or user space, and synchronizing with spinlocks. The core assumption that BPF programs are atomic has not changed, though. Once the kernel jumps into a BPF program, that program must complete without doing anything that might put the thread it is running in to sleep. BPF programs themselves have no way of invoking any sort of blocking action, and the helper functions exported to BPF programs by the kernel are required to be atomic. As BPF gains functionality and grows toward some sort of sentient singularity moment, though, the inability to block is increasingly getting in the way. There has, thus, been interest in making BPF programs sleepable for some time now, and that interest has recently expressed itself as code in the form of this patch set from Alexei Starovoitov. The patch adds a new flag, BPF_F_SLEEPABLE, that can be used when loading BPF programs into the kernel; it marks programs that may sleep during their execution. That, in turn, informs the BPF verifier about the nature of the program, and brings a number of new restrictions into effect. Most of these restrictions are the result of the simple fact that the BPF subsystem was never designed with sleepable programs in mind. Parts of that subsystem have been updated to handle sleeping programs correctly, but many other parts have not. That is likely to change over time but, until then, the functionality implemented by any part of the BPF subsystem that still expects atomicity is off-limits to sleepable programs. For example, of the many types of BPF programs supported by the kernel, only two are allowed to block: those run from the Linux security module subsystem and tracing programs (BPF_PROG_TYPE_LSM and BPF_PROG_TYPE_TRACING). Even then, tracing programs can only sleep if they are attached to security hooks or are attached to functions that have been set up for error injection. Other types of programs are likely to be added in the future, but the coverage will never be universal. Many types of BPF programs are invoked from within contexts that, themselves, do not allow sleeping — deep within the network packet-processing code or attached to atomic functions, for example — so making those programs sleepable is just not going to happen.

  • Btrfs at Facebook

    The Btrfs filesystem has had a long and sometimes turbulent history; LWN first wrote about it in 2007. It offers features not found in any other mainline Linux filesystem, but reliability and performance problems have prevented its widespread adoption. There is at least one company that is using Btrfs on a massive scale, though: Facebook. At the 2020 Open Source Summit North America virtual event, Btrfs developer Josef Bacik described why and how Facebook has invested deeply in Btrfs and where the remaining challenges are. Every Facebook service, Bacik began, runs within a container; among other things, that makes it easy to migrate services between machines (or even between data centers). Facebook has a huge number of machines, so it is impossible to manage them in any sort of unique way; the company wants all of these machines to be as consistent as possible. It should be possible to move any service to any machine at any time. The company will, on occasion, bring down entire data centers to test how well its disaster-recovery mechanisms work.

today's howtos

Home Assistant improves performance in 0.112 release

The Home Assistant project has released version 0.112 of the open-source home automation hub we have previously covered, which is the eighth release of the project this year. While previous releases have largely focused on new integrations and enhancements to the front-end interface, in this release the focus has shifted more toward improving the performance of the database. It is important to be aware that there are significant database changes and multiple potential backward compatibility breaks to understand before attempting an upgrade to take advantage of the improvements. According to the release notes written by contributor Franck Nijhof, better performance has been a major goal of this release with a focus on both the logbook and history components. This builds on the work of the previous release (v0.111) from a performance perspective, which focused on reducing the time it takes to initialize the hub at startup. Read more

Android Leftovers