Why Fedora Decided To Give CC0 Licensed Code The Boot

July 29, 2022 by Tom Nardi 57 Comments

The term “open source” can be tricky. For many people, it’s taken to mean that a particular piece of software is free and that they can do whatever they wish with it. But the reality is far more complex, and the actual rights you’re afforded as the user depend entirely on which license the developers chose to release their code under. Open source code can cost money, open source code can place limits on how you use it, and in some cases, open source code can even get you into trouble down the line.

Which is precisely what the Fedora Project is looking to avoid with their recent decision to reject all code licensed under the Creative Common’s “Public Domain Dedication” CC0 license. It will still be allowed for content such as artwork, and there may even be exceptions made for existing packages on a case-by-case basis, but CC0 will soon be stricken from the list of accepted code licenses for all new submissions.

Fedora turning their nose up at a software license wouldn’t normally be newsworthy. In fact, there’s a fairly long list of licenses that the project deems unacceptable for inclusion. The surprising part here is that CC0 was once an accepted license, and is just now being reclassified due to an evolving mindset within the larger free and open source (FOSS) community.

So what’s the problem with CC0 that’s convinced Fedora to distance themselves from it, and does this mean you shouldn’t be using the license for your own projects?

Continue reading “Why Fedora Decided To Give CC0 Licensed Code The Boot” →

Showing an Ortur lasercutter control module in front of a screen. There's a serial terminal open on the screen, showing the "Ortur Laser Master 3" banner, and then a Grbl prompt.

Watch Out For Lasercutter Manufacturers Violating GPL

July 15, 2022 by Arya Voronova 84 Comments

For companies that build equipment like CNC machines or lasercutters, it’s tempting to use open-source software in a lot of areas. After all, it’s stable, featureful, and has typically passed the test of time. But using open-source software is not always without attendant responsibilities. The GPL license requires that all third-party changes shipped to users are themselves open-sourced, with possibility for legal repercussions. But for that, someone has to step up and hold them accountable.

Here, the manufacturer under fire is Ortur. They ship laser engravers that quite obviously use the Grbl firmware, or a modified version thereof, so [Norbert] asked them for the source code. They replied that it was a “business secret”. He even wrote them a second time, and they refused. Step three, then, is making a video about it.

Unfortunately [Norbert] doesn’t have the resources to start international legal enforcement, so instead he suggests we should start talking openly about the manufacturers involved. This makes sense, since such publicity makes it way easier for a lawsuit eventually happen, and we’ve seen real consequences come to Samsung, Creality and Skype, among others.

Many of us have fought with laser cutters burdened by proprietary firmware, and while throwing the original board out is tempting, you do need to invest quite a bit more energy and money working around something that shouldn’t have been a problem. Instead, the manufacturers could do the right, and legal, thing in the first place. We should let them know that we require that of them.

Continue reading “Watch Out For Lasercutter Manufacturers Violating GPL” →

Vizio In Hot Water Over Smart TV GPL Violations

October 22, 2021 by Tom Nardi 70 Comments

As most anyone in this community knows, there’s an excellent chance that any consumer product on the market that’s advertised as “smart” these days probably has some form of Linux running under the hood. We’re also keenly aware that getting companies to hold up their end of the bargain when it comes to using Linux and other GPL licensed software in their products, namely releasing their modified source, isn’t always as cut and dried as it should be.

Occasionally these non-compliant companies will get somebody so aggravated that they actually try to do something about it, which is where smart TV manufacturer Vizio currently finds itself. The Software Freedom Conservancy (SFC) recently announced they’re taking the Irvine, California based company to court over their repeated failures to meet the requirements of the GPL while developing their Linux-powered SmartCast TV firmware. In addition to the Linux kernel, the SFC also claims Vizio is using modified versions of various other GPL and LGPL protected works, such as U-Boot, bash, gawk, tar, glibc, and ffmpeg.

According to the SFC press release, the group isn’t looking for any monetary damages. They simply want Vizio to do what’s required of them as per the GPL and release the SmartCast source code, which they hope will allow for the development of an OpenWrt-like replacement firmware for older Vizio smart TVs. This is particularly important as older models will often stop receiving updates, and in many cases, will no longer be able to access all of the services they were advertised as being able to support. Clearly the SFC wants this case to be looked at as part of the larger Right to Repair debate, and given the terrible firmware we’ve seen some of these smart TVs ship with, we’re inclined to agree.

Now of course, we’ve seen cases like this pop up in the past. But what makes this one unique is that the SFC isn’t representing one of the developers who’s software has been found to be part of Vizio’s SmartCast, they’re actually the plaintiff. By taking the position of a consumer who has purchased a Vizio product that included GPL software, the SFC is considered a third-party beneficiary, and they are merely asking the court to be given what’s due to them under the terms of the license.

As firm believers in the open source movement, we have zero tolerance for license violators. Vizio isn’t some wide-eyed teen, randomly copying code they found from GitHub without understanding the implications. This is a multi-billion dollar company that absolutely should know better, and we’ll be happy to see them twist in the wind a bit before they’re ultimately forced to play by the rules.

Make It Easier For Your Software Project To Accept Contributions

April 29, 2020 by Donald Papp 30 Comments

[Flameeyes] has heard complaints (and at times, he admits, has complained himself) about big companies not contributing improvements to projects they seem to find useful, or rolling their own implementation rather than use and contribute to an existing code base. Having recently left Google after seven years, he has some insights into some of the reasons big corporations (at least Google, anyway) may sometimes seem to eschew making code contributions, and some of the reasons might come as a surprise.

There are things a corporation can do differently, but there are also some things that can be done on the project’s end to make accepting contributions easier. [Flameeyes] took some time to write out a few pointers on how to make it easier for others (particularly large corporations) to contribute code to a software project.

The biggest issue is the software license. Without one, there is no legal structure to use, distribute, or contribute to the code, and no corporate entity will want to touch it. Google specifically forbids creating patches for projects with either no license, or incompatible licenses. An example of an incompatible license is one that forbids commercial use, because everything a corporation like Google does — even research –is considered a commercial endeavor. In addition, on the corporate side making contributions might trigger a code review process of some kind for some licenses, but not for others. [Flameeyes] suggests the MIT license as one that is acceptable to pretty much everyone with a minimum of fuss. Another caution: if a project’s code resides in an online repository, make sure the repository is licensed as well.

A few other small suggestions (such as maintaining an AUTHORS file to track contributors in a tidy way) rounds out the advice. It sounds simple, but software licensing is so critical to the whole affair that it’s important to get it right — he suggests the REUSE tool for anyone wanting to make sure a project’s licensing is tidy.

[Flameeyes] makes a point that none of this guidance is based on secret or institutional knowledge. Google has a public document detailing exactly how they use and deal with open source, and it’s a solid guide for how to make your project more accepting of contributions from a corporate entity like Google. (Or, if you prefer, a guide on how to set up as many barriers as possible for your project.)

In case you missed it, we just want to remind you that our favorite recent open source project from Google is definitely Pigweed.