Developers almost never have anything good to say about Contributor License Agreements (CLAs) or Developer Certificates of Origin (DCOs), but we're stuck with them anyway, so it helps to understand why they exist and what the differences are between them.
The long face off between the U.S. Government and Huawei regarding 5G standards development has finally reached an end - at about the 90 yard line. Better than before. But not quite there.
Standards come in many forms. Some are created to enable interoperability between programs, and others to enable equality between individuals. Sadly, we seem to be better at universally adopting the former than the latter.
Regular readers will know that the addition of Huawei and scores of its subsidiaries to the U.S. Bureau of Industry and Security Entity List last May has had a serious impact on standards setting organizations (SSOs). For a year now, the U.S. has refused to make it possible for US companies to collaborate with Huawei on 5G standards. That may finally change.
With Huawei barred from helping develop most 5G standards, the stage is set for a possible standards war. If that happens, everyone will end up a loser.
We're used to thinking of standards organizations and open source projects as being societally beneficial - and they are. But they're also places where head to head competitors agree to so things the same way, and the regulators are watching.
There’s been a lot of activity in diverse parts of the standards and open source software development world of late. Here’s a selection of items you may have missed that I think might be of greatest interest.
Merging code in open source software is easy. Just grab and add, right? Well, no. If you don't pay attention to what license each inclusion is offered under, the users of your software may end up with a disaster on their hands. Happily, there are free tools available to help you avoid just that.
The classic way for companies to violate the antitrust laws is to get together and agree to all do something the same way. Happily, the regulators understand that creating open standards and open source is a good thing. But you still have to keep the rules in mind if you want to stay on the right side of the line.
Different OSS licenses have been created for different - and sometimes incompatible - reasons. Before incorporating OSS into a product you need to know the differences and how to be sure you play by the rules.
In this third and final installment, I survey the rich landscape of hosting organizations, platforms and supporting tools that support the development of FOSS today.
In this installment, we'll explore how Richard Stallman's revolutionary free and open source licensing philosophy spread and forked, and where it has taken us to today.
Everybody uses open source software today. But not everyone knows where it came from, or how many battles were fought along the way before it emerged victorious. If you're not sure you know the whole story, this article is for you.
For over thirty years companies have been launching new standards consortia, and then open source foundations, in the US. That's usually been just fine with the rest of the world, until now.
Ever wondered what a "standards essential patent" or a "FRAND" standards commitment was - and why they matter so much? There's a case in process right now that may redefine what technology a vendor does and does not have to share with its competitors
On Monday, the US further restricted Huawei's ability to participate in standards development, and made it a lot harder for standards developing organizations to run their operations without fear of liability. The rules may also affect the ability of US developers to participate in open source projects using "copyleft" licenses like the GPL
Back in the beginning of open source, contributors often transferred ownership of their code to a project. Bad experiences with some corporate-sponsored projects caused that to change. With so many non-profit projects hosts now, it's worth reassessing the advantages of code assignment.
It's easy to imagine that regulators should love free and open source software. After all, anyone can adopt it, change it, and distribute it. But that's not the only way to assess its impact on innovation.
Free and open source software may have won the war with proprietary software, but that doesn't mean the future will always be safe and secure. Victory brings responsibilities as well as cause for celebration.
The addition of Huawei to the US "Entity List" has created a flurry of confusion and concern among open source and open standards organizations wondering whether they need to kick the Chinese company out. The answer to that question will likely vary, depending on the transparency of the process of the specific organization.