GPLv3 explained

GPLv3.md

GPL3 LICENSE SYNOPSIS

TL;DR* Here's what the license entails:

1. Anyone can copy, modify and distribute this software.
2. You have to include the license and copyright notice with each and every distribution.
3. You can use this software privately.
4. You can use this software for commercial purposes.
5. If you dare build your business solely from this code, you risk open-sourcing the whole code base.
6. If you modify it, you have to indicate changes made to the code.
7. Any modifications of this code base MUST be distributed with the same license, GPLv3.
8. This software is provided without warranty.
9. The software author or license can not be held liable for any damages inflicted by the software.

More information on about the LICENSE can be found here

Looking at the messages just now...

@pedro15 If your android app is for private (?!) use, you are not distributing. If you pu it in the Google Play store (for instance), you are distributing. One of tackling this situation is to force the user to install the plugin after the instalation. Then you are not distributing anything and what the user does is none of your concern.

@RogerInHawaii In your case, it is important to know what you are patenting. Is it the unique hardware part? Even if you open source your software, your patent would protect the hardware design. As for the software side, any unique addition that you offer with OSS GPV3.0 must be open source. Patenting that part is difficult and even if you do, enforcing or protecting it would be difficult.

Disclaimer: I am not a legal expert, get advice from an IP lawer.

@hoang-innomizetech

All code linked with GPL 3.0 source code must be disclosed under a GPL 3.0 compatible license.

There's is no such text on the linked page, where did you see it?

Hi,
You mentioned about open sourcing the source code. Well, does that mean I need to open source my entire application or only the modifications I made?
Thanks!

@shubhh123 , My reading of the GPL3 LICENSE is that you only need to open source YOUR VERSION of the open source code that you use in the application, including any modifications you made to IT. Your program may well include other code that you developed and even code that invokes part or all of the open source code you included (and potentially modified), but you do NOT have to make that other code open source. So, no, NOT the entire application, ONY the open source code that you included in the application (plus the modifications you made to IT).

Disclaimer: I am not a patent attorney.

Yet another question: (Trying to protect my own software from being open source).

Suppose I set up a secondary processor, like an Arduino, and have some of MY software running on it. I have the open source code running on the primary processor and modifications I made to that open source code SENDS INSTRUCTIONS, perhaps by way of serial communications, to the secondary processor to have that secondary processor run its own software (that I wrote).

Is the software that I'm running on the secondary processor considered to be "part" of the open source code and therefore must also be made open source? Or can I (potentially) patent or copyright or otherwise protect that software I wrote that's running on the secondary processor?

Thanks man, I was a bit overwhelmed by the unholy amount of stuff it said, and now I actually understand it.

Some clarification of things.

1. the GPL only kicks in for distribution of the work. As long as you keep the derivative work to yourself, the GPL doesn't matter.
2. the GPL requires that you state the work that yours is a derivative of. This definitely matters, for two reasons. One is you can't pretend it's the original work. The other is that it affects your ability to relicense the work. If you fork a GPL work on github, this is already done for you. Otherwise you MUST state it explicitly, either in the documentation or the source itself.
3. linking to a GPL library requires opening up the source of the linking work. dynamic linking to a LGPL library does not. That's why the LGPL exists, to allow that use case.
4. While the gpl makers would very much like the original work creator to be bound by the license, copyright simply cannot force that. If it is your original work that doesn't link to any GPL libraries, then you are 100% free to relicense future versions of your work under any other license. But this ONLY applies to the original author. If you modify a work, you cannot put the genie back in the bottle. All future versions of your modified work that are distributed must be under the GPL. If you link to a GPL (not LGPL) library, you are bound by the GPL.
5. This is where point 2 comes in. Whoever made the work is responsible for enforcement. If someone else violates the GPL on your work, you aren't required to respond, because copyright allows selective enforcement. The original author can never actually bound by their own copyright license. This is part of moral rights as a creator. This is also why you can relicense the work. This is how aali's open source driver got rewritten into a closed source driver for steam releases of Final Fantasy games without violating the GPL. But if it's a derivative work, or links to a GPL library, the original author can call for enforcement.
6. depending on your local law, the GPL may be considered a contract that anyone may sue for enforcement of. This is very much within the spirit of the license, but is not actually required.
7. as works are modified by different people the chain of enforcement growls longer. anyone in the chain can demand enforcement, even without any case law making it a contract.
8. v3 note number 1. You cannot create DRM with gplv3 code. If you try anyone with the source, which is anyone who asks for it is allowed to bypass it by modifying the work. In particular, if firmware with drm is GPLed, you can make a drm free version of it which also works on the original device.
9. v3 note number 2. to satisfy the source available requirement, it must be possible for the one who asks to compile said source and use it with anything that the original source is used with. Again, this affects firmware. If you can't create a firmware the device will accept with the source, it doesn't count. This is known as the anti-TiVOization clause.

