Threaded Mode | Linear Mode

3298 · 11-19-2021, 11:50 PM

(11-19-2021 09:04 PM)Claudio L. Wrote: I packed the bootloader code and requested upload to hpcalc.org.
I also committed a few changes:
* Removed all binary files from the repository
* Created a 'firmware' folder, empty in the repository, that will receive all the binary files
* Made the changes in the code so it looks for the bootloaders in that firmware folder
* Added a bash script (pull-roms.sh) that pulls and extracts the official ROM 2.15 from hpcalc.org, the bootloaders (when the file becomes available I may need to fix the name, we'll see), and the latest unofficial newRPL rom image. All binaries are placed into that 'firmware' folder.

So everything is ready to receive a license file making it explicitly GPL, I don't think there's any other issues that could prevent someone from making clean (as in not in violation of anything) binary packages for Linux. They just need to run the pull-roms.sh script as a post-install script.

Now we just wait for the file to go live on Eric's website...

I checked out the repository, well spotted on the character-skipping bug. Apparently I never properly tested parameters on long options, only on short ones. That means I have to fix another project which also uses this option parser ... how embarrassing.

The binaries removal has an issue though: the Makefile's install target wants to install the bootcode images, and accordingly the main program (specifically, the flash initialization code in flash.c) expects them to be installed too.
Also, I'm getting doubtful, can we risk packaging the bootcode as downloaded from hpcalc.org, or do we need to ask the user to point x49gp to it, like with the main firmware?
The ultimate solution would of course be the source for an independently developed bootcode, because that would let us install it without license headaches. That's a tall order, though. At least between the two of us, a semblance of "clean-room reverse engineering" would be possible (one person decompiles and writes a specification, the other implements the specification into new code). I am aware that once the firmware starts, the bootcode is irrelevant, but it does contain code to update the firmware if it's not valid ("Kinposhcopyright" signature missing) or the user requested it with + and - pressed during boot; and I don't know what kind of hardware initialization it might perform.

(11-18-2021 06:41 PM)Claudio L. Wrote: Mmmm... I understood it in a completely different way. The way I understood it is that a license being "compatible" means that source code under that license can be included in a GPL project. GPL being the main license covering the entire project, swallowing the other license. Anyone modifying the code that's under the other license as part of the GPL project would still have to release the changes in compliance with the GPL license, even if those files were originally BSD licensed for example that doesn't require that. In other words, the GPL attaches on top of the other license and imposes its restrictions.
The other way around doesn't work: any work derived from any GPL'd source becomes GPL'd. You can't derive work from a GPL'd project and place it under a different license, even if it's compatible, the new work becomes GPL.

Looks like I should visit the juristic section of the nearest university library then. Wikipedia at least indicates that license compatibility is a more difficult subject than I imagined. Thanks for the headaches, Mr Stallman...
One thing to note though: we may not be allowed to change the license of the QEMU part, but that doesn't prevent us from picking a license for the rest of the code that's compatible in that linking direction. That leaves more than one choice, as far as I can see, which is what contributors should have a chance to weigh in on.

By the way, does anyone know where to get the history from before the CVS to SVN import? Because I fear that part (including committer info) may be lost.