Qt Licensing Changes

Apple devices are not open, are not compatible with users right to replace QT with a modified version. QT users who target those devices (through the appstore) will have to help fund QT instead.

However, this is no change from previous LGPLv2 licensing which is also incompatible with the restrictions imposed by the appstore license agreement.

That's a long way of saying, I disagree with your definition of copyleft as simply requiring you to keep your modifications free- rather, the definition of copyleft simply requires you to keep your modifications also copylefted. I'm sure you know that as well, I'm not nitpicking you so much as using your comment as a starting point for a tangential rant. :)

Of course, if you buy into the FSF's attempt to co-opt the word "free" to only refer to their brand of freedom, what you said makes sense, but their habit of trying to co-opt common, ambiguous words like "freedom" to mean something very, very, very specific that they define is probably one of the top 2-3 reasons why they've driven so many people away from their cause over the past few decades. If they mean copyleft, they should just say copyleft. Trying to co-opt "free" is at best either dishonest marketing (because who hates freedom, right?) or a dishonest rhetorical device. It's used as a passive aggressive way of laying claim to a word that means lots of different things to lots of different people, even within the context of open source licensing. To the FSF's detriment, it confuses every single discussion about their goals, because it's never clear whether someone means free-as-in-beer vs. free-as-in-freedom vs. free-as-in-RMS.

And let's be clear- free-as-in-freedom is a different thing from free-as-in-RMS. Free-as-in-RMS can be a great thing too, I just wish they would be more intellectually honest about it.

Last time I checked they might eventually be compatible with Pather or something like that.

https://en.wikipedia.org/wiki/Qt_(software)#Licensing

Having lived thru it, the situation was much worse than you imply. Its not that the non-free licenses didn't allow closed source or whatever, they more or less intentionally carefully prevented distros from legally including Qt. Just barely tight enough that on technicalities it failed the DFSG, intentionally. Debian couldn't include Qt and therefore KDE in main until the 2000 relicense.

By mainstream do you mean the 1% desktop share or in the GNU/Linux world?

Actually it was this PDP-11 mentality one of the reasons I eventually moved back into Windows / Mac OS X worlds.

I had my share of CLI starting with Timex 2068, AmigaDOS, MS-DOS, multiple UNIX flavours in the 80 - 90's, to keep doing it daily in the 21st century.

Xerox PARC REPLs were way more interesting way of interacting with the computer and live in modern IDEs.

No, it was originally not open-source at all, and it was QPL (which was just barely open-source, and crucially GPL-incompatible) for a long time. Of course we're talking a decade ago now.

You should see Unreal Engine, which uses preprocessing to extend C++ with a garbage collector, reflection, interfaces, and runtime class objects.

No they are not -- mobile interfaces are the complete opposite of CLI, and they're more popular than anything else in absolute numbers.

CLI wins on the desktop because its flexibility allows for easier automation of "work", stuff humans don't really want to do, stuff that is still predominantly carried out with keyboard-based workstations (desktops and laptops). What you refer to is basically mainstream OS developers finally recognizing that first-class automation support via text interfaces is extremely efficient for power users in professional settings -- hence the rise of Powershell and the demise of graphic-based alternatives like Apple's Automator.

But that's it. For everything else, graphical icon-based interfaces are much more popular: they allow for easier exploration and are more finger-friendly.

I think you are vastly overestimating the actual "exploration" that occurred over this time.

Windowing toolkits have extremely high barriers to entry as well as high networking effects.

The whole idea of a very hierarchical, single-threaded entity controlling all of your user interaction is very much anathema to modern CPU's. However, we are stuck with it because a new windowing toolkit would take a huge amount of effort.

It is a very common misconception that GPLv3 and LGPLv3 would require that code covered by them on the app store include the necessary signing keys or whatever else is needed to make a modified app work with Apple's DRM so it could be installed.

People think this because GPLv3 includes an "anti-Tivoization" section meant to stop people from doing what Tivo does, which is ship a locked down device full of GPL code that you cannot replace even though they give you the source code.

Here is the relevant part from GPLv3 section 6 (which is incorporated into LGPLv3 by reference from LGPLv3 section 4(e)):

    If you convey an object code work under this section
    in, or with, or specifically for use in, a User
    Product, and the conveying occurs as part of a
    transaction in which the right of possession and use
    of the User Product is transferred to the recipient
    in perpetuity or for a fixed term (regardless of how
    the transaction is characterized), the Corresponding
    Source conveyed under this section must be
    accompanied by the Installation Information.

    “Installation Information” for a User Product
    means any methods, procedures, authorization keys,
    or other information required to install and execute
    modified versions of a covered work in that User
    Product from a modified version of its Corresponding
    Source. The information must suffice to ensure that
    the continued functioning of the modified object
    code is in no case prevented or interfered with
    solely because modification has been made.

First, the code has to be conveyed in, with, or for use in a "User Product". The term "User Product" is defined a couple paragraphs earlier:

    A “User Product” is either (1) a “consumer
    product”, which means any tangible personal
    property which is normally used for personal,
    family, or household purposes, or (2) anything
    designed or sold for incorporation into a dwelling.
    In determining whether a product is a consumer
    product, doubtful cases shall be resolved in favor
    of coverage. For a particular product received by a
    particular user, “normally used” refers to a
    typical or common use of that class of product,
    regardless of the status of the particular user or
    of the way in which the particular user actually
    uses, or expects or is expected to use, the product.
    A product is a consumer product regardless of
    whether the product has substantial commercial,
    industrial or non-consumer uses, unless such uses
    represent the only significant mode of use of the
    product.

The second condition is that the software conveyance occurs "as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized)".

When you go to the app store and buy and download some random app for your iPhone (the "User Product") that conveyance is NOT part of a transaction where the right of possession and use of the "User Product" (your iPhone) was transferred, and so the anti-Tivoization provision does not apply.

If Apple were to use GPLv3 or LGPLv3 software in the iOS software, or in any of the bundled apps they ship with the phone, then the anti-Tivoization provision would apply to them, and they would have to give you the "Installation Information".

In short, the (L)GPLv3 anti-Tivoization provisions are narrowly written to only apply to Tivo-like situations: hardware vendors shipping locked down GPL code with their hardware.

There is a problem with distributing GPL (any version) or LGPL (any version) on the app store, but it has nothing to do with DRM or ensuring that users have the technical ability to install modified versions. The problem is with the app store TOS, which users must agree to in order to be allowed to use the app store.

The TOS prohibits sharing and reverse engineering. These terms are incompatible with GPL. If the app store was just a marketplace that allowed sellers and buyers to match up and exchange payment, and the actual software download came from the developer's servers this might be OK, since Apple would not actually be involved in the copying and distribution of the software so nothing they do would matter from a GPL standpoint.

Unfortunately, that's not how the app store works. The developer uploads one copy of the app, and then it is Apple that makes and distributes a copy every time someone downloads. That means that Apple has to be in compliance with the license in order to legally distribute the software.

The developer who uploaded the software has almost certainly given Apple an implicit license to do this, regardless of what the license the developer purports to distribute under says. It's been a long time since I've read the Apple developer agreement, but I'd expect there is also something explicit in there that you give such a license to Apple.

So, as long as all the GPL code is owned by that developer, then the developer is really distributing on the app store with GPL + an exception to allow Apple to distribute.

If the developer incorporates any GPL code from others, though, then unless those others have also granted Apple a GPL exception it will not be legal for Apple to distribute that app.