Further developenemt of CANopenNode

[CANopenNode]

Hi,
I am the author of CANopenNode and I haven't been here for a long time. I must apology for my inactivity. The reason is, I just didn't find my time for quality maintenance of the project. I postponed maintenance for near future, which then became a far future. I also didn't read messages.

However, I still have plans for CANopenNode. My first goals are:

• remove microcontroller code from main stack. Each microcontroller family should have its own git repository, which is maintained by own author.
• Make some kind of (public) wiki for CANopenNode, CANopen objects, different microcontrollers, etc.
• Rewrite Object-dictionary part of CANopenNode. It is too complicated and lacks some functionality. I have some ideas.

I can't promised anything for now. But I asked one member, if he can take care for merging some pull requests into this project, etc.

Janez

[JuPrgn]

Hi Janez,
Nice to read that you are fine.
You have good plans for the future and your previous work helps me a lot in my projects. Thank you and all the best !

[geoffrey-vl]

Hi Janez,

It makes sense for the MCU part to be scoped within its own repo, there is no way to easily verify if its functioning well anyway. Unless you'd have maintainers for each platform/mcu. Regarding the latter, you'd probable need many maintainers, since there are a lot of MCU (ST, Renesas, NCP, ...) and platform (baremetal, freeRTOS, ARMBED, ...) options, so maybe that is not the best solution.
Still I think that only the driver implementation itself would need to be taken out (CO_driver), not the whole stack. This way we can all contribute to the same repo, and not 15 different ones.

I'd also encourage to have at least 2 people in control of the stack, so that at least you back up each-other when you're running out of time or interest.

Great to hear your reply!

[CANopenNode]

Yes, I mean, only the driver implementation itself would need to be taken out (CO_driver).

[heliochronix]

Hello!

It's good to hear from you. I think some some of us suspected something unfortunate had happened. Glad to hear that's not the case!

It's encouraging to hear there are intentions of continuing on this project. We've been basing a project off of it for the last several months, but had to fork it to correct some issues and incorporate some of the fixes @martinwag has contributed over the last couple years. It will be nice to base our project on a more dedicated project again!

[CANopenNode]

Hello,

I asked @martinwag, if he can manage some updates for this project for now.

[martinwag]

Hi,

I will take a look at this within the next few days/week, but right now I'm quite busy myself.

Please be aware that

• I'm working inside a company environment, so I don't have as much time as I like.
• We are users with a very specific use case, not a generic software house. I’ve looked at the stuff we need, fixed the bugs that affected us and implemented the features that were missing.
• I will take a look at bugs if I assume that they might affect us :-)
• Our project is at a point that most of the functions are implemented, so I will not do any major changes as this will break compatibility for us. This is especially for CANopen FD.

[henrikbrixandersen]

Good to hear that the project lives on. I am nearly finished with a driver for the Zephyr RTOS.

[CANopenNode]

Hello,

As I said above, driver files for different microcontrollers won't be included in CANopenNode in the future.

For the driver developers, who wish to share and cooperate, I recommend the following approach:

1. Make own git repo for the Microcontroller specific demo project on the Github or somewhere.
2. Include https://github.com/CANopenNode/CANopenNode as a git submodule. Add specific driver files.
3. Add a note about your specific implementation here on WIKI with some basic description and status. Write a note, even it has an Alpha status.
4. Make a demo folder, which contains project files, etc., necessary to run demo. Please specify demo board and tools used, etc.

[henrikbrixandersen]

As I said above, driver files for different microcontrollers won't be included in CANopenNode in the future.

I think that's a good idea. The current solution likely won't scale.

1. Make own git repo for the Microcontroller specific demo project on the Github or somewhere.
2. Include https://github.com/CANopenNode/CANopenNode as a git submodule. Add specific driver files.

Would these driver files need to be licensed under the GPLv2 with linking exception like the stack? Or can they be under any license given the linking exception? Zephyr RTOS itself is under the Apache License.

3. Add a note about your specific implementation here on WIKI with some basic description and status. Write a note, even it has an Alpha status.

Will do.

4. Make a demo folder, which contains project files, etc., necessary to run demo. Please specify demo board and tools used, etc.

