liquid-dsp: fix license

[ra1nb0w]

Description

• liquid-dsp has MIT as license
• bump revision of CubicSDR to build the package after liquid-dsp license change (verified with port_binary_distributable.tcl)

Type(s)

• bugfix
• enhancement
• security fix

Tested on

macOS 10.14.4 18E226
Xcode 10.2.1 10E1001

Verification

Have you

• followed our Commit Message Guidelines?
• squashed and minimized your commits?
• checked that there aren't other open pull requests for the same change?
• referenced existing tickets on Trac with full URL?

• checked your Portfile with port lint?
• tried existing tests with sudo port test?
• tried a full install with sudo port -vst install?
• tested basic functionality of all binary files?

[macportsbot]

Notifying maintainers:
@michaelld for port CubicSDR, liquid-dsp.

[michaelld]

liquid-dsp does indeed use the MIT license. Like, forever. Not sure how I missed that, but thanks for that fix!

CubicSDR is correct at GPLv2; whew!

So is CubicSDR not distributable when liquid-dsp uses the GPLv3 as its license? I thought since GPLv3 is (for all practical purposes) a superset of GPLv2, it would allow binary distribution in various forms that must include the license and maybe some other files.

The MIT license is pretty much totally open, which would definitely allow for binary to be distributable regardless of the project license ... yes?

Thanks for the PR & for clarifying!

[ra1nb0w]

So is CubicSDR not distributable when liquid-dsp uses the GPLv3 as its license? I thought since GPLv3 is (for all practical purposes) a superset of GPLv2, it would allow binary distribution in various forms that must include the license and maybe some other files.

this is from port_binary_distributable.tcl

"cubicsdr" is not distributable because its license "GPL-2" conflicts with license "GPL-3" of dependency "liquid-dsp"

and I don't have the knowledge to evaluate if it is correct.
License, in my opinion, it is quite hard and not always deterministic ;-)

The MIT license is pretty much totally open, which would definitely allow for binary to be distributable regardless of the project license ... yes?

MIT, for what I know, it is similar to 2-BSD (has something more on selling and on code management like sub-licensing) so it permits to distribuite the binary without restrictions and this is also valid for packages that use it.
ps. sorry if I didn't catch the question but I am hungry ;-)

[macportsbot]

Travis Build #6006 Failed.

Lint results

--->  Verifying Portfile for CubicSDR
--->  0 errors and 0 warnings found.
--->  Verifying Portfile for liquid-dsp
--->  0 errors and 0 warnings found.

Port CubicSDR success on xcode10.2. Log
Port liquid-dsp success on xcode10.2. Log
Port CubicSDR success on xcode9.4. Log
Port liquid-dsp success on xcode9.4. Log
Port CubicSDR fail on xcode8.3. Log
Port liquid-dsp success on xcode8.3. Log
Port CubicSDR fail on xcode7.3. Log
Port liquid-dsp success on xcode7.3. Log

[ra1nb0w]

the failure on xcode8.3/7.3 should be caused by cjcliffe/CubicSDR#723 and it is quite important because touch macOS 10.12 and 10.11.
They are used by many users; this morning one user wrote privately to me showing that failure. Do you know something about wxwidgets? thanks

[michaelld]

Interesting about the license. I'm good with both changes since 'port' is LOL.

[michaelld]

LGTM

[ra1nb0w]

Ops. I preferred to avoid merge and fix the build problem but it is ok, we will add a new revision.
Have you machine with macOS 10.{11,12}? some people in the past suggested to

define a macro 
_WCHAR_H_CPLUSPLUS_98_CONFORMANCE_ 

I see also this on trac but the solution is quite different.

[ra1nb0w]

errors sent upstream

[michaelld]

Merged. As for the build issue: On my OSX 10.10 boot, CubicSDR fails as expected, so I can replicate the issue. I'm trying what you note as a possible CXXFLAGS addition, which would be a nice simple fix. More soon.

