License choice about pi-oled HOT 12 CLOSED

@lukehutch your project looks quite nice. I'm happy my code could be of good use.

from pi-oled.

The library is not licensed under GPL but under LGPL. LGPL permits you to use the library in any software, even commercial ones. Only thing it adds in comparison to the originating BSD is that you need to also license your changes to the library under LGPL - but not the software that uses the library.

So the only thing that you can't do with the current license is make modifications of this code that are NOT under LGPL. But as I said using this library in any commercial software is no problem (check https://tldrlegal.com/license/gnu-lesser-general-public-license-v2.1-(lgpl-2.1)). Changing the license to MIT would only allow for companies to make modifications to this library that they don't have to share with the community. So in my opinion LGPL is the best of both worlds - it keeps the source and additional improvements open source while at the same time allowing everyone to use it in their commercial projects.

Any particular reason why you want this code to be licensed under MIT? By the way, I think it is not really possible as MIT is not compatible with BSD as it is a bit less restrictive (see https://janelia-flyem.github.io/licenses.html).

from pi-oled.

Sorry, my bad, LGPL.

The library is not licensed under GPL but under LGPL. LGPL permits you to use the library in any software, even commercial ones.

That is only true of dynamic linking, not static linking. The issue of linking is murky for Java, hence the birth of the classpath exception.

The (L)GPL also does not protect you from copyright claims (e.g. Oracle is aggressively pursuing many users of the JDK now on copyright grounds).

Mostly though, I was a big proponent of GPL and LGPL for many years, but have now come to conclude that the encumbrance of the viral nature of these licenses does more harm than good, since a huge amount of GPL'd (and even LGPL'd) code is simply not used in production because of the (L)GPL's license's viral nature.

Only thing it adds in comparison to the originating BSD is that you need to also license your changes to the library under LGPL - but not the software that uses the library.

The boundary between what is the original library and what is separate new code becomes blurrier and blurrier over time as the modified code diverges from the original code, especially after extensive refactoring, so the LGPL/proprietary boundary is simply not a useful distinction after significant modification. (This is where I find myself now -- I either need to remove or replace the last bits of your code, or I need to license my code under LGPL, since it is now interwoven with your code.)

Yes, LGPL is better than GPL, but particularly for "example code", or fundamentally useful libraries, I think the most permissive license is the best license. I now distribute any libraries I create under the MIT license. I figure, if I'm going to put software out into the world to help the world, I shouldn't be emotionally affected if it is used by a company to profit from my work without paying me (since, whether I use a more restrictive license or not, I'm still not going to get paid, but I can at least do more good by publishing the code under the most permissive license possible, since then everybody can use it).

If you don't agree with this, no problem, it's your project, feel free to close this issue :-)

The separate issue though is that you ported the code from a BSD-licensed project, but didn't preserve the copyright notice (you only linked to the work). This violates the BSD license. (The 3-clause BSD license doesn't say you can't relicense the code per se, but it does say you can't remove the copyright notice.) Although I guess porting code to an entirely different language without a clean-room reimplementation from specs falls into a gray area (so maybe this gets around needing to preserve the license).

from pi-oled.

That is only true of dynamic linking, not static linking. The issue of linking is murky for Java, hence the birth of the classpath exception.

