Possible to re-license?

[Arcnor]

Hi there,

I was wondering if you'd be open to relicense Nuked-OPL3 (and maybe the other Yamaha emulators) under a less restrictive license (maybe MIT or BSD, although BSD itself is incompatible with MIT so maybe the former is better)?

The main problem with the LGPL is that it cannot be used in certain platforms like iOS, because of the relink clause.

I understand if you're not open to it, but thanks for considering it.

[kcgen]

The main problem with the LGPL is that it cannot be used in certain platforms like iOS, because of the relink clause.

The main problem with the iOS platform is that it cannot be used with certain licenses like LGPL, because of (IOS's) static-linking security model.

Fixed that for you.

The authors of LGPL software are willing to share their source provided you also share the source code of any libraries to which the LGPL library is statically linked.

So the problem is one of reciprocal sharing.

Sharing requires two people:

• One sharing
• One accepting

In this case, the one accepting doesn't want to share in return because they're beholden to a company that also doesn't share in return.

Is it fair to call the one willing to share, "the problem"?

[Jookia]

Technically you can static link with the LGPL as long as you provide the object files that lets users re-link.

[kcgen]

Interesting @Jookia.

So if an iOS developer statically links a single static binary iOS executable (inside of which Nuked-OPL3 is statically linked), they can make their app LGPL compliant by provide the couple .o object files that call Nuked-OPL3?

On the user (or buyer) side - you now have the iOS binary plus a couple .o files. How do you actually re-link a working binary from what you've been given? (I'm probably missing something)

If this approach is LGPL compliant, then someone could write ultra-thin C++ or C API wrappers around all LGPL libraries for anyone (or any company) to use, provided they gave users the tiny .o wrapper object files?

[Jookia]

See section LGPLv2.1 paragraph 6 clause a, and LGPLv3 paragraph 4 clause d.

…

On Sat, Mar 06, 2021 at 12:09:41PM -0800, kcgen wrote: Interesting @Jookia. So if an iOS developer statically links a single static binary iOS executable (inside of which Nuked-OPL3 is statically linked), they can make their app LGPL compliant by provide the couple `.o` object files that call Nuked-OPL3? On the user (or buyer) side - you now have the iOS binary plus a couple `.o` files. How do you actually re-link a working binary from what you've been given? (I'm probably missing something) If this approach is LGPL compliant, then someone could write ultra-thin C++ or C API wrappers around all LGPL libraries for anyone (or any companies) to use, provided they gave users the tiny `.o` wrapper object files? -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #2 (comment)

[kcgen]

Thanks for the references @Jookia.

---

6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications.

   a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.)

---

That makes sense, and my example would not pass these requirements.

In that case, I guess @Arcnor can use Nuked assuming they provide users with their complete machine-readable work as object code and/or source code, so that users can modify the library and relink to produce a modified executable containing the modified library.

[fawtytoo]

As a point of interest, the original code was licensed under the GPL v2.

As a criticism, was it right to change it to the LGPL?

[username00112233]

Did we really turn a "Could we re license this for more freedom?" into "Apple bad."
And instead of opposing the license change, then talking about possible ways to circumvent the license,
how about just agreeing that a license change is very beneficial instead of pretending its not?

Is it fair to call the one willing to share, "the problem"?

Noone did that.

[mywave82]

If this approach is LGPL compliant, then someone could write ultra-thin C++ or C API wrappers around all LGPL libraries for anyone (or any company) to use, provided they gave users the tiny .o wrapper object files?

I believe the intention was the other way around: You need .o files of the closed-source part, so you can relink the final-binary.

iOS do to my knowledge support dylibs, but the app can not download them from the Internet, they have to be shipped with the app through the Appstore for review reasons.

[username00112233]

If this approach is LGPL compliant, then someone could write ultra-thin C++ or C API wrappers around all LGPL libraries for anyone (or any company) to use, provided they gave users the tiny .o wrapper object files?

I believe the intention was the other way around: You need .o files of the closed-source part, so you can relink the final-binary.

iOS do to my knowledge support dylibs, but the app can not download them from the Internet, they have to be shipped with the app through the Appstore for review reasons.

We are getting a little off-topic here