The Business Obligations of Open Source Software

This article is a part of a series on using open source in business:

The previous two articles in this series covered the technical and business benefits OSS offers. However, this only paints half the picture. While OSS might be free to use, modify, and distribute, it doesn’t come without effort and risk; if a company isn’t prepared to handle them, they can cause significant headaches down the road. This article will provide an overview of the obligations and risks a company that uses OSS in their products or services must be aware of.

Licensing and Compliance

While OSS has no initial licensing costs, this doesn’t always mean you’re free to use OSS however you want. Open source licenses can impose a range of obligations that must be satisfied whenever code that includes OSS is distributed in a product or service. This can include things like disclosure requirements, specific notifications, and licensing modifications under the same open source license.

At the very least, all businesses need to maintain an accurate inventory of all OSS that’s used in their products or services, and must have adequate processes to ensure compliance with all licenses both during and after product distribution. Typically, a single person is assigned the responsibility of being the open source compliance manager to oversee the execution of this, and it requires coordination between legal, engineering, human resources, and the compliance officer; larger companies often need to establish an Open Source Review Board to facilitate this coordination.

The most critical coordination is between product, engineering, and management teams: they must identify all OSS used in product code and to assist with any licensing or compliance questions. This often means employee roles need to be expanded to cover the various elements of OSS compliance that directly relate to each position. This coordination must also expand outside the company to include software providers as well because any OSS that’s included in the software they provide must also be properly accounted for and complied with. While establishing a framework for this coordination, it’s common to come across areas that need better tooling which creates more need for deployment and training.

Open source licensing can create substantial obligations, especially in larger organizations, and these obligations require more coordination between various teams. This article only briefly touches on the subject of open source compliance, and if you’re interested in this subject more there is a lot of detailed information on the web.

Training and Development

Training is a critical component of open source engineering because you’ll need to train developers, legal, software procurement, quality assurance, systems administrators, and others on the obligations of open source compliance. Additionally, you might need training for developers that have little to no experience working with an open source community on how open source development works.

Maintenance and Support

Proprietary software typically includes some level of paid support from the vendor company, which may include an SLA, pre-disclosure of vulnerabilities, or implementation support.  This is generally contractually enforceable, and it’s reasonable to demand responsiveness from the vendor in line with your support contract.  Similar support for OSS projects may be offered by companies participating in the ecosystem, but it is rare to find unpaid guaranteed support from the development community itself.  As most of the participants are either working on their own time or on behalf of an employer, it is neither reasonable nor fair to expect the same level of service as provided by a paid vendor.  As such, it may be the case where businesses that incorporate unpaid OSS into their products are responsible for installing updates and implementing security fixes and new modules themselves.  These tasks are easy to push aside in favor of more pressing issues, but they must be addressed nonetheless because a lack of maintenance can rapidly overcome the benefits of incorporating externally developed code.

To reiterate, OSS does not include any sort of support contract unless it is specifically negotiated with a third-party company that offers these services.  The most common OSS licenses specifically include a disclaimer of warranty.  If a business requires 24/7 support for services that use OSS, this will either need to be negotiated with an appropriate third-party company or the team will need to be hired in-house. Support services are a critical, but often overlooked, investment when using OSS.

Application Dependence

OSS can be a great avenue to avoid proprietary software dependence, but that doesn’t mean it’s a simple process to migrate away from OSS that no longer meets the requirements of a company. Whenever OSS is used for business-critical applications, the business becomes dependent on the community and project.  Changes that go against the interests of the business could result in the company needing to migrate to an alternative. The effort required to make this switch can vary widely depending on the availability of expertise and the maturity of the projects being migrated between. OSS community support can mitigate this problem, but this also varies substantially from project to project.  In general, it is considered a best practice to be actively engaged with and support select OSS communities to reduce the risk of unexpected changes to critical components.

Strategic Dependence

Open source leadership can bring substantial benefits to companies that properly leverage it, but the independent nature of open source communities can complicate strategic decisions. For starters, open source community choices may preclude downstream requirements, particularly if a company does a poor job of communicating with the upstream community.  This can introduce added effort to maintain downstream products. Additionally, if the community doesn’t have a formal technical roadmap, planning can become much more complicated. Finally, all software whether open or proprietary fits onto a spectrum of maturity, and this can often reflect the needs of a community.  For example, software developed for home use or for academic research may require some level of investment to meet product security requirements.

Do the Benefits of Open Source Outweigh the Obligations?

This article should have provided you with a general understanding of what obligations and risks are associated with the use of OSS in a product or service. There is no one-size-fits-all solution for whether a company should use OSS or simply buy software from a proprietary vendor, so it’s always important for any business that’s considering the use of OSS to consider their own specific requirements.  However, the overwhelming trend in the industry has been in favor of OSS components wherever possible, particularly in consumer electronics.

Here are some questions all businesses should ask themselves when considering the use of OSS in products.

  • How do the platform costs of OSS compare to similar offerings?
  • What commercial support offerings are available?
  • What license obligations does the code have? Does our company have the resources to fill them?
  • Who are the key individuals and organizations in the open source community? How long have they been around?
  • Do the open source community goals and roadmap meet our risk profile?
  • Does our company have adequate resources to support the use of OSS in our products?


Samsung’s Process for Kicking Off a New Open Source Project

Consistency is everything.

If launching open source projects is part of your job, it is incredibly helpful to have a clear, consistent, and repeatable process for open sourcing code and building a project.