Roger's question. Is he distributing binaries? If no, the GPL doesn't matter. If yes (he is distributing copies of the device to others), then he must distribute the source for what runs on processor a, and is not required to distribute the source of the software that runs on processor b, assuming they are different pieces of software. software b does not run any of the code inside software a, so software b does not link against software a. However, to not run afoul of the anti-tivoization clause, processor B must not perform any integrity checks on software A. Any modification of software A running on processor A has to still be able to work with processor B after it's been modified, or it doesn't fulfill the obligation to provide source. Sufficiently documenting what processor B expects is good enough to avoid needing to open the software for processor B.

Roger here.

I would be distributing a binary (executable) file of my modified (originally Open Source) Firmware that runs on the main machine I am building. So the source of that would be available as a fork of the GPL work.

I would be distributing a binary (executable) file of my own specific software which runs on an additional processor (likely an Arduino) that is NOT derived from any Open Source software.

The main machine will indeed be communicating with the additional (Arduino) machine and it will be very clear, in the source code for the Main machine that will be available from the fork on GitHub, what information is sent to the additional machine and what information comes back from that additional machine to the Main machine.

I THINK that means that I do not have to publish any additional information about the communication protocol between the two machines.

I THINK that also means that I am free to keep the source code that runs on the additional machine PRIVATE, company secret, possibly to copyright or even patent it (if patentable).

The issue is would someone be able to modify the open source firmware and actually put it on the device and have it work?

If yes, you are fine. If not you fall afoul of the anti-tivoization.

Zaphod77,

I really appreciate you taking the time to address my concerns. The software community really can be a wonderful help to others.

Regarding your latest comment . . .

They would definitely be able to modify MY version of the Open Source firmware and be able to install it on a device (in my case it would be any 3D printer that employs the Marlin Open Source firmware). But if they wanted their installation of my version to make use of the additional capabilities I have added to it, which is sending commands to the attached extra microprocessor and having that microprocessor control certain pieces of new hardware that I intend to have on MY version of a 3D printer, they would have to, on their own, attach a microprocessor and the additional hardware as well as WRITE the code for that attached microprocessor.

It's that additional code which runs only on that separate microprocessor and makes no use of any Open Source software that I hope I can keep from being Open Source. Others may well be able to figure out what that code does, how it does it, and write their own, but I don't see that there's any requirement that I simply give it away.

I'm also expecting there to be a very unique piece of hardware as part of my design and which also would be controlled by that software residing on the additional microprocessor. That hardware is unique enough that I would be pursuing a patent on it. That would not prohibit anyone from figuring out what that (potentially patented) hardware does and figuring out how to have something else do what it does and how to have the software (that they would write) control that hardware. But if they wanted to incorporate MY unique hardware they may well need to license it from me or purchase it from me.

But since that hardware does not really preclude anyone from building a 3D printer that does everything MY new 3D printer will do, I would think there would be nothing that violates the Open Source principles.

Yes? No?

You shouldn't be forced to open the coprocessor firmware.

As i said the test is if someone could modify the firmware, and then install the modified version in a device that has your coprocessor and custom firmware for it. if YES, you aren't violating the anti-tivo.

Since you aren't intending to distribute your coprocessor firmware anyway, that sidesteps the entire issue. Unless you intend to distribute the modified open source firmware to others, the GPL is a complete non issue. Your modification is PRIVATE. You would only have to give someone the source of the gpl portion if you sold them your 3d printer. which would also give them your closed source additional firmware. Printing stuff with the printer doesn't count as distributing the firmware unless it is AGPL, and it almost certainly is not.

