Language Selection

English French German Italian Portuguese Spanish

Legal

The Commons Clause causes open-source disruption

Filed under
OSS
Legal

Redis Labs tried to legally stop cloud providers from abusing its trademark, but found it difficult because of the legal resources and budgets these giant companies have.

So the company took another route and decided to change the licenses of certain open-source Redis add-ons with the Commons Clause. This change sparked huge controversy within the community with many stating that Redis was no longer open source.

“We were the first significant company to adopt this and announce it in such a way that we got most of the heat from the community on this one,” said Bengal.

The reason for the uproar is because the Commons Clause is meant to add “restrictions” that limit or prevent the selling of open-source software to the Open Source Initiative’s approved open-source licenses.

“ … ‘Sell’ means practicing any or all of the rights granted to you under the License to provide to third parties, for a fee or other consideration (including without limitation fees for hosting or consulting/ support services related to the Software), a product or service whose value derives, entirely or substantially, from the functionality of the Software. Any license notice or attribution required by the License must also include this Commons Clause License Condition notice,” the Commons Clause website states.

According to the OSI, this directly violates item six of its open-source definition in which it states no discrimination against fields of endeavor. “The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research,” the definition explains.

Read more

Is the ‘commons clause’ a threat to open source?

Filed under
OSS
Legal

There are discussions on various forums regarding this clause with conflicting views. So, I will try to give my views on this.

Opposers of the clause believe a software becomes propriety on applying commons clause. This means that any service created from the original software remains the intellectual property of the original company to sell.

The fear is that this would discourage the community from contributing to open-source projects with a commons clause attached since the new products made will remain with the company. Only they will be able to monetize it if they choose to do so.

On the one hand, companies that make millions of dollars from open source software and giving anything back is not in line with the ethos of open source software. But on the other hand, smaller startups and individual contributors get penalized by this clause too.

What if small companies contribute to a large open source project and want to use the derived product for their growth? They can’t anymore if the commons clause is applied to the project they contributed to. It is also not right to think that a contributor deserves 50% of the profits if a company makes millions of dollars using their open source project.

Read more

The Commons Clause doesn't help the commons

Filed under
OSS
Legal

The Commons Clause was announced recently, along with several projects moving portions of their codebase under it. It's an additional restriction intended to be applied to existing open source licenses with the effect of preventing the work from being sold[1], where the definition of being sold includes being used as a component of an online pay-for service. As described in the FAQ, this changes the effective license of the work from an open source license to a source-available license. However, the site doesn't go into a great deal of detail as to why you'd want to do that.

Fortunately one of the VCs behind this move wrote an opinion article that goes into more detail. The central argument is that Amazon make use of a great deal of open source software and integrate it into commercial products that are incredibly lucrative, but give little back to the community in return. By adopting the commons clause, Amazon will be forced to negotiate with the projects before being able to use covered versions of the software. This will, apparently, prevent behaviour that is "not conducive to sustainable open-source communities".

But this is where things get somewhat confusing.

Read more

Microsoft-Connected Black Duck and Salil Deshpande With Their Attacks on Copyleft

Filed under
OSS
Legal
  • The Big Legal Issue Blockchain Developers Rarely Discuss [Ed: The latest FUD from Black Duck]
  • Commons Clause stops open-source abuse [Ed: Salil Deshpande trying to rationalise his attack on Free as in freedom software]

    There are two key reasons to not use AGPL in this scenario, an open-source license that says that you must release to the public any modifications you make when you run AGPL-licensed code as a service.

    First, AGPL makes it inconvenient but does not prevent cloud infrastructure providers from engaging in the abusive behavior described above. It simply says that they must release any modifications they make while engaging in such behavior. Second, AGPL contains language about software patents that is unnecessary and disliked by a number of enterprises.

    Many of our portfolio companies with AGPL projects have received requests from large enterprises to move to a more permissive license, since the use of AGPL is against their company’s policy.

