Addressing concerns over using open-source libraries in closed-source projects [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 7 years ago.

Improve this question

Background: There are a couple of concerns that are not core business for us. They are essential to our core business, but we have no business writing on our own, in terms of manpower, time, and expertise. I am familiar and very comfortable with some open-source implementations, using closed-source-friendly licenses, that could fill these gaps. Closed-source alternatives I either could not find, or were crap.

I put together an informal proposal to show my boss, including the original licenses for each project for legal review. Being a business owner that knows little about the world of open-source, he was initially hesitant when he realized some of these libraries were. I tried to educate him 开发者_运维技巧to the best of my abilities (I'm no open-source warrior myself), but he did bring up some valid questions that, in some cases, I don't feel I answered as well as I could have.

Concerns (worded from my boss's prospective)

• How do we know and ensure there is no malicious code in an open-source project? Read and understand every line? At that point we could have just written it ourselves!
• Who do we blame when things go wrong? With support licenses and a responsible party, we can get things fixed. And if they fail to come through, well... you know.
• How do we establish or measure that an approach or implementation in an open-source project is sound, efficient, or good quality?
• What sort of liability do we open ourselves up to, in terms of licensing [granted, this is more a question for lawyers and an issue of RFTL].

Question: How have or would you have addressed these concerns?

---

How do we know and ensure there is no malicious code in an open-source project? Read and understand every line? At that point we could have just written it ourselves!

• Same problem with closed source. Actually worse with closed source. With open source at least you CAN review it yourself, or you can take someone else's word for it. With closed source, taking someone's word for it is your only option.

Who do we blame when things go wrong? With support licenses and a responsible party, we can get things fixed. And if they fail to come through, well... you know.

• Probably the biggest issue. This depends on which particular solutions you're using. Some things are backed by a reputable vendor (e.g. Red Hat) whereas others have virtually no support. But that "you know" is critical here: ultimately there is no way to guarantee that someone will fix bugs that you encounter when you are using closed source. At least with open source you can hire a 3rd party consultant to do the job, for the right price, because you have the source.

How do we establish or measure that an approach or implementation in an open-source project is sound, efficient, or good quality?

• The same way you would with any other code? I don't have any better answers for this one.

What sort of liability do we open ourselves up to, in terms of licensing [granted, this is more a question for lawyers and an issue of RFTL].

• Yep, have a lawyer advise you on this. Every tech business should employ a lawyer anyway. The answer will depend on the specific licenses you're dealing with and what exactly you plan to do with the software you develop.