I agree that linking in Java works a bit differently than in conventional compiled languages, but the LGPL still applies as intended (see https://www.gnu.org/licenses/lgpl-java.en.html).

Nevertheless it's also okay to change the license - after all it's just one very small class (if you don't count the font) and I really rather have people using my code then not just because of the license.

But as you mentioned the original code was licensed under BSD license, so I can can only offer to put this library under BSD as well, as the MIT license is somewhat incompatible with BSD (don't ask me for specifics, I'm not a lawyer - but you can see it in this very handy diagramm)

So would the BSD license work for you?

from pi-oled.

Yes, I see that BSD is more restrictive than the MIT license, and that is no problem. I would still rather work with the OLED driver class under the original BSD license than under LGPL, and I appreciate your offer on that. I will release all my other code under the MIT license. In return you are welcome to incorporate and relicense any of the code in my fork that you are interested in back under the LGPL (I am happy for an LGPL version of my changes to exist, I just don't want to maintain it myself).

I stripped down the OLED driver class so that it only drives the OLED, and doesn't do any rendering -- I have a separate class for the rendering.

The only other part I need is the font definition data. Did you design the fonts, or did you pull them in from another project? The fonts look like pretty standard small bitmap fonts, but I was curious if they were originally public domain or under another license.

I have merged in more extensive 16x16 font support from another project, for Latin1 and Korean. I ideally need Chinese support too, so I plan to merge in a few more bitmap fonts to create a more extensive font rendering library before I push out a release.

from pi-oled.

For reference, this is the stripped down OLEDDriver.java class, and this is what I would love to see BSD-licensed:

https://pastebin.com/5p2vaCC6

It has a couple of modifications, mostly surrounding clearing the screen.

(See also the question on font definition licensing in the previous comment..)

Technical question: Is there any reason you're writing the display data in chunks, rather than sending it as a single transmission?:

        for (int i = 0; i < ((DISPLAY_WIDTH * DISPLAY_HEIGHT / 8) / 16); i++) {
            // send a bunch of data in one transmission
            device.write((byte) 0x40, imageBuffer, i * 16, 16);
        }

from pi-oled.

In return you are welcome to incorporate and relicense any of the code in my fork that you are interested in back under the LGPL (I am happy for an LGPL version of my changes to exist, I just don't want to maintain it myself).

If I re-license the driver then I'd like the have the same license for all of it. So if you want to contribute to the driver (which I'd welcome) that code should also be under BSD license.

The only other part I need is the font definition data. Did you design the fonts, or did you pull them in from another project?

If the font is not part of the original driver then I created it myself. Most likely I ported the font I used for Plant-Lab (http://ludumdare.com/compo/2015/12/17/plant-lab-post-mortem/) - which is, as you said, a very simple font.

Technical question: Is there any reason you're writing the display data in chunks, rather than sending it as a single transmission?:

    for (int i = 0; i < ((DISPLAY_WIDTH * DISPLAY_HEIGHT / 8) / 16); i++) {
        // send a bunch of data in one transmission
        device.write((byte) 0x40, imageBuffer, i * 16, 16);
    }

Honestly I didn't look into the code for months if not for years, so I can't really tell you why I did this. Most likely I just ported it the way it was in the original driver, because I just wanted a working driver and I simply trusted the original authors that they knew what they were doing when they wrote it.

from pi-oled.

In return you are welcome to incorporate and relicense any of the code in my fork that you are interested in back under the LGPL (I am happy for an LGPL version of my changes to exist, I just don't want to maintain it myself).

If I re-license the driver then I'd like the have the same license for all of it. So if you want to contribute to the driver (which I'd welcome) that code should also be under BSD license.

The code I have written is not driver code in the strict sense, it is a font rendering and UI library, designed to be used with the Adafruit bonnet, which has the same display, but also a D-pad and two additional buttons. That is why I stripped out the rendering code from the OLED driver class, leaving only actual hardware driver code, as linked in my previous comment. The hardware driver is the only part I strictly need from your project, since getting the details right of how to program the display hardware would be very difficult without it.

I already wrote my own font renderer for a new 16x16 font, and will be adding more fonts. I am currently using your two fonts too, but there are many others out there that I could incorporate.

You said that the LGPL works with Java, but reading that article, as far as I can tell RMS is saying that this is only the case if you are depending on an external jar, it doesn't work to mix LGPL and non-LGPL code within the same source tree that a single jar is built from? If you can have LGPL and non-LGPL code in the same source tree, I could keep your fonts as LGPL, based on your assertion that that works with classpath linking against non-LGPL code. If it only works having them in a separate jar, I can replace them with other bitmap fonts.

So I guess what I'm saying is that I respect your decision to keep your library LGPL, if you can simply grant permission to re-license the OLED driver code class I linked in my last comment. Everything else I can build myself from scratch, and I will continue to create my own UI library on top of that OLED driver code.

from pi-oled.

You said that the LGPL works with Java, but reading that article, as far as I can tell RMS is saying that this is only the case if you are depending on an external jar, it doesn't work to mix LGPL and non-LGPL code within the same source tree that a single jar is built from?

Exactly. But I think we have a small misunderstanding here: my suggestion is that I put the whole code as it currently is in the repo's master branch under BSD license (for everyone). Then you can push your changes (which would then also fall under BSD) or take a branch of the current code and modify/license it under any compatible license that you want.

Actually I just did exactly that and changed the license (also pushed a new built with the new license to Maven Central). Hope this works for you :)

from pi-oled.

Actually I just did exactly that and changed the license (also pushed a new built with the new license to Maven Central). Hope this works for you :)

Yes, I did misunderstand, I wasn't sure you actually wanted the code you had written under BSD, given what you initially said about the LGPL. But I appreciate this change!

Many thanks!

from pi-oled.

@entrusc I used the modified version of your BSD-licenced code in this project:

https://github.com/lukehutch/Adafruit-OLED-Bonnet-Toolkit

from pi-oled.

PS many thanks, I could not have gotten the OLED working without your code!

from pi-oled.