FSF/FSFE/GNU: The Commons Clause Against Copyleft, GCC/Loongson and Sustainable Computing (FSFE)

Filed under
GNU
Legal
  • A Fresh Concern About Open-Source Software

    The issue came to a head last week due to two separate licensing decisions in the space. First, the database project Redis, which is known for its ability to store data in memory, announced it would use a new kind of license called “The Commons Clause,” which looks like open source (in that the source is available to use and modify) but doesn’t fully fit the standard because it allows the project to require that some commercial clients pay for use.

    The problem for Redis Labs, the maker of the software, was that many cloud providers, such as Amazon, use its software but don’t contribute to its upkeep.

    “Cloud providers contribute very little (if anything) to those open source projects. Instead, they use their monopolistic nature to derive hundreds of millions dollars in revenues from them,” the company wrote on its licenses page. “Already, this behavior has damaged open-source communities and put some of the companies that support them out of business.”

  • Loongson 3A1000/3A2000/3A3000 Processor Support For GCC

    A compiler engineer working for Loongson Technology Co is looking to land a number of improvements to these newer MIPS64 processors into the mainline GCC code-base.

    Paul Hua of Loongson Tech sent out a number of patches to improve the GNU Compiler Collection's support for these Chinese MIPS64 CPUs. In particular, the six patches officially add support for the 3A1000, 3A2000, and 3A3000 series processors. Also, there is support for the older Loongson 2K1000 processor series.

  • Sustainable Computing

    Recent discussions about the purpose and functioning of the FSFE have led me to consider the broader picture of what I would expect Free Software and its developers and advocates to seek to achieve in wider society. It was noted, as one might expect, that as a central component of its work the FSFE seeks to uphold the legal conditions for the use of Free Software by making sure that laws and regulations do not discriminate against Free Software licensing.

    This indeed keeps the activities of Free Software developers and advocates viable in the face of selfish and anticompetitive resistance to the notions of collaboration and sharing we hold dear. Advocacy for these notions is also important to let people know what is possible with technology and to be familiar with our rich technological heritage. But it turns out that these things, although rather necessary, are not sufficient for Free Software to thrive.

Dutch government to remove legal barriers to sharing code as open source

Filed under
OSS
Legal

The Dutch government plans to remove legal roadblocks to allow public services to publish the source code of their ICT solutions. A pending proposal from the government to the parliament will change the country’s rules of conduct that minimise interference with the private sector. Next year, the government will begin encouraging public services to publish their source code publicly.

In recent months, the government has been working on a proposal to change itsrules of conduct. The proposal has not yet been submitted to the Dutch parliament, but the changes are anticipated in NL DIGIbeter, a brochure detailing the country’s digital agenda that was published in August. This week, a spokesperson for the Interior Ministry referred to the brochure when asked about pending changes to the rules of conduct.

Read more

Limiting Free Licences and New FUD From Veracode/CA

Filed under
OSS
Security
Legal
  • ​Javascript Tool Maker Relents After Mixing Immigration Politics with Open Source Licensing

    In very short order, Lerna, a company that offers some Javascript tooling, has learned the hard way not to mess with the integrity of an open source license. In other words, don’t decide you’re going to take an existing OSI-certified open source license, modify it to suit your agenda, license your code under the newly derived license, and still continue to refer to your offering as "open source.”

    First, this analysis piece is really just a follow up to my previous post about why it’s time to reject the latest attack on open source software (OSS). The main point of that post was to point out that all of us who have experienced the benefits of open source (ok, that’s nearly all human beings) should play a role in defending it. Otherwise, it will whither and so too will the benefits most of us have come to enjoy, blind to the fact that open source is playing such an important role in our lives.

  • Does Redis' Commons Clause threaten open-source software?
  • Get a Jump on Reducing Your Open Source Software Security Risks [Ed: Anti-FOSS firm Veracode/CA pays IDG for spam which stigmatises FOSS as lacking security]