I take it this demo (including its CO_OD.h and CO_OD.c files) can be under any license given the linking exception in the GPLv2 license of the CANopenNode stack?

[CANopenNode]

I don't have strong opinion and also I'm not an expert about licenses. I think, GPLv2 with linking exception is valid for CANopenNode.

I think, driver itself and optional supplementary files may have any license, even commercial. The same I think for CO_OD.h and .c files. If there are any other opinions, please note.

[w1ne]

Hello,

It is great to hear from you!
Thank you for continuing development.
It is good idea to separate examples and CO_driver from stack code.

Example project for specific MCU was something that will significantly speed up development for new users.
I am the author of porting CanOpenNode drivers to stm32 HAL, having working example will make implementation of CanOpenNode based project straightforward.

It was what I missed on my journey with the stack.

Thank you for the instructions for the driver devs, will follow.

[wilkinsw]

Welcome back!

I also agree with moving the drivers to their own repositories. It would be nice to be able to add CANopenNode as a module without having to exclude all of the driver folders before build.

As for the object dictionary handling, @robincornelius of libedssharp might have some ideas too. His EDS editor is still in progress, but quite powerful, and supports exporting EDS files in CO_OD.c/h format for CANopenNode.

It might be a good time to add some sort of versioning info. That way you can tag the current version as release and go about refactoring without people getting upset over changes.

[robincornelius]

Glad to see you back, I understand how busy it can get with paid work and other projects, but thanks for creating and supporting CanOpenNode this far.

On Mon, 23 Sep 2019 at 19:37, Wilkins White ***@***.***> wrote: As for the object dictionary handling, @robincornelius <https://github.com/robincornelius> of libedssharp <https://github.com/robincornelius/libedssharp> might have some ideas too. His EDS editor is still in progress, but quite powerful, and supports exporting EDS files in CO_OD.c/h format for CANopenNode. I've got no specific ideas for the internals of CanOpenNode, i'll pretty

much follow what ever gets decided (happy to help if and when i can). My ODE will just get a new exporter to generate the new or old object dictionary format as the user requires. Currently i don't support things like DEFSTRUCT either so if CanOpenNode gains new features for the OD i'll have to add them as well. But i'll certainly keep both formats, i've got a lot of code invested in the old OD and need to continute supporting that. Robin

…

[martinwag]

I've had a look, but something went wrong with permissions (no write access).

I think I'll give the current version a "v1.0" version tag and then go on and check/merge the pull requests, excluding the driver-only ones.

[CANopenNode]

