The "risk of beind sued for IP infringement" isn't really the right way to think about it. This isn't a "risk" thing.
Either
You have a license and can use the source. There's no risk. You have the license. There can't be a lawsuit.
Or
You don't have a license and you're in violation. Effectively, you will be sued. There's no risk here, either. You're in violation of someone's copyrights (or worse).
Companies are averse to Open Source for a variety of strange reasons. Risk of lawsuit is not one of them.
Things I've heard.
What if it has a virus?
What if it doesn't work as advertised?
What if it "crashes" something? Who do we sue?
None of these are "risk" items. They're "due diligence" items. And mostly, they're easy to address: pick products with enough users that someone else vets the code before you; QA open source as if one of your own people typed it in. Except for one.
This leads us to the real reason. [Hint: It's not "risk of lawsuit".]
There's no one to sue when you didn't perform due diligence on open source.
Most shops don't have real solid configuration management or QA policies (the kind that would stand up in court as best practices). Until they have these things in place, they don't dare think about introducing open source for which you really need solid QA and configuration management.
I think what your company is really worried about is you directly copying large segments of code for which there may be licensing issues, presenting a legal problem to the company if they are caught using it. However, you may read blogs or other non-licensed code and discover a solution which works for the particular problem you are working on. In that case, you would be better off rewriting the code (that is, look at the solution and reproduce it) as opposed to just copying the code and making modifications to it. At my company, that is what they generally recommend for using non-proprietary code.
As well, for small amounts of code (e.g. a standard implementation of a cache) where everyone implements this the same way, every time, your company is unlikely to be afraid of using outside code, as long as you are sure to test it carefully.
By "indemnification", I assume they mean assurance that the code is free of copyright or patent or maybe trade secret encumbrance that they don't know about up front, or that somebody's willing to compensate them if something like that turns up. I've never been in a company that worried about this, nor have I heard of one before.
It's not clear what you actually want here, other than sympathy (and I do have sympathy for people trapped in corporate foolishness). It sounds like the policy is quite rigid, if you're worried about sample code in books. This is a bad policy, and will hinder you, but I don't know what you can do about it. Unlike Joel's blog post on getting things done as a grunt, it sounds like you can't just start doing thing intelligently without being in clear violation of corporate policy.
Not knowing your situation, my suggestion would be to look for another job. This one will definitely stifle your professional growth, and a company with that policy is unlikely to be reasonable about it.
(It would be nice if you could assure them there was no danger, but that's not true. People have lied about copyrights, although open source projects tend not to, and only a fool would claim definitely that a large chunk of code did not infringe on any patents in the US; even if it was written a year before software patents were first awarded, that would be merely good grounds for a court fight, rather than avoiding a court fight. GPLed software is actually better than BSD software, since it requires some patent licensing downstream, but it can't deal with third-party patents. Of course, if they're that worried about being sued, writing in-house software is no solution. That can infringe on patents.)
You could rename the variables and how would they find out? Do they check every line of code ? Universities tell you that all the time, not to copy code without referencing. Why don't you try coding something and useing parts of code you find in the Internet?
Generally you will use more from communities like stack overflow or blogs than from open source projects.
Finally since the code has no warranties, its at your own risk.. well the is the same case if you came up with the code by yourself: its at your own risk.
It could be that I don't understand licensing very well either. From the companie's perspective (I suppose) they don't want to incur any risk of beind sued for IP infringement.
My thought is that you have to weigh risks. Taking a coding snippet from a book is low risk. Incorporating code from an open source library could be high-risk. I say make decisions based on how much risk you are willing to take.
I'm not sure if I understood correctly. If you are saying that license infringement is fine when you don't get caught, I will have to disagree with you.
You can learn by reading code without breaking laws or getting fired. Just don't copy the code to your company's code base if the license doesn't allow it.
If you're not aware of the "clean room" concept, then there's always that approach. Have a friend look at some open source code and get them to tell you how they think it works. Diagram it out, and then code it yourself.
请记住，并非所有开源都是 GPL。 您的公司可以随意复制 BSD 许可的代码。 BSD 许可的代码已进入 OS X（这可能是我今天最大的轻描淡写），并在较小程度上进入了 Windows NT。
Keep in mind that not all Open Source is GPL. Your company can copy as much BSD-licensed code as they like. BSD-licensed code has made it into OS X (that's probably my biggest understatement of today) and to a lesser extent Windows NT.
发布评论
评论（7）
“因知识产权侵权而被起诉的风险”并不是真正正确的思考方式。 这不是一个“风险”的事情。
您
或者
公司出于各种奇怪的原因而反对开源。 诉讼风险不是其中之一。
我听说过的事情。
如果有病毒怎么办？
如果它不像宣传的那样工作怎么办？
如果它“崩溃”了什么东西怎么办？ 我们该起诉谁？
这些都不是“风险”项目。 它们是“尽职调查”项目。 大多数情况下，它们很容易解决：选择拥有足够用户的产品，以便其他人在您之前审查代码； QA 开源，就好像您自己的人输入的一样。除了一个。
这引导我们找到真正的原因。 [提示：这不是“诉讼风险”。]
如果你没有对开源进行尽职调查，就没有人可以起诉。
大多数商店没有真正可靠的配置管理或质量保证政策（那种可以在法庭上站得住脚的最佳实践）。 在他们把这些事情落实到位之前，他们不敢考虑引入真正需要可靠的质量保证和配置管理的开源。
The "risk of beind sued for IP infringement" isn't really the right way to think about it. This isn't a "risk" thing.
Either
Or
Companies are averse to Open Source for a variety of strange reasons. Risk of lawsuit is not one of them.
Things I've heard.
What if it has a virus?
What if it doesn't work as advertised?
What if it "crashes" something? Who do we sue?
None of these are "risk" items. They're "due diligence" items. And mostly, they're easy to address: pick products with enough users that someone else vets the code before you; QA open source as if one of your own people typed it in. Except for one.
This leads us to the real reason. [Hint: It's not "risk of lawsuit".]
There's no one to sue when you didn't perform due diligence on open source.
Most shops don't have real solid configuration management or QA policies (the kind that would stand up in court as best practices). Until they have these things in place, they don't dare think about introducing open source for which you really need solid QA and configuration management.
我认为你的公司真正担心的是你直接复制可能存在许可问题的大段代码，如果他们被发现使用它，就会给公司带来法律问题。 但是，您可以阅读博客或其他未经许可的代码，并发现适用于您正在处理的特定问题的解决方案。 在这种情况下，您最好重写代码（即查看解决方案并重现它），而不是仅仅复制代码并对其进行修改。 在我的公司，这就是他们通常建议使用非专有代码的做法。
同样，对于少量代码（例如缓存的标准实现），每个人都以相同的方式实现，每次，只要您确保仔细测试，您的公司就不太可能害怕使用外部代码。
I think what your company is really worried about is you directly copying large segments of code for which there may be licensing issues, presenting a legal problem to the company if they are caught using it. However, you may read blogs or other non-licensed code and discover a solution which works for the particular problem you are working on. In that case, you would be better off rewriting the code (that is, look at the solution and reproduce it) as opposed to just copying the code and making modifications to it. At my company, that is what they generally recommend for using non-proprietary code.
As well, for small amounts of code (e.g. a standard implementation of a cache) where everyone implements this the same way, every time, your company is unlikely to be afraid of using outside code, as long as you are sure to test it carefully.
通过“赔偿”，我认为他们的意思是保证代码不受版权或专利的影响，或者可能没有他们事先不知道的商业秘密负担，或者如果出现类似的情况，有人愿意补偿他们。 我从来没有在一家公司担心过这个问题，我以前也没有听说过这样的公司。
除了同情（我确实对陷入公司愚蠢困境的人们表示同情）之外，还不清楚你在这里真正想要什么。 如果您担心书中的示例代码，那么听起来该政策相当严格。 这是一个糟糕的政策，会阻碍你，但我不知道你能做些什么。 与乔尔关于如何以咕噜的方式完成工作的博客文章不同，听起来你不能在不明显违反公司政策的情况下开始明智地做事。
不知道你的情况，我的建议是另找工作。 这肯定会扼杀你的职业发展，而有这种政策的公司不太可能对此合理。
（如果你能向他们保证没有危险，那就太好了，但事实并非如此。人们在版权问题上撒了谎，尽管开源项目往往不会这样做，只有傻瓜才会明确声称一大块代码没有侵犯版权即使它是在软件专利首次授予之前一年编写的，这也只是法庭诉讼的好理由，而不是避免法庭诉讼 GPLed 软件实际上比 BSD 软件更好。需要一些下游专利许可，但它无法处理第三方专利。当然，如果他们担心被起诉，那么编写内部软件并不是侵犯专利的解决方案。）
By "indemnification", I assume they mean assurance that the code is free of copyright or patent or maybe trade secret encumbrance that they don't know about up front, or that somebody's willing to compensate them if something like that turns up. I've never been in a company that worried about this, nor have I heard of one before.
It's not clear what you actually want here, other than sympathy (and I do have sympathy for people trapped in corporate foolishness). It sounds like the policy is quite rigid, if you're worried about sample code in books. This is a bad policy, and will hinder you, but I don't know what you can do about it. Unlike Joel's blog post on getting things done as a grunt, it sounds like you can't just start doing thing intelligently without being in clear violation of corporate policy.
Not knowing your situation, my suggestion would be to look for another job. This one will definitely stifle your professional growth, and a company with that policy is unlikely to be reasonable about it.
(It would be nice if you could assure them there was no danger, but that's not true. People have lied about copyrights, although open source projects tend not to, and only a fool would claim definitely that a large chunk of code did not infringe on any patents in the US; even if it was written a year before software patents were first awarded, that would be merely good grounds for a court fight, rather than avoiding a court fight. GPLed software is actually better than BSD software, since it requires some patent licensing downstream, but it can't deal with third-party patents. Of course, if they're that worried about being sued, writing in-house software is no solution. That can infringe on patents.)
您可以重命名变量，它们将如何找到答案？ 他们检查每一行代码吗？ 大学一直告诉你，不要在没有引用的情况下复制代码。 为什么不尝试编写一些代码并使用在互联网上找到的部分代码呢？
一般来说，您会更多地使用堆栈溢出或博客等社区，而不是开源项目。
最后，由于代码没有保证，因此您需要自行承担风险。如果您自己编写代码，情况也是如此：您需要自行承担风险。
希望有帮助...祝你好运。
You could rename the variables and how would they find out? Do they check every line of code ? Universities tell you that all the time, not to copy code without referencing. Why don't you try coding something and useing parts of code you find in the Internet?
Generally you will use more from communities like stack overflow or blogs than from open source projects.
Finally since the code has no warranties, its at your own risk.. well the is the same case if you came up with the code by yourself: its at your own risk.
Hope that helps... and good luck.
我不确定我理解是否正确。 如果您说只要不被抓到就可以侵犯许可，那么我将不得不不同意您的观点。
您可以通过阅读代码来学习，而不会违反法律或被解雇。 如果许可证不允许，请勿将代码复制到公司的代码库。
I'm not sure if I understood correctly. If you are saying that license infringement is fine when you don't get caught, I will have to disagree with you.
You can learn by reading code without breaking laws or getting fired. Just don't copy the code to your company's code base if the license doesn't allow it.
如果您不知道“洁净室”的概念，那么总有这种方法。 让朋友查看一些开源代码，并让他们告诉您他们认为它是如何工作的。 把它画出来，然后自己编码。
如果它适用于 IBM，对吗？
If you're not aware of the "clean room" concept, then there's always that approach. Have a friend look at some open source code and get them to tell you how they think it works. Diagram it out, and then code it yourself.
If it worked for IBM, right?
请记住，并非所有开源都是 GPL。 您的公司可以随意复制 BSD 许可的代码。 BSD 许可的代码已进入 OS X（这可能是我今天最大的轻描淡写），并在较小程度上进入了 Windows NT。
Keep in mind that not all Open Source is GPL. Your company can copy as much BSD-licensed code as they like. BSD-licensed code has made it into OS X (that's probably my biggest understatement of today) and to a lesser extent Windows NT.