For the software/firmware side, hire a specialized lawyer for a few hours (in separate one-hour sessions) to explain how the various licenses work, answering your questions about them. (Of course, read about them beforehand on the web, and write down the questions that leave you uncertain.) This is what I did in late 1990s –– except the lawyer was a friend specialising in copyright training other lawyers and didn't actually charge me anything!
(I should have paid him anyway, because it would have been best money I'd ever spent for the business, it was that useful.)
The main licenses I've used are CC0-1.0/Public Domain, Apache/MIT/BSD, LGPL, GPL, and completely proprietary ones, including work under NDAs.
The hardest to initially truly understand was GPL, hands down.
Depending on the product, the client may wish to own the copyright on the work. They may or may not wish to license some of the work back to you. This is often not beneficial to either party, however: many implementations make no sense to do from scratch, and things like Ethernet/Wifi/BT connectivity is usually better implemented using externally licensed code (existing libraries). Typically such things are licensed under permissive licenses (lwIP, for example, under BSD license).
My own approach in negotiations started from the point of what the client actually needs, instead of what they want. For example, when not transferring copyrights, and only licensing the firmware/software sources to the client using a suitable permissive license, they could still have any other contractor work on and develop it further; the main limitation would be that they would be constrained to that license, so if someone else wanted to buy it off them, the license would govern that sale and could not be changed.
Because I understand the basic legal requirements and benefits of the various licenses –– not like a lawyer would, but enough to talk to a customer and explain how it works in practice, and also describe it to lawyers on both sides who can verify it is legally correct ––, I have also done mixed-license work. The tricky part is what the pertinent copyright laws consider a derivative work. On computer software, run-time linkage and published APIs are the currently accepted demarcation line, but for embedded firmwares it can be much trickier. Nevertheless, most permissive licenses like BSD do allow incorporating completely proprietary parts to otherwise e.g. BSD-licensed code, so for embedded stuff incorporating proprietary closed-source stuff, this typically only excludes GPL- and LGPL-licensed external libraries.
Having the copyright ownership and licensing be discussed first and agreed upon, before even signing a contract, is crucial for sane custom software development work. Without it, especially with "tricky clauses" in the contract, things easily become bitter and you end up paying lawyers more than the work is worth. I find it better to be crystal clear, and manage expectations from well before signing the contract. I like to be utterly predictable for the client, with zero surprises; it seems to work best.
Not everyone will agree with me here. There are many programmers who don't care about licensing at all, that they are something for someone else to worry about. I disagree. The things I write and build, I'm ready to support in the future as well, and even have an independent reviewer check for both bugs and copyright issues. I claim it makes life and work easier. So, whether your friend (almost wrote "friend" there, sorry) needs to understand the few most common software licenses or not, does actually depend on which kind of niche they intend to fit in. I would not bother trying to compete with the Chinese on price, and suggest targeting quality and reliability and verifiability and such instead.
Home
Help
Search
Login
Register
