License information is missing

[tijuca]

Please ad some license information for this repository.

As this code is split off originally from the arduino source the license and copyright information are the same as for the arduino tree I assume.

[matthijskooijman]

I think most, if not all files should have copyright and license info inside. However, it would indeed be good to have a summary of licensing info, this makes it easier for redistrubution of this code. If such a license overview is added, I would recommend using the DEP5 / Debian copyright file format, which is machine readable and well-suited to express different licenses for different files: https://dep-team.pages.debian.net/deps/dep5/

[tijuca]

Hehe, I'm sitting here and try to collect all things together to get this packaged for Debian. 😄

As usual in dynamic projects not all files have a copyright header or information. So it's not fully clear which default copyright and license are to use.

I've found various used licenses.
BSD-3-clause
Expat/MIT
GPL-2+
ISC
LGPL-2.1+
and some non standard copyleft license in

bootloaders/caterina/Caterina.c
bootloaders/caterina/Caterina.h
bootloaders/caterina/Descriptors.c
bootloaders/caterina/Descriptors.h
bootloaders/caterina-Arduino_Robot/Caterina.c
bootloaders/caterina-Arduino_Robot/Caterina.h
bootloaders/caterina-Arduino_Robot/Descriptors.c
bootloaders/caterina-Arduino_Robot/Descriptors.h
bootloaders/caterina-LilyPadUSB/Caterina.c
bootloaders/caterina-LilyPadUSB/Caterina.h
bootloaders/caterina-LilyPadUSB/Descriptors.c
bootloaders/caterina-LilyPadUSB/Descriptors.h
firmwares/atmegaxxu2/arduino-usbdfu/Arduino-usbdfu.*
firmwares/atmegaxxu2/arduino-usbdfu/Descriptors.*
firmwares/atmegaxxu2/arduino-usbdfu/Board/LEDs.h
firmwares/atmegaxxu2/arduino-usbserial/Arduino-usbserial.*
firmwares/atmegaxxu2/arduino-usbserial/Descriptors.*
firmwares/atmegaxxu2/arduino-usbserial/Board/LEDs.h
firmwares/atmegaxxu2/arduino-usbserial/Lib/LightweightRingBuff.h

The license in/for firmwares/wifishield isn't conform with the DFSG unfortunately.

[matthijskooijman]

Hehe, I'm sitting here and try to collect all things together to get this packaged for Debian. smile

Cool. Getting (up-to-date) Arduino stuff back in Debian is something I'd really welcome. I haven't made time to dive into the licensing stuff myself, but if you will, I'll try to review any changes and help nudge the maintainers to merge them :-)

Are you looking at cores specifically? Or also arduino-cli and/or the IDE?

There has been some previous discussion on the licensing subject that might still be relevant, see arduino/Arduino#5827, arduino/Arduino#1117 and arduino/Arduino#2703.

The license in/for firmwares/wifishield isn't conform with the DFSG unfortunately.

Then it should probably be omitted from Debian. I don't think that would be a big problem for usability, even for users with a wifishield (AFAICS they just cannot upgrade the firmware then, and it would be easy enough to provide instructions for a manual download if they do want to).

What's the problematic license? I found "This software may only be redistributed and used in connection with an Atmel AVR product." in e.g. https://github.com/arduino/ArduinoCore-avr/blob/master/firmwares/wifishield/wifiHD/src/CONFIG/conf_at45dbx.h, is that it?

[tijuca]

Getting (up-to-date) Arduino stuff back in Debian is something I'd really welcome. I haven't made time to dive into the licensing stuff myself, but if you will, I'll try to review any changes and help nudge the maintainers to merge them

Thanks, for now there are no issues so far for ArduinoCore-avr as this package is quite straight forward. Good to know that you are open for constructive criticism. But it might help if you can add some default license definition for ArduinoCore-avr so that all files that doesn't have some licensing information can be identified (so far the license is clear of course).

Are you looking at cores specifically? Or also arduino-cli and/or the IDE?

For now I'm happy to get the Arduino UI updated and working for Debian Bullseye. So far I understand this also requires moving over from arduino-builder to arduino-cli. But I haven't looked at both projects that deep yet as -builder and -cli are requiring some Go knowledge. Debian is right before the soft freeze of Debian Bullseye, the next stable release. This means the window for introducing new source package (ArduinoCore-avr and arduino-cli would be such new source packages e.g.) is closing slowly. But having the new source packages in the archive is necessary to work and tune on the binary packages afterwards.

