Joe 'Zonker' Brockmeier Fights FOSS License FUD

17 Years Ago Techwriter10 0 556 Views

Seems every time I write a piece suggesting open source as an option, I get a couple of comments warning readers about the scary complexities of open source licenses. So I decided to ask a guy who knows free and open source (FOSS) exactly what the deal was regarding FOSS licensing and whether they were really any more or less complex than their commercial counterparts.

Joe 'Zonker' Brockmeier, who is Community Manager for and has been working with FOSS in one way or another since 1996, says the bottom line is that you should always check the license language carefully, so that you are keenly aware of the terms, but you should never let the license scare you away from open source.

RM: Every time I write about opens source, I get comments about watching out for the licenses, that they can be confusing and get companies in trouble if they don't pay attention. Are open source licenses in general any more complex than their commercial counterparts?

JZB: Not really. The only difference is that open source licenses allow redistribution and modification -- and since there are a lot of different licenses with different conditions, companies should pay attention when they engage in those activities.

As a general rule, though, use of open source is no more complex --and is typically less complex -- than use of proprietary software.

RM: Comments also suggest open source users should be careful about altering the software, which you can do under many open source licenses, What are the conditions under which companies can alter the software?

JZB: It depends on the license, but open source means companies can always alter the software -- what changes is the conditions that you need to meet after doing so. If you're altering for internal use only, typically there's no requirement to do anything. If you alter the software and redistribute, then it depends on the license whether you need to make changes available or not, how you need to acknowledge the original software, and so forth.

RM: When companies make changes to open source software, what are the general rules, about giving back and sharing with community? Does this differ across products and communities?

JZB: Well, that depends on the license, and the communities. Software under the GNU General Public License and copyleft type licenses requires that changes be made available when you distribute the software. There's also the matter of the so-called 'viral' nature of the GPL, which means that if you incorporate GPLed software into your product, you may need to distribute the entire thing -- not just the original GPLed product.

This can get a bit complex, and a company should consult a lawyer and/or the Free Software Foundation for advice on this kind of thing. (The GPL also has an extensive FAQ, which, sadly few people read!)

Note that mere aggregation doesn't mean you have to GPL the entire thing. So, for instance, if you have a program that does its own thing distributed with a bunch of other software, that doesn't mean all the other software has to be GPLed. But, if it's 'derived' from the GPLed software, then you need to GPL the entire lot.

An additional note - a lot of people like to use scare tactics to try to convince companies to avoid "tainting" their software with GPLed software, claiming that it could force a company to open all of their software. Not true -- the worst case scenario is really that a company may be forced to cease distribution of the GPLed software if they're not willing to comply with the license. Now, this may be inconvenient, but if a company feels that its code will lose value to the company if distributed under the GPL, they can opt to not distribute the GPLed code and retain their copyrighted code under whatever license they choose.

Proprietary companies want money for their code, projects that GPL software simply want code in lieu of money. (Of course, it's not unheard of for authors to dual-license software too - so companies have the option of asking to pay licensing fees for GPLed code.)

BSD/MIT style licenses require very little - so companies are allowed to keep the code under whatever license they choose and may even keep their changes proprietary -- though they may have some notification requirements.

RM: How do communities incorporate ad-hoc changes into the core offering?

JZB: It depends. One of the sad things is that many companies choose not to collaborate effectively with the communities that produce the code -- and therefore tend to just deliver "code bombs," which is to say, a tarball of code without any revision control history or other assistance that would allow a project to easily consume the changes.

So, sometimes a company makes valuable changes to a code base that are not easily incorporated because of the way the changes are delivered.

The process works best when a company becomes part of the community of the software they are consuming and the company's developers work hand-in-hand with the rest of the project, so that the code stays in sync with the development trunk.

Dani AI

Generated 10 Months Ago

This thread (notably ’s interview and ’s reaction) highlights two separate worries people conflate: license complexity and whether a community “fits.” Both are solvable with a few concrete, repeatable practices that make license risk a part of engineering work instead of an obstacle.

A compact playbook:

Maintain a simple SBOM (component, version, declared license, origin) so every dependency is visible.
Classify licenses into “allowed / needs review / disallowed” for your product teams and automate checks during builds.
Flag where code goes: internal tools vs redistributed artifacts — obligations usually attach when you redistribute.
Preserve provenance: use VCS, keep commit history, and include clear authorship so upstream can accept changes.
Default contribution hygiene: open an issue to describe large changes, keep patches small and well-documented, include tests and a changelog entry.
Add license metadata: a LICENSE file, SPDX identifiers in files, and any required NOTICE text; record contributor agreements or ownership if relicensing is planned.

Practical notes for working with projects: never drop an untracked tarball and expect easy consumption. Upstream maintainers accept well-framed, small pull requests with tests and clear commit messages far faster. If a project expects a CLA or DCO, follow that workflow rather than reinventing it.

Example of minimal headers/commit sign-off to include with a contribution:

SPDX-License-Identifier: MIT
Signed-off-by: Alice Developer <alice@example.com>

Add feature X with unit tests and README entry.

Licensing is risk management, not mysticism. Community culture (the point raises) matters for collaboration, but it’s separate from legal obligations. A short checklist, automated scans, and an escalation path to legal for edge cases remove most of the fear and make contributions and use predictable.

putTheGinGnome 0 Newbie Poster

17 Years Ago

I think openSUSE is complicated in general so it's hard to read this article with an open mind. This isn't a poorly written article, but the jargon and the overly technical explanations are simply overstated. I think UBUNTU is a lot more in sync with it's community and there is almost like a snobbishness in openSUSE I find totally annoying. But overall thanks for the article. It's interesting to hear the opinion from the dark side once in awhile.

Reply to this topic

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.