Hi Martin,
I added you as a collaborator (https://help.github.com/en/articles/inviting-collaborators-to-a-personal-repository). You should have received an email (~18 days ago), where you can confirm invite.

I'm currently not on track with comments and with the stack, so I think, it is better, if you can do some updates for now. Thank You.

[martinwag]

Thanks, I've missed that.

[martinwag]

I've merged most of the stuff into CANopenNode and CANopenSocket, please have a look and check if everything is working for you.

[martinwag]

I've also cleaned up some pull requests and issues, most were either relating to drivers or stuff that is fixed now.

[henrikbrixandersen]

Good to hear that the project lives on. I am nearly finished with a driver for the Zephyr RTOS.

I regret to inform that my Zephyr RTOS integration of CANopenNode was rejected by the Linux Foundation Zephyr Governing Board due to CANopenNode not using an Open Source Initiative (OSI) approved license (see zephyrproject-rtos/zephyr#19510 (comment) for the rejection).

Is there any chance of changing the license of CANopenNode to e.g. the GNU LGPL license? I am not a lawyer, but from a laymans standpoint it looks like it gives the same obligations for making changes to the stack available for others and freedom for linking with software under other licenses as the GNU GPL with classpath/linking exceptions.

[martinwag]

I think there is no easy way for a lisense change.

• You need to ask ALL contributors for license change (except what is covered by current license).
• The intention behind the current license is having GPL with static linking exception for embedded devices. So LGPL is no option.

If you see a way to get to a standardised license, I would be more than happy to accept that :-)

[martinwag]

@henrikbrixandersen What I think you can do is to fork the current repo and just remove the non-standard license stuff. This should leave you with a stock GPL2.

[CANopenNode]

Hello,

I first have to thank to Martin and his company for contributions to CANopenNode.

I took a quick only look into many changes. Currently I'm not working with new CANopen projects, but I will in the future and I will keep my promise from comments above. I can't read all the issues and comments for now, but if someone needs some answer from me, please let me know. I will try to follow this thread.

I just like to see, that the project is useful, that it lives on, and that I am not the only main contributor. I think, most important is the quality of the code and then the new functionalities (thanks for the LSS, it was really missing). Code should be as simple as possible, but not simpler.

[henrikbrixandersen]

@henrikbrixandersen What I think you can do is to fork the current repo and just remove the non-standard license stuff. This should leave you with a stock GPL2.

Yes, perhaps I could legally do that. But that would force me to release the firmware with CANopenNode linked as GPL as well. That's not an option for me.

[CANopenNode]

Zephyr RTOS seems very interesting for me.

I'm also not an expert for licenses. CANopenNode was LGPL licensed in past, but there was problems with using it on different microcontrolleres, tools, libraries, ... So linking exception to GPL was added.

I like free and open-source software (FOSS) mainly, because it is free to use (free of charge is usually only a consequence). From the same reason I like open standards, like CANopen, etc. As I know, CANopen was well adopted by many smaller companies. (Large companies like to develop their own standards.) I like to use widely adopted and free to use standards and (software) tools wherever possible. That's the reason, I developed CANopenNode and made it free to use.

If someone adds some CANopen functionality into it, it is nice, if he contribute back to the public. However, CANopenNode is only a base tool. On the other hand, application, which makes amazing device, is usually part of specific know-how of a specific company. This know-how with source code is property of the company. I think, it is fair, if companies use (standardized, public) FOSS base tools in combination with specific, proprietary know-how. (I tried to explain my FOSS philosophy, I hope I didn't wrote nonsense.)

---

As said martinwag, LGPL is not suitable here. I don't know for other solutions.
If GPL license is suitable for Zephyr, then I think, best solution is just to make a fork and delete the exception. The only question is only, how to make this task simple with each update of the base project.

If you like, I can open here another project, for example "github.com/CANopenNode/CANopenZephyr". It could be a fork of CANopenNode/CANopenNode with exception removed. You can be developer and other contributors can try to update both projects at the same time.

---

I have a question about Zephyr RTOS: Is it possible to use some custom (closed) code with Zephyr RTOS? Like with LGPL?

[CANopenNode]

Yes, perhaps I could legally do that. But that would force me to release the firmware with CANopenNode linked as GPL as well. That's not an option for me.

I missed that in my previous post. As I understand, LGPL is suitable for you, but GPL is not?

[martinwag]

Maybe ask the maintainers of Zephyr OS (I don't know that one myselve) what license would fit to our requirements? Using LGPL with some kind of linking exception should be quite common on microcontrollers.

[henrikbrixandersen]

I missed that in my previous post. As I understand, LGPL is suitable for you, but GPL is not?

No, you are probably right that LGPL is not an option either, since CANopenNode will not be used a dynamically linked library but statically linked in.

Zephyr RTOS itself is Apache-2.0 licensed. I will try asking around to see if anybody within the Zephyr community/Linux Foundation are able to come up with a suggestion for a way forward.

[CANopenNode]

I searched some license-related issues.

Found this one: #60
@martinwag I'm sorry, I didn't read that issue before. I used GLP only license in CANopenSocket for no strong reason. We could use GLP with linking exception (or something similar) for whole CANopenSocket, if it is necessary. You had extra work to write separate files. Sorry for that. Now there are two different parts for the same thing.

---

Onother issue is this: https://sourceforge.net/p/canopennode/discussion/387151/thread/b7910450/
After that issue LGPL license of CANopenNode changed to GPL with linking exception. In the thread is also mentioned LGPL with exception: https://opensource.org/licenses/wxwindows.phP

[kestewart]

Statically linking LGPL is going to have some distribution issues as you indicate. see: https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDynamic

One option would be to provide the files under a dual license so that the user has the choice of which license to use. This can be indicated in SPDX by using "OR". Is this something you'd be open to discussing?

[CANopenNode]

Yes, I think, dual license can be a good solution. For example LGPL OR GPL with exception.

[CANopenNode]

I'm also open for discussion about simply changing the license of the CANopenNode to single Apache-2.0.

This license is more permissive to commercial usage, as explained here:

• When someone modifies an Apache licensed software and redistributes it, it is not necessary to release the modified version of the source code.
• It is not necessary to submit the changes made to the source code to upstream.

https://en.wikipedia.org/wiki/Apache_License#Licensing_conditions

[henrikbrixandersen]

I'm also open for discussion about simply changing the license of the CANopenNode to single Apache-2.0.

That would be awesome in my opinion.

[martinwag]

If we want a more premissive license, why not just use MIT or BSD two clause? Those are short and understandable.

[CANopenNode]

I'm learning about licenses now :)

I think, switching to permissive license is a good option. I would change all three projects: CANopenNode, CANopenSocket and CANopenPIC. This will give more freedom for commercial use. I believe, there will be more quality contributions, not less.

@martinwag, what is your opinion? Would you vote for switching to permissive license? (Will then you or your company still contribute to public?)

---

In permissive licenses I prefer Apache-2.0 license. It is more complicated, but it is also more specific, which is good. It is newer, widely used and is safer in aspect to patents. Here is some comparison and short explanation of the Apache-2.0 license:

• Apache 2.0 allows users of the software to distribute, modify, or otherwise use software for any purpose, as long as the user complies with the license terms. The terms state that users can’t remove existing copyright, patent, trademarks and attribution notices
• Recent updates of the license, leading up to Apache 2.0, allow it to be included by reference, instead of listed in every software file, meaning developers don’t need to insert license text into the GUI.
• In addition, this latest version has two patent clauses. The first states the software can be used regardless of software patents which are in effect, without any further obligations. The second states that software users can’t initiate litigation over patent infringement (and if so, they lose their license)
• This license is considered by many to offer the best patent protection among the permissive licenses
• A limitation of this license for developers is that it requires you to add prominent notifications of any changes you make to a file.

[martinwag]

We're open to that. We prefer a more permissive license over GPL.

If you prefer the Apache, we can have that. We implement an open standard, so I think the patent stuff doesn't matter for us anyway.

Please be aware that I will only change license on files that our company is the owner.

[henrikbrixandersen]

@martinwag, @CANopenNode Exciting! I will soon have to have the licenses of the software (among others, CANopenNode) used in our upcoming product reviewed and approved by our company legal department. Any idea how soon a license change will/could be implemented?

It would also be nice if we were able to get CANopenNode integration into Zephyr RTOS v2.2, which is due some time in February 2020.

[CANopenNode]

I changed the license of my part of the stack with 9c2f0a1 commit.

We can continue the discussion about the license in #147

[CANopenNode]

I have some more time now for Further developenemt of CANopenNode.
Now I'm change the licenses to Apache 2.0, separating drivers and stack, and will start with new OD interface.

[Reissner]

I have a question: I heared that change of license requires consent of all contributors to be valid.
Not only the current ones.
For CANopenNode, this seems difficult to me.

[wilkinsw]

I have a question: I heared that change of license requires consent of all contributors to be valid.
Not only the current ones.
For CANopenNode, this seems difficult to me.

From what I understand, the license change is governed by the original license to some extent. The previous license, GPLv2, states that no further restrictions may be placed on the code:

CANopenNode/LICENSE.old

Lines 189 to 195 in a1f36cb

	6. Each time you redistribute the Program (or any work based on the
	Program), the recipient automatically receives a license from the
	original licensor to copy, distribute or modify the Program subject to
	these terms and conditions. You may not impose any further
	restrictions on the recipients' exercise of the rights granted herein.
	You are not responsible for enforcing compliance by third parties to
	this License.

The goal of the new license is to remove restrictions and make it easier for people to use. Thus I don't think anyone is going to make a stink about it.

Though, for the record, I give my explicit consent for my contributions to the CANopenNode project be re-licensed to Apache 2.0 :)