Conformity of the DFSG is the most important part to get packages accepted into Debian main, contrib and non-free isn't official Debian due the DFSG definitions. And the most critical part is here the software license. But also the availability of the source and the possibility to get every thing build from source. Means for the arduino binary package we need to filter out the .jar files and non Linux stuff and use the libraries that are packaged within Debian to get every thing built. I also needed to patch some Macbook specif stuff out (jtouchbar and the call of apple.jar related functions) which isn't relevant for Debian. But not a big problem now.

I can't say more right now for potential other parts of ArduinoCore, I haven't taken a look on these yet. But if someone want's to contribute and collaborate for packaging I'm happy to work together.

Regarding WiFi Shield, from a first look at this I decided that the license is definitely not DFSG compatible. And it's only a small part of the core package. It would be no problem to re-add this later if the license question is clear. Another option could be to create a non-free package for this.

Point 4 of the license term is a violation of the DFSG article 6 in my eyes that make the whole software non-free.

4. The software may only be used together with hardware from H&D Wireless all other use is prohibited.

The other part you mentioned is also falling into that category. These whole prohibitions are all ridiculous as the source is also provided. If they really want to protect something than only providing the binaries would be smarter and easier. Any way, that's the world it is.

[matthijskooijman]

But it might help if you can add some default license definition for ArduinoCore-avr so that all files that doesn't have some licensing information can be identified (so far the license is clear of course).

Right, that might need some spelunking in the Arduino/Arduino repository, where most of this code lived before. Do you already have a clear view of which files are missing licensing? If not, maybe you could find out (maybe you could provide a DEP5 file here, or in a PR, that lists the license that are clear, with a section for all files that have unclear or missing licensing)? Then maybe I can have a look around to see if I can figure out the origin of those files (I'm probably more familiar with the structure and history). How is that?

Regarding the arduino-builder vs arduino-cli situation:

• The Arduino Java IDE bundles a build of arduino-builder and calls that internally to do the actual builds.
• arduino-builder is built using the arduino-cli codebase as a library. The arduino-builder repository is largely empty now, it's just a shim that calls the actual code that lives in the arduino-cli repository (but this happens by linking to the code, not actually calling arduino-cli).
• The plan is to replace arduino-builder with arduino-cli entirely, so letting the Java IDE call arduino-cli to do the real work, but I'm not sure how close this is. Probably needs some more refactoring in arduino-cli first.
• So for now, you can probably package the Java IDE with arduino-builder included in the same package (though given arduino-builder has its own repo and releases, it is probably easier to put it into its own package and have the IDE package depend on that).
• In addition, packaging arduino-cli might make sense, since that is useful on its own (but also under heavy development, so might not be super-suitable for Debian/stable yet).
• When the Java IDE is converted to use arduino-cli, it can depend on the arduino-cli package.

I hope that clarifies.

As for packaging ArduinoCore-avr: One other approach could be to omit it from Debian and package just the IDE. Users should be able to install the core (into ~/.arduino15) using the boards manager, just like they would install e.g. the SAMD core or other third-party cores. I believe Arch does something similar, they do package the AVR core, but it's an optional dependency (according to arduino/Arduino#10580). I'm not exactly sure if the Java code really supports this right now, but again arduino/Arduino#10580 implies that it used to work and if it does not work right now, we should fix it so it does IMHO.

Note that I'm also maintaining some packages in Debian as a DM, so I have some experience with Debian packaging. If you want to discuss packaging issues or have some work reviewed, feel free to ask me as well (within limits of my available time, of course). Maybe this is not the best place for such discussions, but maybe a separate issue (here, on Arduino/Arduino or maybe on Salsa if you're planning to host the packaging there could work. I'm also on IRC as blathijs).

[tijuca]

Thanks Matthijs!

And yes, it getting offtopic as we are now on basic discussions about the packaging. I started a discussion thread on the relevant electronics team mailing list in Debian. If someone can provide useful ideas and help feel free to join!

https://alioth-lists.debian.net/pipermail/pkg-electronics-devel/2020-December/007562.html

[oxr463]

Possible duplicate of #50

[tijuca]

For the record, the license question for Core-Avr is currently clear enough right now for Debian main (but still not that nice it could be) and we needed to drop some things, the FTP Master in Debian accepted a packed version of Core-Avr some days ago and as this was one of the last packages dependency of the Arduino package itself Debian now has all needed packages within the unstable release so people can use the most recent Arduino IDE version by simply installing it with apt(-get) again. We plan to getting all required packages into the next stable release of Debian Bullseye, that will get released this year.