ARM Development: License concerns about opensource - Page 1
Forum section: electronics / general

author: luisr
author_rank: Contributor
timestamp: September 10, 2014, 04:59:51 pm
content: I've been evaluating some IDEs for cortex-m developing (KEIL MDK-ARM 32KB Limited, Eclipse, IAR 32KB Limited and Rowley Crosswork ersonal license)From my point of view Rowley Crossworks is hard to beat with it's personal license, it has a "feature" that annoys me but not a show stoper. I was about to purchase a personal license few days ago but didn't do it because a question came into my mind: I will not develop products to make profit but I might be interested in releasing the source code of my projects... but according to the following line in Rowley's licensing page: "Note that you cannot redistribute any source code that has Rowley Associates copyright noticies on it." it's not allowed to release any source that have their copyright notice on it!Now, correct me if I'm wrong bus last time I tested their software even the startup code assembler file for the generic cortex-m project template has rowley's copyright, so it's not possible to release a project created with that template!One way to overcome this might be creating an empty project and start from scratch, but not sure if that would be legal; So the only "safe" option is using Eclipse with GNU ARM plugin (or just GNU GCC) and not relying on third party libraries?I would appreciate your comments on this, and please excuse any grammar/orthographical errorsThanks

author: dannyf
author_rank: Super Contributor
timestamp: September 10, 2014, 05:19:58 pm
content: You probably want to see how the copyright is applied for re-distribution. CMSIS for example is copyrighted but allows free distribution as long as it is for ARM chips/cores.QuoteNot sure value those guys bring that justify it over freebies like commercial demos + CoIDE, emblocks, etc.

author: luisr
author_rank: Contributor
timestamp: September 11, 2014, 11:13:09 pm
content: Quote from: dannyf on September 10, 2014, 05:19:58 pmWell, to me Rowley is very clear on that matter: No redistribution of any file which have their copyright mark. I've been keeping an eye on CMSIS, even tried to use "vanilla" files provided by ARMQuote from: dannyf on September 10, 2014, 05:19:58 pmCouple of thing but the most important to me: is cross-platform (MAC/Linux), have support for J-Link, works out-of-the-box and have support + libraries for my target chip (LPC4330). These arguments are somewhat silly because the same can be achieved with eclipse but I'm unable to debug my projects inside Eclipse, that's another history though.

author: ElektroQuark
author_rank: Unknown
timestamp: September 12, 2014, 07:06:29 am
content: Quote from: luisr onTodayat 10:13:09 AMHave you triedTHIS?It's a pluging for use J-Link with Eclipse. It works.

author: westfw
author_rank: Super Contributor
timestamp: September 12, 2014, 07:16:19 am
content: The libraries typically don't have their source included in the project, do they?

author: janekm
author_rank: Unknown
timestamp: September 12, 2014, 08:32:36 am
content: Quote from: luisr on September 10, 2014, 04:59:51 pmWell... at the risk of stating the obvious, if you want to release your source under open source then you choose the libraries that have compatible libraries, not Rowley. You're hardly spilled for choice on ARM here; CMSIS covers the base cpu core support, most IC manufacturers release their support libraries sensibly (with some annoying exceptions), and there's also mbed.org which gives you a fairly comprehensive library with cross-vendor support...I'd treat the libraries separate from the IDE. You don't want to be stuck with a particular IDE just because you decided to use the IDE vendor's libraries!It's true that Eclipse feels a bit janky and fragile at times (I'll try to refrain from showing my disdain for Java too openly, that's neither here nor there at the end) but it does work with a little perseverance.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: September 12, 2014, 09:05:04 am
content: I don't see the problem - your project is designed to compile under a particular toolchain.You distribute your files, people can compile it with their copy of the same toolchain. No need to distribute anything of theirsCompilers never have restrictions on distributing object code as it would defeat their whole reason to exist.

author: janekm
author_rank: Unknown
timestamp: September 12, 2014, 09:50:21 am
content: Quote from: mikeselectricstuff on September 12, 2014, 09:05:04 amIt doesn't have to be an issue, but can be, and it feels "unclean" for those coming from a certain camp of open source enthusiast; under that ethos it is considered very important to have the libraries and toolchain open source or your code would be considered tainted (it's all a bit too political for my taste tbh).It can be a real hassle though; for example, the otherwise great NRF51822 combined Cortex M0 / BLE radio requires a dev board to be purchased before giving access to the SDK supplied by Nordic Semiconductor, so that puts up a real barrier to the distribution of open source code built on that foundation.

author: dannyf
author_rank: Super Contributor
timestamp: September 12, 2014, 10:33:22 am
content: QuoteWhen that happens, people usually relax the restrictions to a point where a solution exists.If you are unwilling to relax your restrictions, there may not be a solution. That's just life.

author: romantao
author_rank: Contributor
timestamp: September 12, 2014, 08:41:45 pm
content: Hi,i've been working with a arm cortex m4 lpc4337 using this toolchain, wich has no code size limits and enables the hardware floating point for example.https://github.com/vedderb/summon-arm-toolchain/regarding the device drivers, i use the ones provided by lpcopen, which are compatible with nxp mcu:http://www.lpcware.com/content/nxpfile/lpcopen-platformthe only thing i'm not quite sure about licensing is the linkerscript i used. it was based on the one generated by the codered toolchain and slightly modified to allow the use of all the memory regions.regards

author: nctnico
author_rank: Super Contributor
timestamp: September 12, 2014, 09:35:51 pm
content: I'd take no chance and don't include anything from which it isn't clear it can be distributed or not. A safe route to go is to use the CMSIS bits to get the CPU going. I don't see why Rowley is using assembly in the startup of a Cortex Mx device. It is not necessary at all.There is also a choice to be made regarding compatibility. Each toolchain (C compiler + linker) has a slightly different C dialect for putting objects (variables, functions, etc) into a certain region of the memory. IMHO using GCC is a safe choice since many compilers are adapted to understand the GCC C dialect.

author: sporadic
author_rank: Regular Contributor
timestamp: September 12, 2014, 09:59:59 pm
content: This is where Atmel really shines IMO. Chips are a little pricier but their IDE and libraries are all free and use the GCC toolchain. Nice datasheets too.

author: dannyf
author_rank: Super Contributor
timestamp: September 12, 2014, 10:10:50 pm
content: QuoteThat's pretty much true for almost all arm chips, if you use CoIDE.and in the case of STM32, you don't have to pay more.

author: Fred27
author_rank: Unknown
timestamp: September 12, 2014, 10:12:33 pm
content: Quote from: luisr on September 10, 2014, 04:59:51 pmSo delete the copyright notice. It *had* Rowley Associates copyright notice. It doesn't now.

author: westfw
author_rank: Super Contributor
timestamp: September 12, 2014, 10:35:58 pm
content: Which source files with Rowley copyright does a project actually include? Usually, libraries are linked rather than included, at least for things like the standard C libraries. (although there is something to be said, version-control-wise, for including source for everything that the project uses.) If it's just the startup file, you can probably replace it with the ARM-provided example startup, perhaps with a few edits. (Rowley has a lot of nerve adding their copyright to a startup.s file not substantially different from the ARM template (if that's what they've done.) It reminds me of when Berkeley got people annoyed by adding a copyright to the "true" shell script.)(OTOH, licensing is pretty out-of-control. Use of GPL for libraries is common (rather than even LGPL) (and most people aren't quite sure of how LGPL applies to embedded systems, either.) And then you have vendors like TI plastering their copyright on files generated by their pin configuration utility... Grr.)