It's Time To Reject The Latest Attack On Open Source Software

Filed under
OSS
Legal

Open source software is under attack. Again. And so it's beholden on all of us to take a stand before the current scourge marginalizes the wonderous benefits of open source (which accrue to every human) and the organization which looks after both the sanctity of the open source movement and the integrity of the licenses behind it: the Open Source Initiative.

Whether you know it or not, all humans are the beneficiaries of open source software in almost everything we do in our digital lives. Most of everything we use -- the smartphones, the cable modem routers, our desktops and laptops, the Web sites and services we access, the APIs at work under the hood of it all -- is built using open source software (in all or in part). It can be easily argued that all of our user experiences would be a lot suckier and slower were it not for the open source model and how it drives innovation (much of it charitable) which trickles into every digital moment without exception. Some experiences that add value to our lives might not exist at all were it not for open source.

Read more

Also: Open Source Devs Reverse Decision to Block ICE Contractors From Using Software

Licensing/Legal: Public Money, Public Code and Linux Foundation Stuff

Filed under
OSS
Legal
  • Software created using taxpayers’ money should be Free Software

    It might seem obvious that software created using tax money should be available for everyone to use and improve. Free Software Foundation Europe recentlystarted a campaign to help get more people to understand this, and I just signed the petition on Public Money, Public Code to help them. I hope you too will do the same.

  • Major Open Source Project Revokes Access to Companies That Work with ICE [iophk: "former open source now ... however, it is their code and they can change the license"]

     

    On Tuesday, the developers behind a widely used open source code-management software called Lerna modified the terms and conditions of its use to prohibit any organization that collaborates with ICE from using the software. Among the companies and organizations that were specifically banned were Palantir, Microsoft, Amazon, Northeastern University, Motorola, Dell, UPS, and Johns Hopkins University.  

  • Solving License Compliance at the Source: Adding SPDX License IDs

    Accurately identifying the license for open source software is important for license compliance. However, determining the license can sometimes be difficult due to a lack of information or ambiguous information. Even when there is some licensing information present, a lack of consistent ways of expressing the license can make automating the task of license detection very difficult, thus requiring significant amounts of manual human effort. There are some commercial tools applying machine learning to this problem to reduce the false positives, and train the license scanners, but a better solution is to fix the problem at the upstream source.

    In 2013, the U-boot project decided to use the SPDX license identifiers in each source file instead of the GPL v2.0 or later header boilerplate that had been used up to that point. The initial commit message had an eloquent explanation of reasons behind this transition.

  • Arm and Facebook join Yocto Project

    Arm and Facebook have joined Intel and TI as Platinum members of the Yocto Project for embedded Linux development. Meanwhile, the Linux Foundation announced 47 new Silver members.

    The Linux Foundation’s seven-year old Yocto Project was originally an Intel project, and the chipmaker has continued to nurture it over the years. Yet, the Yocto Project’s collection of open source templates, tools, and methods for creating custom embedded Linux-based systems was quickly embraced by the Arm world as well as x86. Now, the technology’s presence in Arm Linux has been reinforced at the membership level with Arm and Facebook joining Intel and Texas Instruments as Platinum members. In other news, the Linux Foundation announced 51 new Silver and Associate members (see farther below).

  • Google Hands Off Kubernetes to the Cloud Native Computing Foundation, Kinetica Joins Automotive Grade Linux, NordVPN Releases NordVPN Linux App, Storj Labs Announces The Open Source Partner Program and Update on Librem 5 Phone

    Google is handing over control of the Kubernetes project to the Cloud Native Computing Foundation. According to the TechCrunch post, Google is providing the foundation $9 million in Google Cloud credits to help cover the costs of building, testing and distributing the software.

Redis modules and the Commons Clause

Filed under
OSS
Legal