[michaelld]

Yes that tweak works:

configure.cxxflags-append \
    -D_WCHAR_H_CPLUSPLUS_98_CONFORMANCE_

CubicSDR builds on both 10.10 and 10.14 for me. It worked before on 10.14, but failed on 10.10 ... so I think this change does no harm at least for newer OSX. I haven't tried it on anything older yet; still updating ports & need to reboot to get those OSX versions. I'm trying on OSX 10.5 PPC using GCC6; probably won't work but who knows?

[michaelld]

Just rebooted into OSX 10.6. Trying first without this tweak. I'll try with it (regardless of whether it fails without it). Probably will end up being Monday before I can get back to this. Just about at end of workday & all of my build-bot computers are at work, without remote access (yet; one of these days ...).

[ra1nb0w]

maybe you can commit that macro _WCHAR_H_CPLUSPLUS_98_CONFORMANCE_ in the meantime upstream fixes the problem or they found a solution.

[ra1nb0w]

I'm trying on OSX 10.5 PPC using GCC6; probably won't work but who knows?

# from documentation
if {${os.platform} eq "darwin" && ${os.major} < 13} {
    pre-fetch {
        ui_error "${subport} @${version} requires OS X 10.9 or newer"
        return -code error "unsupported Mac OS X version"
    }
}

[michaelld]

Yes I found that out the hard way LOL. I couldn't even get SoapySDR to build on OSX 10.5 PPC. Then CubicSDR failed on 10.6. I was about to try 10.7, then ran out of time at the same time as I came upon that piece of code. I'll try 10.9 Monday, but I went ahead and committed the fix: a03b49f .

[ra1nb0w]

;-)
Thank you! Have a nice holiday

[ra1nb0w]

ops..you need to bump up revision...

[michaelld]

ops..you need to bump up revision...

Nope! Here's a little history:

Rev-bumps are mostly reserved for anything that changes the ABI (binaries: applications, libraries, plugins) or API (data: headers, docs, related data such as images) or MP-internals (such as dependencies). We don't generally rev-bump for changes to *FLAGS, as those don't generally change anything on the install side; doing the rev-bump here is a call that has to be made by the maintainer.

So doing a rev-bump after changing the license is OK as that's MP-internals.

The change here just fixes the build for certain OSX versions by clarifying where to find a specific API; it doesn't otherwise impact the OSX where it's currently working & hence no rev-bump needed.

Tradition is if the build is broken right now && the fix doesn't require a rev-bump (per the above), then we put in the fix but don't rev-bump.

IMHO doing a rev-bump doesn't hurt, and I would prefer to do so for "small" builds such as this one; I think doing this helps keep track of even minor changes. But it's not tradition & not required, and for "large" builds doing so would result in tedious and often unnecessary rebuilding -- so, I bow to this tradition && I get why.

Hope this is useful!

[ra1nb0w]

Thank you for your enlightenment. In this case, I though to rev-bump to trigger the package builder. I remember this from another discussion. is this reasonable?

[michaelld]

Triggering the package builder can be done in other ways IIRC. I also tend to believe that the CubicSDR folks will push more changes soon enough (to fix this issue, or some other issue, or add new features etc), and so we'll be updating the port soon enough. That said, if you truly want the rev-bump I'll push it ... you are a port maintainer after all, so your opinion matters!

[ra1nb0w]

Was just a question to understand the best-practice/limits ;-)
Anyway, you are right we can wait the upstream fix or new commits also because who tried to build CubicSDR and it failed don't need to have a new revision to fix the problem.
I feel that my mind needs holiday and to slow down.
Just for curiosity: what do you mean with "Triggering the package builder can be done in other ways"?

[michaelld]

I believe that this is true: For people with a login to the package builder, they can trigger a package rebuild via the web interface. I might be mistaken. It's not something I do, even if I did have access (which I might).

[ra1nb0w]

ok. thank you!