3

I'm rewriting/reimplementing an open source program/library and need to know about my options for licensing. I'm asking about software rewrites/reimplementations generally and specifically about my current use-case.

The software (also as shared object library possible) I'm reimplementing is AVRDude licensed under GNU General Public License v2 or later.

As I don't currently need all provided options I'm writing a prototype with minimal functionality that is required for Arduinos. AVRDude is written in C/C++ with YACC config parsing and I'm programming in Python mit PLY parsing. Since C and Python are sometimes rather different syntactically, I need to more or less re-implement everything. I can orientate myself by the logical flow of AVRDude and need to re-use defined constants but everything else is rewritten and optimized for Python. There is no usage of the native AVRDude afterwards.

Examples of code (information) that has to be kept as is (only converted from C to Python):

  • logical sequence of commands issued to the chips by a programmer, e. g. STK500
  • constants defined with command codes, error codes/returns

Examples of code that is currently being kept relatively unchanged (adopted to Python naturally):

  • structures to hold the data for fuses, memory etc.
  • bitflag lists but somewhat optimized for Python
  • programmer functions with weird pass-by-reference parameters (will be changed later if it works)
  • commandline interface (will be later changed more like the one in esptool.py)

Examples of code that is re-implemented by myself:

  • config file parsing (currently in own grammer in PLY), naturally not that restrictive compared to the native implemenation by AVRDude (output similar to: avrdude-config-webapp)
  • USB device access (for use in Termux on Android, only possible with USB file descriptors)

My questions are:

  1. What is generally under the licence?
    Definitions like error codes etc., functions names, general logic flow? [not?]
    A communication to hardware is specified somewhere (documenatition, manuals) and it is only possible in this way.
    There are sometimes other implementations out there that can/could be the base for my own code, e. g. on Github with less restrictive licensing.
  2. Is a rewrite a modification of software or a newly created 'thing'?
    Does the licence apply in that my rewrite/reimplementation also has to be under GPL or do I only have to include the notice/credits that I base my code on?
    Should I reformulate "rewrite" as "(re-)implementation based on ..."?
  3. What are my options for my AVRDude reimplementation? GPL v2 and more restrictive or also less restrictive like MIT?
    I would like to publish under a less restrictive license if other may want to use my code later on, so that closed source software does not have to be open sourced if I understand the GPL correctly.

Attribution to AVRDude is no problem but I do not know if I can change to MIT licence for my library etc.


Maybe similart to this one:


Update #1, 08.01.2020, Reply to @Brandin

I had to look and read through each line and trace most program paths of the original AVRDude source for my re-implementation. A more or less literal translation is the communication in the STK500 programmer as I'm unsure of how to do this any other way and keep it still working. That points into the derivative work direction. The original code may be 'functional' as it is sometimes 'just' an implementation of a protocol, but there must have been much 'creativity' to write it that way in the first place. And there are still many people contributing patches etc. and improving the code even if it is rather old.

Since AVRDude is a tool for a rather specific use-case, reading from & writing data to microcontroller, there is not much leeway compared to a large general purpose library from which I would only extract/rewrite a small functional part.

  • Whether your "reimplementation" can be considered a new work is going to depend on the details of how you do it. If you look at each line of code, function, etc. of the old program and then try to translate that, then yes that is a derivative work (as you saw in your linked questions). If your new program is merely inspired by the old one, or if what you are 'copying' is non-creative or a functional element (for example, the old program has a "--record" command line option, so you also include your own "--record" option with compatible syntax), then that is probably not a derivative work. – Brandin Jan 8 at 11:19
2

What you describe reads pretty much as a translation to another language with "only" the work necessary to adopt it to that without changing the principle logic or structure of the programme. Generally, that makes your work a derivative work of the original work and you are bound to its license. For a GPL-licensed source that means you will need to comply to that and use a compatible GPL-license for your translation as well. The FAQ on the GPL is quite clear on that a rewrite as described constitutes a modification. Especially important in this aspect is the structuring in functions and programme flow as well the use of data structures.

Unaffected by this argument are strictly only these things which are required to create a compatible piece of software which is the commands sent to the chips (thus the API for it). This does not include the naming of the constants, though. Additionally the API you offer to your user can be an exception, that is the command line parameters accepted can be the same by your implementation.

To make an independent piece of work you would have to re-implement the software completely anew without ever looking at the thing you try to translate (a so-called clean-room implementation) - the APIs (and only these) to the chip and user excluded from this argument for compatiblity reasons.

  • Thank you. A clean-room implementation at this point is impossible and unpracticable as I would have to test even more to have it working correctly. There are parts written by me that are completely new (e. g. config parsing, device acces via USB), some are heavier modified, but I had to look at the original source to understand what choices were made for the given results. One reason for the 'rewrite' is also that I needed it in Python with additional functionality. Trying to get it working with the original language "C" and using it would have been even more time-consuming. – E. Körner Jan 8 at 15:02
  • According to this gnu.org/licenses/gpl-faq.html#AllCompatibility - would that mean I can also use the LGPLv2* licences? – E. Körner Jan 8 at 15:29
  • I find that table colouring a bit mis-leading and I think the answer is 'no'. The corresponding matrix says in those cases "combination (of GPL and LGPL) is ok under GPL". – planetmaker Jan 8 at 15:46
  • Thank you, I thought so too but hoped otherwise. I will search a bit or even post a question. The wording was not really that clear and more about other software that is depending on a GPL licensed software if I understood it correctly. -- I will wait til the end of the week to accept your answer. Maybe some other replies will come but if not, yours was really helpful. – E. Körner Jan 8 at 17:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.