The "Commons Clause", which is a condition that can be added to an open-source license, has been around for a few months, but its adoption by Redis Labs has some parts of the community in something of an uproar. At its core, using the clause is meant to ensure that those who are "selling" Redis modules (or simply selling access to them in the cloud) are prohibited from doing so—at least without a separate, presumably costly, license from Redis Labs. The clause effectively tries to implement a "no commercial use" restriction, though it is a bit more complicated than that. No commercial use licenses are not new—the "open core" business model is a more recent cousin, for example—but they have generally run aground on a simple question: "what is commercial use?"

Redis is a popular in-memory database cache that is often used by web applications. Various pieces of it are licensed differently; the "Redis core" is under the BSD license, some modules are under either Apache v2.0 or MIT, and a handful of modules that Redis Labs created are under Apache v2.0, now with Commons Clause attached. Cloud services (e.g. Amazon AWS, Microsoft Azure, Google Compute Engine, and other smaller players) provide Redis and its modules to their customers and, naturally, charge for doing so. The "charge" part is what the adoption of the clause is trying to stamp out—at least without paying Redis Labs.

Read more

Syndicate content

More in Tux Machines

Android Leftovers

Kernel Articles at LWN (Paywall Just Expired)

  • Filesystem sandboxing with eBPF

    Bijlani is focused on a specific type of sandbox: a filesystem sandbox. The idea is to restrict access to sensitive data when running these untrusted programs. The rules would need to be dynamic as the restrictions might need to change based on the program being run. Some examples he gave were to restrict access to the ~/.ssh/id_rsa* files or to only allow access to files of a specific type (e.g. only *.pdf for a PDF reader). He went through some of the existing solutions to show why they did not solve his problem, comparing them on five attributes: allowing dynamic policies, usable by unprivileged users, providing fine-grained control, meeting the security needs for running untrusted code, and avoiding excessive performance overhead. Unix discretionary access control (DAC)—file permissions, essentially—is available to unprivileged users, but fails most of the other measures. Most importantly, it does not suffice to keep untrusted code from accessing files owned by the user running the code. SELinux mandatory access control (MAC) does check most of the boxes (as can be seen in the talk slides [PDF]), but is not available to unprivileged users. Namespaces (or chroot()) can be used to isolate filesystems and parts of filesystems, but cannot enforce security policies, he said. Using LD_PRELOAD to intercept calls to filesystem operations (e.g. open() or write()) is a way for unprivileged users to enforce dynamic policies, but it can be bypassed fairly easily. System calls can be invoked directly, rather than going through the library calls, or files can be mapped with mmap(), which will allow I/O to the files without making system calls. Similarly, ptrace() can be used, but it suffers from time-of-check-to-time-of-use (TOCTTOU) races, which would allow the security protections to be bypassed.

  • Generalizing address-space isolation

    Linux systems have traditionally run with a single address space that is shared by user and kernel space. That changed with the advent of the Meltdown vulnerability, which forced the merging of kernel page-table isolation (KPTI) at the end of 2017. But, Mike Rapoport said during his 2019 Open Source Summit Europe talk, that may not be the end of the story for address-space isolation. There is a good case to be made for increasing the separation of address spaces, but implementing that may require some fundamental changes in how kernel memory management works. Currently, Linux systems still use a single address space, at least when they are running in kernel mode. It is efficient and convenient to have everything visible, but there are security benefits to be had from splitting the address space apart. Memory that is not actually mapped is a lot harder for an attacker to get at. The first step in that direction was KPTI. It has performance costs, especially around transitions between user and kernel space, but there was no other option that would address the Meltdown problem. For many, that's all the address-space isolation they would like to see, but that hasn't stopped Rapoport from working to expand its use.

  • Identifying buggy patches with machine learning

    The stable kernel releases are meant to contain as many important fixes as possible; to that end, the stable maintainers have been making use of a machine-learning system to identify patches that should be considered for a stable update. This exercise has had some success but, at the 2019 Open Source Summit Europe, Sasha Levin asked whether this process could be improved further. Might it be possible for a machine-learning system to identify patches that create bugs and intercept them, so that the fixes never become necessary? Any kernel patch that fixes a bug, Levin began, should include a tag marking it for the stable updates. Relying on that tag turns out to miss a lot of important fixes, though. About 3-4% of the mainline patch stream was being marked, but the number of patches that should be put into the stable releases is closer to 20% of the total. Rather than try to get developers to mark more patches, he developed his machine-learning system to identify fixes in the mainline patch stream automatically and queue them for manual review. This system uses a number of heuristics, he said. If the changelog contains language like "fixes" or "causes a panic", it's likely to be an important fix. Shorter patches tend to be candidates.

  • Next steps for kernel workflow improvement

    The kernel project's email-based development process is well established and has some strong defenders, but it is also showing its age. At the 2019 Kernel Maintainers Summit, it became clear that the kernel's processes are much in need of updating, and that the maintainers are beginning to understand that. It is one thing, though, to establish goals for an improved process; it is another to actually implement that process and convince developers to use it. At the 2019 Open Source Summit Europe, a group of 20 or so maintainers and developers met in the corner of a noisy exhibition hall to try to work out what some of the first steps in that direction might be. The meeting was organized and led by Konstantin Ryabitsev, who is in charge of kernel.org (among other responsibilities) at the Linux Foundation (LF). Developing the kernel by emailing patches is suboptimal, he said, especially when it comes to dovetailing with continuous-integration (CI) processes, but it still works well for many kernel developers. Any new processes will have to coexist with the old, or they will not be adopted. There are, it seems, some resources at the LF that can be directed toward improving the kernel's development processes, especially if it is clear that this work is something that the community wants.

