legacy-support: license precludes distributable binaries; declare license_noconflict, via pg 'legacysupport'?

[mascguy (Christopher Nielsen)]

It appears that the use of legacy-support precludes binary distribution for various ports, when it comes into play.

Examples:

"mysql57" is not distributable because its license "gpl" conflicts with license "APSL-2" of dependency "legacy-support"

"gnupg2" is not distributable because its license "gpl" conflicts with license "APSL-2" of dependency "legacy-support"

[...etc]]]

Given that legacy-support is a MacPorts component, would it be reasonable to declare license_noconflict for it? (We'd want to do that via PG legacysupport though, to ensure this happens automatically.)

[mascguy (Christopher Nielsen)]

This started on 2023-07-05, when legacy-support was updated to add additional license APSL-2:

​https://github.com/macports/macports-ports/commit/6cc1b506cb3be841bd7a3300375b810a02694a7b

[jmroot (Joshua Root)]

The APSL code was there from almost the beginning. The GPL doesn't have an exception for MacPorts components, only OS components.

[mascguy (Christopher Nielsen)]

Replying to jmroot:

The APSL code was there from almost the beginning. The GPL doesn't have an exception for MacPorts components, only OS components.

Ugh, we already have a significant number of ports that need legacy-support. And as the need for it grows, more and more ports will need to build from source.

To be fair, it mostly only comes into play for macOS 10.12 and prior. But I suspect that over time, we'll need to add things for 10.13+. Further expanding the impact zone...

[jmroot (Joshua Root)]

It's at least theoretically possible to replace the APSL code with versions under a GPL-compatible license, I guess.

[kencu (Ken)]

Jeremy's atcall.c replacements will likely never be clean-roomed by someone to come up with their own unpolluted and defendable implementation, so replacing that license in that code seems impossible.

Different parts of legacysupport are used by different software ... if you're just using the getline implementation you're not using APSL-2.

A better question might be to look at the whole idea of it... is it really impossible to distribute some piece of software because it links against something else that has a different license? I believe Legacysupport code is not incorporated into any of these software builds....could be examined by a disassembler to be 1000% sure of that if someone really needs to be certain.

Seems silly to me, but IANAL.

In the end, this licensing thing will end up taking us back to the old days, where individual (and questionably-licensed) patches were added in to ports ad-hoc.

[cjones051073 (Chris Jones)]

Ken, just because you link dynamically to a lib doesn’t excuse you from respecting the license for that library. This is the exact reason the GPL has the exclusion for system libs, as *every* links against that so without that exclusion nothing GPL would be distributable.

For me there are only 3 ways out.

1. Do nothing, and accept the non-distributable outcome in some case.
2. Replace the APSL code with something else.
3. Break up the single legacy support lib into multiple libs, depending on license, and allow ports via the PG to pick and choose more what they need.

2. And 3. Require quite some significant work.

[mascguy (Christopher Nielsen)]

My original freak-out related to this topic, didn't factor in the various licenses that come into play. But I think - and I'll let Josh clarify - that this will mostly be a pain for GPL-based components.

That's supported by the fact that the corrected license has been in place for nearly six weeks... yet very few ports appear to be negatively affected.

Despite continually updating my entire suite of VMs (10.5 thru Monterey), almost daily... the only two ports that I noticed building from source, are mysql57 and gnupg2. Virtually everything else has updated from the MacPorts-provided binaries. And I have a considerable swath of things installed on each VM, on the order of 1,000-ish ports/each.

Others' mileage may vary. But my gut tells me that this may not be a big deal overall. Enough so that I almost regret creating this ticket, as I didn't want to panic others unnecessarily...

[cjones051073 (Chris Jones)]

My inclination is indeed to just go with 1. Above.

[mascguy (Christopher Nielsen)]

Replying to cjones051073:

My inclination is indeed to just go with 1. Above.

Yes I agree, the impact isn't anywhere near as bad I originally thought. So probably not a big deal.

Anyone else... thoughts?

[jmroot (Joshua Root)]

Replying to mascguy:

My original freak-out related to this topic, didn't factor in the various licenses that come into play. But I think - and I'll let Josh clarify - that this will mostly be a pain for GPL-based components.

Yes, as is often the case due to the GPL being the only widely used license that has a "no additional restrictions" requirement, it's only the GPL (and derivatives like AGPL and CeCILL) that conflicts with the APSL.

[kencu (Ken)]

Replying to cjones051073:

Ken, just because you link dynamically to a lib doesn’t excuse you from respecting the license for that library.

The code you wrote has a license. The library you link to has a license. They don't have to be the same license; they don't share code. For me this is not confusing.

Having a binary call code from another binary library is no different than having a shell script call another executable to do something.

And nobody gives a rat's ass about the license in that case there, do they :>

[kencu (Ken)]

Or maybe somebody does care about that... it's a weird weird world, when the lawyers smell blood.

[jmroot (Joshua Root)]

Who knows, maybe you're right, but the FSF wrote the GPL and they disagree. ​https://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic

[kencu (Ken)]

This suggests that so long as the library you link to is available with your GPL software (and legacysupport is available) then you're fine to link a GPL program against and non-GPL library.

​https://opensource.stackexchange.com/questions/2219/can-i-use-a-proprietary-library-in-my-gpld-program

We're splitting hairs here, perhaps?

[kencu (Ken)]

OK, I see what you referenced, Josh.

I'll read it over... it is too bad if it can't be simply used though...

[jmroot (Joshua Root)]

BTW, if your thesis is correct in the broadest sense, it would mean there is effectively no such thing as a license conflict. This situation is exactly like the one with OpenSSL and the GPL; it's assumed that the combined work is subject to both licences, and it's impossible to simultaneously comply with both the GPL and the old OpenSSL license.

[jmroot (Joshua Root)]

Wearing my portmgr hat: It comes down to this. While reasonable minds may differ on these points, the only way to be certain is to be sued (and even that certainty only applies to a single jurisdiction). So, we err on the side of caution.

[mascguy (Christopher Nielsen)]

Replying to jmroot:

Wearing my portmgr hat: It comes down to this. While reasonable minds may differ on these points, the only way to be certain is to be sued (and even that certainty only applies to a single jurisdiction). So, we err on the side of caution.

Makes sense for sure!

And given that we had plenty of great discussion on all of this, I'll go ahead and close.