Why? There are a few reasons. For one, it increases your odds of success if you can identify the parts of the process that worked well before, and repeat them. Project launches are about people as much as technology. There are actions that attract others, and actions that drive others away; it’s beneficial to remember which is which. If you can’t convince others to join and use your project, you may as well just post the code and be done with it.

Another major reason is time. I seriously doubt I’m alone in observing that the typical “We’re launching an OSS project next month! Um, where do we start?” emails usually come with little warning. Most of the time another group has been working on it for a while, and we get a heads up when they think they’re done and ready to go.

But more often than not, they’re about halfway there – and their original deadlines are still in place. Having a structured process can help quickly identify what’s already done, what still needs to be done, and whether that launch date is actually realistic.

The Samsung Open Source Group maintains these processes for a variety of project types, customized based upon our own experience in launching projects as well as the specific needs of our company. Here’s a high level overview of one we use when preparing to launch a major standalone open source project.


We start by asking some basic questions. One of the most important steps in this process is determining, right at the start, if it’s even worth doing as a standalone OSS project. If, for example, the project addresses a niche that only you can reasonably contribute to, it may be faster and cheaper to publish the source code under an appropriate license without constructing a full project.

Once you’re past that first sanity check, you should be sure there’s a genuine reason for others to contribute and use the code. This will help determine the ideal project governance structure, which in turn will help you predict where you’ll need to focus your time and energy.

Once you have identified the “to-be” state, you need to ask one of the hardest questions in the entire process: “Do we have the willpower, skills, and funding to see this through until it becomes self-sustaining? What will we do if (for reasons beyond our control) it never becomes self-sustaining?”

Another deceptively simple but guaranteed-to-cause-you-pain-if-you-overlook-it question is, “How do we define and measure success so that we can justify our budget every 12 months?” If you work in a large corporate environment, you know exactly what I’m talking about. The definition of success will change immensely in the first few years of a project, so make sure your plans reflect this.

We also ask how this project will affect Samsung’s reputation. Are we going to win new advocates? Create new competitors? Fundamentally alter the economics of an ecosystem? These are all things that must be considered.


If you are launching a standalone open source project you will need to determine the structure of the Board of Directors (for members to make decisions about money and policy), a Technical Steering Committee (for contributors to self-govern the development and release process), and other specialized committees like Marketing or Certification.

Next, we ask who is expected to participate in each governing body, and how. In some cases, you can look into the governance practices of similar communities, particularly if membership could overlap. This can give you a reasonable idea of what level of participation can be expected from others, what dues should be charged, and the membership benefits you should offer.

This is also the right time to draft code submission requirements, processes by which committers, reviewers, and maintainers are selected, and so forth.


Of course, I’m not going to give you any legal advice. However, there are some questions you should ask your own attorneys.

For example, what is the project’s policy on the Developer Certificate of Origin? Should we use a CLA? Who will actually produce the project’s legal documents, such as membership agreements, bylaws, and IPR/license policy?

This is also a good time to investigate similar communities, as well as vertical components in the stack, and determine if they will influence the project’s policies. In an ideal situation, you want to match them as closely as possible. This reduces potential sources of friction when existing developers and users start participating in your project.

Project Budget

This is hard to predict in advance, particularly if you don’t already have a roster of committed companies. I have found it best to create three budgets: the absolute minimum to keep the lights on, the ideal case, and the blowout success case. This is tightly tied to the willpower question above. If only a few others join, who will make up the funding gaps? If membership revenue doesn’t ramp up as expected, will others help fund the difference?


Speaking of hard-to-predict, membership is one of the other big unknowns. Sure, you can come up with plenty of reasons others should want to join, but will they actually do it?

There are ways to improve your odds. One of the most effective strategies is to use your own business development people to approach current business partners. They already have a relationship with you, and probably also see the same benefits from participating in the project. This is an advantage, particularly if your business development teams can approach people who can make a meaningful decision about committing to membership.

At any rate, it is important to come up with a list of companies, to know who can reach them, and to do this before the launch.


In many respects, launching a project is similar to launching a new product. You need to build a brand, and we have a few key items we look for in this process. Digital assets such as logos and presentation templates need to be created, as do style guides. Events need to be planned, both your own as well as some that are organized outside your team.

One thing that can get overlooked is registering your project’s social media handles, even if you don’t plan to use them immediately.  Transferring ownership can be difficult after the fact.

Finally, it’s important that there be a distinction between developer and end user outreach. The two audiences may overlap, but rarely are they exactly the same. As such, there will be different messages, delivered at different times.


Compliance and certification requirements are often tied to the rights to use a project’s trademark. In some cases, it can also be tied to the project’s IPR policy. Our process asks relevant questions such as, “Will there be a defined spec, or will it be derived from the code?” “Do you need to plan for plugfests and test labs, or will everyone use the same implementation?”


Finally, this checklist ends with infrastructure. This is one topic that can often lead to bikeshedding, simply because everyone has a favorite bug tracker/build system/wiki/whatever and it’s an easy problem to tackle. However, the key question is not “What do you like to use,” but rather, “What will help the project succeed?”

The preceding questions should give insight whether there are other external factors that would influence your infrastructure decisions. For example, if your industry builds their stacks with Yocto, you know what you should use (if you want your project to be adopted).

Wrapping up

Of course, there’s a lot more depth than what I wrote here. We’ve developed a 2+ day workshop that walks internal Samsung teams through all of their decisions, as launching a new project is not a decision to be taken lightly. However, once you’ve done it a few times and taken note of what works and what doesn’t, it becomes considerably easier.