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.
Open source audits are never as simple as they seem. You have successfully tackled your first open source audit and you are probably asking yourself what to do to help with future audits. The answer is: preparation. The steps you take before you start the auditing process will make the project that much more successful. To help with future audits, let's look at a few tips and tricks you can use before you begin an audit:
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.