Here are some of the misunderstandings around open source software that I hear every day. Feel free to add your own!
- The most important thing is whether you modify the code or not.
I keep hearing from people, “we’re ok because we didn’t modify it.” Or they create a policy that doesn’t allow anyone to modify open source code because then they think they are risk free. I agree, modifying open source software may cause a support problem, but it isn’t what triggers anything special in the license. The GPL says that if you make modifications to the software, you have to distribute those modified source code files with your binaries. But it is the distribution that triggers that clause, not the modification. So if you distributed the binaries unmodified, you’d have to distribute the source code. And if you linked statically to those GPLed binaries, you’d have to distribute your source code as well. But only if you distributed your product. If you are using it in house, it really doesn’t matter whether you modified it or not. Except from a support perspective. - If you modify GPL code, you have to give the modifications back to the project.
I highly recommend you do give your modifications back – it’s the nice, neighborly thing to do. It also makes your life easier to be using the standard version and not your own forked version. However, you don’t have to give those modifications back. You only have to give the
modified source code to anyone you give the binaries too. Now note that they can give that modified source code to anyone they want, which brings me to the next point. - Distributing GPL code under an NDA does not count as distribution.
I’m not an attorney, and it hasn’t been taken to court yet, but I think most attorneys would agree with me that distributing GPL code under an NDA not only counts as distribution but the recipient can give that GPL product to anyone they want to under the terms of the NDA regardless of what your NDA says. It’s not a risk I would take. - If you are only using open source software internally, you don’t have to worry.
First I’d argue that nothing used internally stays internal – what if you share with a partner or sell a group to another company or … That said, many licenses have clauses that trigger on something other than distribution. Sometimes they are simple, sometimes they aren’t. For example, one says that you have to buy a copy of the book for every developer on the team. Regardless of whether you redistribute or not. - Anybody can sue me for using open source wrongly.
Only the person that owns the copyright for a piece of software can sue you for violating the license. Typically, the person that owns the copyright is the person that wrote the code. They can however give that copyright away. They can even give it away and keep it for themselves so that two people hold the copyright. The copyright holder is also the only person that can change the license on a piece of software. (Note that this is why SCO lost – in the end the court ruled that SCO didn’t hold the Unix copyright.) - There is no support for open source. First off, lots and lots of products are open source. The support options vary widely from the do it yourself variety to multiple companies competing for your business.  The problem is you have to do a lot of research – the products’ name doesn’t give you a direct clue to the company that supports it. And you might come up with more than one name and have to compare several companies. But there are lots of people and companies out there supporting open source software.
- Freeware and Shareware are open source. Freeware and shareware are not open source. All things free are not open source. Just because it’s free, doesn’t mean it’s open source. The freeware and shareware licenses are very different and do not meet any of the traditional open source guidelines like providing source code, allowing modification and redistribution.
Got any others?