There is a story, possibly apocryphal, that during Mahatma Gandhi’s first visit to England, a journalist asked him, “What do you think of western civilization?” to which he replied, “I think it would be a good idea.” Whenever someone asks me about software security, I often hear in my mind an echo of Gandhi’s clever response. Software, by its nature, will always have security flaws, and moreover, software users will continue to make bad decisions, reveal passwords, and release information that is supposed to be kept confidential.
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.
Yesterday it was publically announced that two of the world’s best-of-class software development solution providers have joined forces as one, creating an entirely new class of provider with no real peers in perhaps the most critical segment of the IT infrastructure market.
Today’s article considers some of the similarities, and differences, between community versions and enterprise versions of open source software. Mature open source usually comes from one of two sources of global communities: 1) communities like the Apache Software Foundation that are not directly affiliated with a specific corporate entity, or 2) commercial and open source software companies.
As a developer I'm always keeping my eye out for new technologies that can help me do my job better or faster. There's a saying in this industry: "work smarter, not harder." If I can use a piece of existing code instead of writing it from scratch, I will, unless there's a good reason not to. And diving into a new language, library, framework, or database can be like wearing a brand new pair of jeans. The novelty is exciting.
Making the case internally to embrace open source software as a viable, and improved alternative to commercial software, is no easy task. This is why I have outlined for you 4 tools to help solidify your case for change, and prepare you for opposition you might encounter.
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.