License agreements with MCUs

[lollandster]

I'm sorry for asking such boring questions, but I guess this too is part of the game.
I'm just finishing my first professional embedded project at the company I work for and now the license agreements gets focus. We have a "Open Source Review Board" that will look at the licenses. Since this project is part of testing equipment and not the final product, it's only a formality at this point. But it does rise some questions for me.

How do you deal with licenses when using libraries?
For STM32 and TM4C the license simply say; don't edit the license text and include the license text in the documentation. That's simple.
For NXP LPC the license text was mostly the same, but when starting a c++ project from the MCUXpresso IDE one of the included files included a license from Code Red Techonlogies. The Red license is very aggressive and say things like criminal sanctions and civil liabilities, but it fails to mention any restrictions or provide a link to a full text.
Silicon Labs include a link to their Master Software License Agreement. I tried to read and understand that license, but had to give up. I have no idea how to use Silicon Labs EFM32 legally so I'm just going to ignore their existence. Luckily I bought the Wonder Gecko while it was $30, now it's $100 for some reason.

The C libraries (like stdint.h) also includes copyright text, but I find it hard to know what is used and not used (I'm still a beginner). Do you pay attention to the copyright text in files that is included by libraries, or just the copyright text for the library itself?

Do you have any recommendations for the best vendor?
I don't mind if the copyright license for MCU-specific files limits modification or use on other MCUs, but I don't like that most of them requires the license to be reproduced in the documentation. Nothing in the copyright text is applicable to the end user so I don't understand why it must be included with the final product.

[mikeselectricstuff]

If any MCU maker made any attempt to take any legal action for using their libraries on their parts in any way it would be suicidal for them - not going to happen.
It's just their legal dept trying to justify their existance.

[Ian.M]

IANL, and nor are you.  Determining policy for handling 3rd party licencing is a job for your company's legal team, at the direction of CxO level company executives.  All you can do is ask your head of department for a copy of any existing licence policy, and do your best to comply with it.  If you have a concern about a specific licence's compatibility with company policy, that's something you should raise with the review board.   However it would be worth running your queries past your boss first, allowing enough time to re-examine any issues before the review board meeting.  Get written confirmation (or printed email - with headers) if your boss orders you to ignore any concerns you have (enough paper to CYA  ).

If there isn't an existing written policy that's been approved by the legal team, or your boss isn't willing to listen to your concerns about licencing issues, or doesn't want to put orders in writing, you'd better start polishing your resume as all it would take is ONE breaking news story, whistle blower, or lawsuit for your company to look for the least 'valuable' employee 'responsible' to throw to the wolves, and as the newbie, that's probably *YOU*. 

[donotdespisethesnake]

I generally agree with the other posters. If there is a legal compliance aspect, get copies of the licenses and send to corporate legal, it is not your job to be a lawyer.

In general you will not have problem with vendor supplied code, all they care is that you are buying their chips. If you are using their code on other vendor's chips, that would be a problem.

More and more vendors are bundling open source code in their packages (both permissive and copyleft), but also third party libraries which appears as a "free download" in your IDE but if you read the small print actually requires royalties paid to a third party if used for production.

Unfortunately there are dozens of OSS licenses, as well as standard OSS with custom provisions, and vendors like to create their own proprietary license from scratch.

So as a developer, you need to keep on file:
1. What libraries and source code packages you have used
2. Copies of the download links and license text for each

Make the data set available to legal dept.

[AndyC_772]

It's quite usual for embedded developers to consider licensing when deciding which tool chain and libraries they're going to use. They may not perform the final sign-off, but are often the best placed people to understand which licences apply, how the software is used, and whether any conflicts might arise.

In a small company there won't be a team of in-house lawyers that you can just dump the problem onto. A senior developer may also be a senior member of the company, and ultimately responsible for the decisions they make and the consequences.

Being aware of the wider implications of their decisions is a hallmark of a good engineer. We can't always just swat the problem aside and claim it's someone else's responsibility.

[donotdespisethesnake]

Software licenses are legal contracts, the same as contracts the business enters into with other suppliers. Even Senior Developers are not responsible for business contracts, these should be the responsibility of senior managers or directors.

I would say a professional Software Engineer should not take responsibility for subjects outside their remit. Equally, managers should not swat away their responsibility.

Of course, if you are in one of those small companies where cowboy rules apply, and if the company goes bust the directors with a new one a few months later, then yeah, do what the hell you like. 

[andyturk]

Software licenses are legal contracts, the same as contracts the business enters into with other suppliers.

Not exactly. Contracts are negotiated, involve an exchange of consideration, and are signed by both parties. Because of the signature aspect, contracts are much more visible to the legal department.

OEM licenses are a surprise hidden at the bottom of the software cereal box... from the management point of view, anyway. Nobody would even know a license was there unless an engineer brought it to someone's attention, and usually it's the engineer who decides which software gets integrated into the product.

IMO, it's very much the firmware team's resposibility to keep track of which licenses appear in production code. The main requirement is to be able to tell which code has which license should someone from the legal side ask. Management may set guidelines about licenses that incompatible with the business, and the firmware folks may need to choose between different code/vendors based on how the licensing works.

[ralphrmartin]

The problem here is "just finishing my first professional embedded project". The time to study licences is when you are deciding what libraries etc you are going to use in the project, at the beginning. Find which ones you think you want to use, then send them to the legal team to see if such usage is likely to cause problems later, when deploying / shipping the end-product.

[lollandster]

The problem here is "just finishing my first professional embedded project". The time to study licences is when you are deciding what libraries etc you are going to use in the project, at the beginning. Find which ones you think you want to use, then send them to the legal team to see if such usage is likely to cause problems later, when deploying / shipping the end-product.

I'm still learning. I did read the licenses before using them, I just didn't put much thought into it at the start.

It's quite usual for embedded developers to consider licensing when deciding which tool chain and libraries they're going to use. They may not perform the final sign-off, but are often the best placed people to understand which licences apply, how the software is used, and whether any conflicts might arise.

In a small company there won't be a team of in-house lawyers that you can just dump the problem onto. A senior developer may also be a senior member of the company, and ultimately responsible for the decisions they make and the consequences.

Being aware of the wider implications of their decisions is a hallmark of a good engineer. We can't always just swat the problem aside and claim it's someone else's responsibility.

Thanks for the insight.

[mac.6]

Just stay away from any GPL code and you will be fine with most vendor licence (who themselves stay away from GPL).
Most of these licences giberish is to avoid dumbasses that take any licenced code and put them in GPL code, which happens all the time.

[Karel]

I just stay away from any libraries.
In case we need USB or LAN connectivity, we use a SOC with Linux.
It's not rocket science to skip HAL or Harmony and write your own clock setup, drivers for UART, SPI,I2C, etc.
SD-card and FAT32 takes more effort but it's worth to do it once and for all.

[AndyC_772]

Just stay away from any GPL code and you will be fine with most vendor licence (who themselves stay away from GPL).
Most of these licences giberish is to avoid dumbasses that take any licenced code and put them in GPL code, which happens all the time.

This is a big deal - some (most?) variants of GPL contain a clause which can require your code (which incorporates GPL code) to be released under GPL itself. Obviously this is OK if your intent is to develop an open-source project, but if your own code is confidential and proprietary, it's a complete no-no.

This is also where it gets technical; even if your company does have legal specialists, they won't necessarily know how you're making use of any GPL code, ie. are you just making use of it unmodified, or are you making modifications to it (in which case you must make these public), or is your whole project effectively a derived work. Depending on these technical details, your company may have very different obligations, some of which are harmless, and others ruinous.

For all the restrictions which commercial licences impose, I've never seen one which imposes this requirement to disclose and give up your own IP to the world.

[ejeffrey]

For all the restrictions which commercial licences impose, I've never seen one which imposes this requirement to disclose and give up your own IP to the world.

I mean, the intent is mostly intended to keep people from making modifications to GPL code (which they get for free) and not sharing those back upstream, or with their customers.  The fact that in the world of microcontrollers "library" code and "application code" often can't easily be separated is obviously annoying.  But consider the alternative: Intel adds Linux kernel support for their latest CPU to the linux kernel and then distributes it in binary only format.  If you have an Intel CPU you need to use their kernel.  They have effectively taken ownership of the entire kernel for updating a few structures.  This isn't some hypothetical situation: it is exactly what happened in the commercial UNIX world and was a large factor in that markets destruction.  Yes, from the perspective of a commercial developer it is pretty extreme, but the purpose is to support free software, not to make the lives of commercial developers easier.

Also, if you want to see bad licenses, I have seen "commercial" software licenses that claim to grant the copyright owner unlimited access to any of your proprietary / internal data for the purposes of doing compliance audits.

[sokoloff]

For all the restrictions which commercial licences impose, I've never seen one which imposes this requirement to disclose and give up your own IP to the world.

I mean, the intent is mostly intended to keep people from making modifications to GPL code (which they get for free) and not sharing those back upstream, or with their customers.  The fact that in the world of microcontrollers "library" code and "application code" often can't easily be separated is obviously annoying.

I see it slightly differently. There's nothing in GPL that requires you to share your modifications to GPL code back upstream. You may make copies of GPL software, modified or unmodified, compile and run those programs, so long as you don't ship the program to anyone else. Up to this extent, you don't have to share your source code changes with anyone. This happens all the time in the corporate world and does not represent a license violation of GPLv2, GPLv3, nor LGPL.

I believe the intention of the GPL is to preserve end user freedom to effectively modify the programs that they run and this is reflected in the preamble to the license text as well as by the license clauses embodied within.

When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.

To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.

For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.

The basic permissions clauses in v3 is what allow you to run modified versions of the code on your own and, so long as you don't give the binaries to anyone else not under your control, you don't have to publish your modifications. You have this same right under GPLv2, but there's no single, specific clause to allow it, rather you have to infer it from the lack of obligation under any other clauses.

You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force.

On the obvious annoyance front, this is why LGPL, MIT, and Apache [and similar non-copyleft] licenses are popular in the microcontroller and general F/OSS world.

[ehughes]

I can tell you that the MCU vendors don't give a rats ass about what you do with that code unless you plan on holding them liable.     

Unless you are working on medical, aerospace no one gives a crap.      The only reason they provide code is the masses of people who want examples. They are only concerned with putting on a header that releases them from any liability.  It is a waste of time to even worry about it.