Server Leftovers

  • Knative at 1: New Changes, New Opportunities

    This summer marked the one-year anniversary of Knative, an open-source project that provides the fundamental building blocks for serverless workloads in Kubernetes. In its relatively short life (so far), Knative is already delivering on its promise to boost organizations’ ability to leverage serverless and FaaS (functions as a service). Knative isn’t the only serverless offering for Kubernetes, but it has become a de-facto standard because it arguably has a richer set of features and can be integrated more smoothly than the competition. And the Knative project continues to evolve to address businesses’ changing needs. In the last year alone, the platform has seen many improvements, giving organizations looking to expand their use of Kubernetes through serverless new choices, new considerations and new opportunities.

  • Redis Labs Leverages Kubernetes to Automate Database Recovery

    Redis Labs today announced it has enhanced the Operator software for deploying its database on Kubernetes clusters to include an automatic cluster recovery that enables customers to manage a stateful service as if it were stateless. Announced at Redis Day, the latest version of Kubernetes Operator for Redis Enterprise makes it possible to spin up a new instance of a Redis database in minutes. Howard Ting, chief marketing officer for Redis Labs, says as Kubernetes has continued to gain traction, it became apparent that IT organizations need tools to provision Redis Enterprise for Kubernetes clusters. That requirement led Redis Labs to embrace Operator software for Kubernetes developed by CoreOS, which has since been acquired by Red Hat. IT teams can either opt to recover databases manually using Kubernetes Operator or configure the tool to recover databases automatically anytime a database goes offline. In either case, he says, all datasets are loaded and balanced across the cluster without any need for manual workflows.

  • Dare to Transform IT with SUSE Global Services

Audiocasts/Shows: FLOSS Weekly and Linux Headlines

  • FLOSS Weekly 555: Emissions API

    Emissions API is easy to access satellite-based emission data for everyone. The project strives to create an application interface that lowers the barrier to use the data for visualization and/or analysis.

  • 2019-11-13 | Linux Headlines

    It’s time to update your kernel again as yet more Intel security issues come to light, good news for container management and self-hosted collaboration, and Brave is finally ready for production.