This gives me hope for using Arduino and LGPL.

I want to make a product, I don't even mind giving away the code. I'm just worried since its an embedded system, its hard to update or whatever. As many times as I read the legal stuff, its over my head. I can't understand how you can let someone update part of the code on something compiled. Its not like I'm going to have a screen on my device to let users read the code either.

If someone wants to fight a legal battle, its really due to my incompetence, not malice.

For [L]GPLv2 it's super simple - release any changed code and anything that links closely to it. If you publish all your source you basically can't fail to do this right.

For GPLv3, it's that simple most of the time. You talk about embedded which suggests you may be thinking primarily of the "tivoization" clauses designed to prevent user lockout. Again, if you're a fully open source project this will be hard to fail because the user should be able to just copy whatever you do in development. It's when you try to prevent user updates while allowing your own that this applies.

That was basically my thought, I'm just worried that if I link to the code online, that someone could claim 'Well I don't have internet'. Bam lawsuit.

I suspect that publishing it public to the internet is sufficient. If you really wanna cover your ass offer to mail someone the source on a CD for "reasonable handling fees"... which can reasonably be fairly high if someone demands such service.

This was changed in GPLv3. To my reading, section 6(b)(2) means that if you're distributing a physical product, you can just include a link to a URL where the source can be downloaded for free.

You could read 6(b) to mean that you have to offer consumers the choice between physical-delivery-at-cost and for-free-download of the source... but I don't think that's the right reading.

Maybe offer the source code at the point of purchase? Could even sell USB/SD with source code on it. Folks who want the code offline can buy them and copy the code where they want it.

OTOH, the internet is a "medium customarily used for software interchange" so maybe that would be fine, but the internet wouldn't "accompany" the device. Also, in GPLv2 you are allowed to just send a note "you can get source from us delivered on a storage device for $X", so if you do the purchase thing, plus write a note with every device about how to get the code on the internet or on disk, you should be fine.

I think it is their stated aim at sfc to enforce compliance, not to sue. If they see you are not complying they will ask you to comply. Doesn't sound like something to be scared of?

Indeed, and their principles while enforcing compliance are eminently reasonable:

https://sfconservancy.org/copyleft-compliance/principles.htm...

>I can't understand how you can let someone update part of the code on something compiled.

You can provide your closed source part as a precompiled library or object file together with the source code for the LGPL part and build scripts that let the recipient relink it with a (possibly modified version of) the LGPL code to generate a new final binary.

A pain yes but not impossible. Having a screen or not is irrelevant, nothing says the recipient has to access the source on the same device as the binaries run.

IANAL, but I don't think that the part in the GPL about modification makes any requirement that you facilitate modifying compiled binaries. My understanding is that the requirement is essentially that distributing the binary requires you to distribute the source as well; if someone modifies that source code you provide and distributes a binary they compile from that modified code, they need to share the modifications as source as well.

This is also my understanding of why the AGPL was created to try to close the loophole of running GPL code on the backend; since running code on a server doesn't entail distributing the server binary to people who access the service, the GPL didn't enforce any requirements on sharing any modifications to code that was modified and used as part of the backend for the service. Some felt that this went against the spirit of the GPL, so a new license that made this also explicitly disallowed was created.

As for the LGPL, my recollection is that it differs from the GPL in creating an exception for dynamically linking to the compiled binary; the phrasing of the (non-L) GPL requires that any "derivative works" of the GPL-licensed product (I can't remember if that's the exact term, but it's a something similarly general) must abide by the GPL, which could be interpreted as applying to something that dynamically links to a library licensed under the GPL. Licensing something under the LGPL gives permission for users to dynamically link to your product without requiring them to share the code linking to it.

The point of the LGPL is that it allows static or dynamic linking with proprietary software, but it requires that users be able to modify the LGPL part and relink it with the proprietary part and have the result work, as long as the modified part is compatible with the proprietary part. With dynamic linking thats simple, just drop in a new LGPL library, but with static linking you have to share the .o files for the proprietary software to enable user relinking.

I'll chime with my experience in embedded systems. In the last 2-3 companies I've worked with the directive has been "no GPLv3/LGPLv3, period. You will be fired if you ship with it." The legal departments just don't want to deal with it at all.