Lisa Hoover 0 Junior Poster

Open source software is being taken seriously as a viable alternative to expensive proprietary applications but it's important to realize that, like its commercial brethren, it comes with a license for use. It's also important to remember that all open source licensing is not created equal.

Free software licensing is quite complex and I recommend browsing gnu.org for the most up-to-date and complete information. According to Eran Strod, director of product marketing at Black Duck Software, around 70% of open source code is licensed under the GPL, something you'll want at least a passing familiarity with.

Although the GPL is popular, it's not the only game in town. In fact, developers can publish their code with any license the want. As a result, there are more than 1,400 unique software licenses, each with its own attributes and obligations. At first blush, it seems that some sort of standardization is in order to keep variables in licensing from becoming unwieldy, but Strod says that's simply not feasible.

While scouring the Internet for open source and other downloadable code, the BlackDuck team has found "over 170,000 projects from 3,800+ Internet sites, and we find upwards of 10GB of new code each day...This tremendous activity by so many thousands of developers working around the globe is simply impossible to control. Developers are creative and they freely create new licenses all the time. There is no real way to stop that, although some of the open source organizations are trying to step in and help by encouraging developers to reuse the top licenses."

If open source software is available to anyone, then who really cares if the various licenses aren't perfectly compatible, right?

Wrong.

"There are many parameters that have been placed into software licenses and if developers are mixing and matching software components with different licenses, it is not uncommon for two licenses to contain conflicting obligations. If not managed properly, this may result in bad press, the loss of control over a code base or legal complications," Strod notes.

In the case of a licensing conflict, it can be tough to determine which license obligations carry the greatest weight and which one ultimately "wins." Strod says those types of legal questions should be addressed by someone with expertise in the field, but prevention is ultimately the best medicine. "The real point here is that a development team should have processes in place to prevent these types of things from happening."

Before you dismiss open source software alternatives as too complicated or not worth the effort to sort through licensing issues, consider its long term impact on your company's bottom line. "Cost savings in year one of deployment often drive initial open source adoption, but reduced vendor lock-in and flexibility to customize emerge as stronger value drivers over time. Customization is really all about application development...Open source is a phenomenon that you simply can’t ignore and companies are finding that it is easy to justify the small investment in open source management relative to the potential productivity benefits."

The bottom line: don't shy away from open source options because of concerns over licensing. Just do your homework and make sure to get some expert advice from people familiar with the intricacies of using free software in business. You might as well get on board now because, as Strod says, "Open source is a nothing short of a tidal wave that will reinvent software engineering."

Dani AI

Generated

Good, practical framing from — license obligations shouldn’t be an afterthought. Treat open‑source licensing as an engineering requirement: record license metadata where machines can read it, produce a Software Bill of Materials (SBOM) for each release, and make compatibility checks part of the dependency approval process. (linuxfoundation.org)

A short, pragmatic checklist teams can adopt:

  • Record the component’s declared license and a standard short identifier (SPDX) alongside provenance.
  • Compare declared metadata with detected license text (files can differ from package metadata) and evaluate compatibility with the product’s distribution model.
  • Add the component to the project’s SBOM/inventory and retain scan evidence.
  • If a conflict appears, prefer an alternative, isolate the code (API/service boundary), or escalate to the OSPO/legal owner for a decision.
    These process elements map to widely recommended compliance practices. (openchainproject.org)

Automate detection and triage so reviews scale. Run an automated license scanner as part of CI, store machine‑readable output (SPDX/CycloneDX), and feed results into a policy evaluator so pull requests with disallowed licenses can be flagged before merge. Open toolchains exist that orchestrate scanning, analysis, and policy evaluation; scanners can produce detailed, reviewable findings for human conclusions. (oss-review-toolkit.org)

Governance and contributors: require contributor sign‑off (DCO) or an appropriate contributor agreement, maintain a clear third‑party notice file, assign an owner (OSPO or designated engineer) for license changes, and treat distribution‑impacting questions as legal issues requiring counsel. These operational controls, combined with traceable SBOMs and automated scans, turn license risk from an open question into a managed engineering flow. (developercertificate.org)

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.