Happy to explain things.

One question, does it matter if I use a library that is not licensed with the GPL?

You must obey any licensing conditions of any library you use. If the library has a license that conflicts with the GPL then you can’t add it to the gpl source unless you don’t distribute the binary.  I do not know what the library is.Sent from my iPhoneOn Nov 26, 2024, at 6:14 PM, BluePy ***@***.***> wrote:Re: ***@***.*** commented on this gist.One question, does it matter if I use a library that is not licensed with the GPL?—Reply to this email directly, view it on GitHub or unsubscribe.You are receiving this email because you commented on the thread.Triage notifications on the go with GitHub Mobile for iOS or Android.                                                           

zaphod77
I'm asking all these questions because I DO HOPE for my design to be the basis of a start-up company and to manufacture and sell the resultant 3D printers. It's really quite a unique design. It should print much faster and create much stronger prints (fingers crossed).
But it does seem like my code that runs on the separate processor can be kept as the company's trade secret, with no requirement that its source code has to be made available as Open Source.
So, that's a relief. :)

Thank you.

Note that you won't be able to stop people from reverse engineering the coprocessor based on what your open source part does to talk to it, but they would have to clean room the replacement, and if they didn't do that, major bucks for you.

…

On Tue, Nov 26, 2024 at 9:13 PM RogerInHawaii ***@***.***> wrote: ***@***.**** commented on this gist. ------------------------------ zaphod77 I'm asking all these questions because I DO HOPE for my design to be the basis of a start-up company and to manufacture and sell the resultant 3D printers. It's really quite a unique design. It should print much faster and create much stronger prints (fingers crossed). But it does seem like my code that runs on the separate processor can be kept as the company's trade secret, with no requirement that its source code has to be made available as Open Source. So, that's a relief. :) Thank you. — Reply to this email directly, view it on GitHub <https://gist.github.com/kn9ts/cbe95340d29fc1aaeaa5dd5c059d2e60#gistcomment-5302917> or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQL7ZOO7L33CEOUOO7I3JL2CVIH7BFKMF2HI4TJMJ2XIZLTSKBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDHNFZXJJDOMFWWLK3UNBZGKYLEL52HS4DFVRZXKYTKMVRXIX3UPFYGLK2HNFZXIQ3PNVWWK3TUUZ2G64DJMNZZDAVEOR4XAZNEM5UXG5FFOZQWY5LFVAZTKNZTGYYTONFHORZGSZ3HMVZKMY3SMVQXIZI> . You are receiving this email because you commented on the thread. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> .

The libraries in question are in my Cobalt repo under bot_code.py, it needs A LOT of work, it's concept is being a programming assistant that you can configure to only make answers to certain languages, this would be beneficial if for example, you ran the bot offline, so you don't download useless data you won't need.

@RogerInHawaii

https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation (my emphasis):

... pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.

So it seems you actually need to provide the source code for your firmware to the users under the GPL license.

@MasterKia , I don't know how one defines the phrase "intimate enough". In my case the only communication between the Firmware and the program running on the additional microprocessor is commands from the Firmware to the additional microprocessor telling it to perform some operation (e.g. turning a light on having it drive a stepper motor), and for the additional microprocessor to respond with a "DONE" or "FAILED" message back to the Firmware. No "complex data structures" are communicated.

I agree here. I don't believe that statement would apply.

Functionality is added to the open source firmware that sends instructions to the closed source microprocessor. Those instructions are not obfuscated, and no other communication is done. It's essentially one open source program giving a closed source ones simple command line switches, and reading the return code.

This seems like a legitimate aggregate, based on the description.

Now if there were secret undocumented actions caused by activating commands in a specific sequence, then things would be a bit more questionable. If there is data encoded into the sequence of commands that the coprocessor detects (and affects it's ability to succeed or fail), then that would be abuse, unless the required sequences themselves were documented in the open source side. If you have undocumented magic sequences, then you are concealing some of the source.

From the way it's described, there is no issue.