In an effort to save time and money, and leverage valuable code bases, most companies use open source software. Many companies, large and small, have formal open source policies. Even more companies have informal open source policies, e.g., a company may not want to use any software under a General Public License, and that information is spread via word of mouth. I often hear people mention that they have been ordered to write an open source governance policy, and they are not sure where to start. This blog covers what an open source policy is, and the various topics to address when developing an open source policy.
It’s important to scan your source code for open source software to make sure your company complies with the licenses you’re using.
I would argue that ensuring you are in compliance with open source software (OSS) licenses is easy for the most part. As we have explained in past blog articles, the hard part is determining which OSS packages you have in your product, and what the associated licenses are for each package. For example, what if you have downloaded some free code from the Internet and the author has not provided a specific license or copyright notice; how do you comply? But, once you have completed your diligence and determined your list of OSS and confirmed licenses, compliance is the easy part. In this article, I will explore what it means to be in compliance.
You might politely answer them by asking a question similar to this one in return.
A number of interesting press releases by industry experts published this year show some of the most impressive data ever on the exponential growth of open source software adoption. Open source buzz is humming both behind the scenes and on the front page in just about every major industry that touches a piece of modern technology!
The growing acceptance of open source software in the workplace prompts a strong push for open source training for recent college graduates. I cannot speak for all recent college graduates, and I cannot speak for every university, but I can speak from my experiences and the experiences of others I have talked with on this subject.
Before I jump into my topic, here is some background for those new to open source licenses.
In my last two posts, I discussed the evolution of open source knowledge: where we came from, where are we now, and how did we get here. I provided some examples of common misunderstandings and knowledge gaps and suggested that such gaps may be due to the need to take action without taking as much time to prepare and plan as is optimal. The sum total is that misconceptions and misunderstandings about open source persist both within and outside the software industry.
What is an open source software (OSS) bill of materials (BOM)? In the simplest terms, it is a list of the OSS components used in an application. But, it can actually be much more. Most OSS BOMs will, at a minimum, also contain the licensing information associated with each OSS component.
I am asked two very reasonable questions, on a very regular basis, by some very interesting people.
If you read a post on The Enterprise OSS Blog, please leave a comment. Let us know what you think, even if it's just a few words. Comments do not require approval, but they are moderated.OpenLogic reserves the right to remove any comments it deems inappropriate.