6 ms·

Before: LGPLv2.1 or LGPLv3 or GPLv2 or pay for a commercial license After: LGPLv3 or GPLv2 or pay for a commercial license "LGPL version 3 differs from versio

Before: LGPLv2.1 or LGPLv3 or GPLv2 or pay for a commercial license After: LGPLv3 or GPLv2 or pay for a commercial license "LGPL version 3 differs from version 2.1 in two fundamental aspects. It explicitly protects the right of the end user to not only compile their modifications, but also deploy and run them on the target device. This essentially prevents the creation of fully locked-down devices. Secondly, it explicitly includes a protection against patent claims from the entity distributing code licensed under LGPLv3. These two additions greatly help protect the end users’ freedom when using source code licensed under LGPLv3."

the_mitsuhiko 11y ago
Is LGPL3 permitted on the appstore?
- belorn 11y ago
  > Qt user will then either help the ecosystem by creating an open device that allows Qt developers to target a larger market, or help the ecosystem by funding further development of the product 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.
  - hugs 11y ago
    I was wondering how this license change helps them make more money. This is it.
    - carussell 11y ago
      Except that it doesn't, and the post that you're replying to even already said so: > this is no change from previous LGPLv2 licensing. It too was incompatible with appstore
      - the_mitsuhiko 11y ago
        > Except that it doesn't, and the post that you're replying to even already said so: As mentioned earlier: [citation needed] on this please. There are plenty of apps using LPGLv2 libraries on the app store. //EDIT: currently the Qt website under does not recommend a commercial license for mobile apps from what I can tell and the wiki page is very ambiguous: https://wiki.qt.io/Licensing-talk-about-mobile-platforms https://wiki.qt.io/Licensing-talk-about-mobile-platforms
        deleted 11y ago
        [deleted]
        FigBug 11y ago
        http://multinc.com/2009/08/24/compatibility-between-the-iphone-app-store-and-the-lgpl/ http://multinc.com/2009/08/24/compatibility-between-the-ipho... Some LGPL2 libraries add a static linking exception. Others the authors don't really care and don't bother submitting copyright violations to Apple.
        the_mitsuhiko 11y ago
        The link you just provided says this: > have a couple of choices according to the license requirements […] You can keep your app closed-source, but you provide to your users all the object code of your application necessary to re-link your application. That means for example all the .o and .a files. Most people forget that this option is in fact available to iPhone app developers.
        carussell 11y ago
        Spend two minutes to read the rest of the article. It's technically possible for anyone developing with iPhone SDK to satisfy the LGPL, but that's so trivial an observation that there's hardly a reason to mention it. Writing an app with the iPhone SDK and publishing it on the App Store are not the same thing. The latter is the point that we're discussing.
        11y ago
    - pjmlp 11y ago
      Many companies that are allergic to GPLv3, now need either to change their software stack or pay for a commercial license. EDIT: Apparently stating facts how many companies see GPLv3, regardless of the license contents, hits a nerve with the downvote squad.
      - wolfgke 11y ago
        That's a problem of the companies. GPLv3 contains no fundamental changes in the freedoms it gives and requires to be uphold - it just clarifies some things explicitly (in particular that tivoization is explicitly forbidden, where before it was some legal gray area) and gives better compatibility between the GPL and other FOSS licenses.
        pjmlp 11y ago
        I didn't say that it was a licence problem. Many companies have legal departments that forbid any form of GPL software. I had customers that any third party dependency required legal approval before being used in the code.
        wolfgke 11y ago
        You explicitly wrote about GPLv3 in your post above. For GPL software in general, your claim is surely true. But I see no reason why GPLv3 might make a difference (except for the few rare cases where tivoization might play a role) over GPLv2 here.
        pjmlp 11y ago
        Every licence change, even a comma, triggers a new legal review in such customers.
        chris_wot 11y ago
        Given they were using the LGPL before, which means they were already using GPL software, it means they are already in conflict with their legal department. In other words, what you say isn't the case.
  - the_mitsuhiko 11y ago
    > However, this is no change from previous LGPLv2 licensing. It too was incompatible with appstore. Can you elaborate on this? I was under the impression that LGPLv2 is compatible with the app store under the assumption that users can get access to the source of that library and object files of the application for re-linking.
    - belorn 11y ago
      You do not need to give users the right to republish your application on the AppStore, but you need to give users the right to deploy your app with the modified version of the LGPL code on their own devices. The Appstore agreement prohibits this, which means it adds an conflicting legal condition to the users. The Appstore agreement also restricts the use of reverse engineering, a condition which is incompatible with LGPLv2, section 6. Section 2.6 in the "iPhone Developer Program License Agreement" prohibits reverse engineering, including anything that would "enable others" to reverse engineer.
      - comex 11y ago
        I think you may be right, but if there is a conflict, it's narrower than you say. > You agree not to, or to enable others to, copy (except as expressly permitted under this Agreement), decompile, reverse engineer, disassemble, attempt to derive the source code of, modify, decrypt, or create derivative works of the Apple Software, Apple-issued certificates or any services provided by the Apple Software or otherwise provided hereunder, > "Apple Software" means the iOS SDK, the iOS, the Provisioning Profiles and any other software that Apple provides to You under the Program, including any Updates thereto that may be provided to You by Apple. Those terms don't apply to your own app. Of course, this is the agreement developers have to sign; let's look at what users have to sign, the iTunes ToC: http://www.apple.com/legal/internet-services/itunes/us/terms.html#APPS http://www.apple.com/legal/internet-services/itunes/us/terms... The relevant clauses are: > You agree not to violate, circumvent, reverse-engineer, decompile, disassemble, or otherwise tamper with any of the security technology related to such Usage Rules for any reason—or to attempt or assist another person to do so. Again it only applies to "security technology", not the app itself. There is also a default license for apps themselves that has similar language, but it has an exception if "that App Store Product is covered by a valid end user license agreement between you and the Application Provider of that App Store Product". However, all apps are distributed encrypted and any attempt to decrypt them would presumably be considered circumventing "security technology". And the LGPL requires that the terms allow for: > modification of the work for the customer's own use and reverse engineering for debugging such modifications. The latter part is potentially more broad than reverse engineering the library itself, and is probably the biggest problem. Also, in the former, "the work" refers to the entire linked binary, which per above is distributed encrypted. But I (who ANAL) think there may be a valid argument that if the app submitter separately distributes unencrypted copies of the binary, these terms are satisfied. The "security technology" in question does not actually include any code linked into the binary - the only transformation to it is encryption - so the unencrypted and encrypted versions could be considered two different representations of the same work, rather than the latter being a derivative work. Thus it would still be possible to modify and reverse engineer it by referring to the unencrypted version. But not reverse engineer iOS to debug it, so that's still a problem. Maybe if the library was sufficiently isolated from the system that it could not be reasonably considered necessary to do so... You are incorrect about needing to give users the right to deploy modified versions. An App Store submitter can satisfy either 6a or 6b: 6a requires distributing object or source code to relink the app, but says nothing about installation of the relinked version; 6b merely says "will operate properly with a modified version of the library, if the user installs one", which is different from providing a means for the user to install one. (Anyway, this may often be accomplished by jailbreaking.) edit: Not that any of this matters much. Chances are Apple will be conservative and remove an app from the store if it has any ambiguity as to valid licensing - if someone asks. Meanwhile, right now nobody is asking, and some LGPLv2 apps and libraries are in the store. The exact terms only matter if it gets to court, and because of that conservatism, it won't.
  - roel_v 11y ago
    "will have to help fund QT instead." Lol this is one of the worst cases of newspeak I've seen in months. Just say "will have to pay" because that's what you really mean.
  - joosters 11y ago
    LGPLv2 is compatible with the app store. It certainly goes against the spirit of the licence, but does not break the letter. See the comments in https://lwn.net/Articles/526355/ https://lwn.net/Articles/526355/ for a discussion about LGPL and VLC on the app store.
zx2c4 11y ago
Plus they're open sourcing the previous commercial-only components: Qt Charts Qt Data Visualization Qt Virtual Keyboard QML Profiler Clang static analyzer Qt Test Integration Qt Quick 2D renderer Also, they're binding to the KDE Qt Free agreement all the editions of Qt, not just the X11 one. This is an important update, especially as Wayland takes off.
- makomk 11y ago
  Wait, the non-OpenGL renderer for Qt Quick was commercial-only? You literally had to pay them $$$ if you wanted to develop a modern Qt app that actually worked if OpenGL wasn't available or functional (which it far too often isn't)? That's ridiculous. And even now it's only available under the GPLv3, which means that if you need to use any non-GPL-compatible code you have to pony up - and also means that distros probably can't safely ship it.
  - nilliams 11y ago
    Yeah it's really bad. I feel for anyone that has stuck with these old-school 'cross-platform toolkits' over the last few years, they have really been missing out for a while now. On top of this, the whole scene is just stagnant and decades out-of-date from my experience (trying to get into Qt a couple of years ago). There are no devs there, you're basically on your own. If you want to make cross-platform desktop apps (with opportunities for mobile too), I'd recommend hiring people who know web-dev and start looking at Electron [0] and NW.js [1]. Then you can tap into the web ecosystem with its (enormous, company-backed) massively vibrant frameworks, libraries, tools and communities. It really doesn't make sense to use things like Qt, wxWidgets, GTK anymore (opinion - willing to be proved wrong). [0] http://electron.atom.io/ http://electron.atom.io/ [1] http://nwjs.io/ http://nwjs.io/
    - twchupachup 11y ago
      I think you are wrong on pretty much everything you've stated here. > There are no devs there, you're basically on your own There is an extremely active mailing list and IRC channel (several official ones actually) where you can almost always get in touch with the actual Qt devs and others who use it for support without paying them anything. There are over 500 people in the IRC room right now. > If you want to make cross-platform desktop apps (with opportunities for mobile too), I'd recommend hiring people who know web-dev and start looking at Electron [0] and NW.js [1]. Maybe when Web Assembly (or whatever its called) becomes a thing performance will be tolerable but I have yet to come across a web application that doesn't run incredibly slowly. I use Atom for a basic code viewer right now and it is pathetically slow compared to any native applications (GEdit, Kate, Geany, etc)... and this is on a desktop machine. I can't imagine anyone creating a remotely complex web application on mobile and expecting any sort of reasonable performance. Text editors should be some of the faster applications -- imagine creating something that's media rich like a music player, a video or photo editor; it would be a disaster. Also regarding your "with opportunities for mobile too" comment, you know Qt is supported on iOS, Android, WinPho, BlackBerry, Sailfish right? > massively vibrant frameworks, libraries, tools and communities Yeah, its not like the native software community doesn't have that or anything. Unlike web tools, native tools have been developed for far longer and they are more robust and reliable. >It really doesn't make sense to use things like Qt, wxWidgets, GTK anymore Yes, if you don't care about performance and all the things web frameworks miss out on (how's that GL support looking? Native is getting ready to support Vulkan -- WebGL is still stuck on the ES2 equivalent) then jump on board the web app hype train. You're also completely overlooking embedded where Qt specifically is used extensively. Kiosks, IVIs, small displays for smart appliances, etc. I don't like the Qt model of using the GPL as a way to get people to go for their very expensive commercial offering and I think a model like Unreal Engine's (give us a share of your revenue) makes more sense as an additional option for smaller devs.
bonoboTP 11y ago
"Commercial license" is the wrong term. You (and they) should write "proprietary". You are allowed to use free software for commercial purposes. The copyleft licenses simply require you to keep your modifications also free. Many commercial business models aren't possible with copyleft licenses, though.
- mwfunk 11y ago
  When people talk about lowercase-f "free", they often aren't talking about copyleft- in my experience lowercase-f "free" is ambiguous to a lot of people. People who know nothing about open source software might assume free-as-in-price. Even people who know quite a bit about open source licensing might use lowercase-f "free" to refer to open source licenses in general, despite RMS and the FSF attempting to own that word in Orwellian fashion. 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.
  - bonoboTP 11y ago
    You seem to be factually mistaken about an important point. Nobody, not even Richard Stallman or the FSF, uses the word "free" to mean "copyleft". The two are distinct concepts. For example the MIT license is free, but not copyleft. GPL is free and copyleft. Copyleft ensures that all the derived works (AND those derived from the derived etc.) must also be distributed with a free license. In practice licenses that people call "open source" are almost always considered "free" by the FSF's terms. I wouldn't say it's a very very specific brand of freedom. It's all necessary to have the user in control. But I agree that "free software" is not a good name, due to misunderstandings about price. It could also be called "user-freedom-respecting software" or "user-controlled software" or "the-users-have-the-final-say-in-how-their-computing-is-done-and-not-the-developer software", but it would be too long.

the_mitsuhiko 11y ago

Is LGPL3 permitted on the appstore?

belorn 11y ago
> Qt user will then either help the ecosystem by creating an open device that allows Qt developers to target a larger market, or help the ecosystem by funding further development of the product 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.
- hugs 11y ago
  I was wondering how this license change helps them make more money. This is it.
  - carussell 11y ago
    Except that it doesn't, and the post that you're replying to even already said so: > this is no change from previous LGPLv2 licensing. It too was incompatible with appstore
    - the_mitsuhiko 11y ago
      > Except that it doesn't, and the post that you're replying to even already said so: As mentioned earlier: [citation needed] on this please. There are plenty of apps using LPGLv2 libraries on the app store. //EDIT: currently the Qt website under does not recommend a commercial license for mobile apps from what I can tell and the wiki page is very ambiguous: https://wiki.qt.io/Licensing-talk-about-mobile-platforms https://wiki.qt.io/Licensing-talk-about-mobile-platforms
      - deleted 11y ago
        [deleted]
      - FigBug 11y ago
        http://multinc.com/2009/08/24/compatibility-between-the-iphone-app-store-and-the-lgpl/ http://multinc.com/2009/08/24/compatibility-between-the-ipho... Some LGPL2 libraries add a static linking exception. Others the authors don't really care and don't bother submitting copyright violations to Apple.
        the_mitsuhiko 11y ago
        The link you just provided says this: > have a couple of choices according to the license requirements […] You can keep your app closed-source, but you provide to your users all the object code of your application necessary to re-link your application. That means for example all the .o and .a files. Most people forget that this option is in fact available to iPhone app developers.
        carussell 11y ago
        Spend two minutes to read the rest of the article. It's technically possible for anyone developing with iPhone SDK to satisfy the LGPL, but that's so trivial an observation that there's hardly a reason to mention it. Writing an app with the iPhone SDK and publishing it on the App Store are not the same thing. The latter is the point that we're discussing.
      - 11y ago
  - pjmlp 11y ago
    Many companies that are allergic to GPLv3, now need either to change their software stack or pay for a commercial license. EDIT: Apparently stating facts how many companies see GPLv3, regardless of the license contents, hits a nerve with the downvote squad.
    - wolfgke 11y ago
      That's a problem of the companies. GPLv3 contains no fundamental changes in the freedoms it gives and requires to be uphold - it just clarifies some things explicitly (in particular that tivoization is explicitly forbidden, where before it was some legal gray area) and gives better compatibility between the GPL and other FOSS licenses.
      - pjmlp 11y ago
        I didn't say that it was a licence problem. Many companies have legal departments that forbid any form of GPL software. I had customers that any third party dependency required legal approval before being used in the code.
        wolfgke 11y ago
        You explicitly wrote about GPLv3 in your post above. For GPL software in general, your claim is surely true. But I see no reason why GPLv3 might make a difference (except for the few rare cases where tivoization might play a role) over GPLv2 here.
        pjmlp 11y ago
        Every licence change, even a comma, triggers a new legal review in such customers.
        chris_wot 11y ago
        Given they were using the LGPL before, which means they were already using GPL software, it means they are already in conflict with their legal department. In other words, what you say isn't the case.
- the_mitsuhiko 11y ago
  > However, this is no change from previous LGPLv2 licensing. It too was incompatible with appstore. Can you elaborate on this? I was under the impression that LGPLv2 is compatible with the app store under the assumption that users can get access to the source of that library and object files of the application for re-linking.
  - belorn 11y ago
    You do not need to give users the right to republish your application on the AppStore, but you need to give users the right to deploy your app with the modified version of the LGPL code on their own devices. The Appstore agreement prohibits this, which means it adds an conflicting legal condition to the users. The Appstore agreement also restricts the use of reverse engineering, a condition which is incompatible with LGPLv2, section 6. Section 2.6 in the "iPhone Developer Program License Agreement" prohibits reverse engineering, including anything that would "enable others" to reverse engineer.
    - comex 11y ago
      I think you may be right, but if there is a conflict, it's narrower than you say. > You agree not to, or to enable others to, copy (except as expressly permitted under this Agreement), decompile, reverse engineer, disassemble, attempt to derive the source code of, modify, decrypt, or create derivative works of the Apple Software, Apple-issued certificates or any services provided by the Apple Software or otherwise provided hereunder, > "Apple Software" means the iOS SDK, the iOS, the Provisioning Profiles and any other software that Apple provides to You under the Program, including any Updates thereto that may be provided to You by Apple. Those terms don't apply to your own app. Of course, this is the agreement developers have to sign; let's look at what users have to sign, the iTunes ToC: http://www.apple.com/legal/internet-services/itunes/us/terms.html#APPS http://www.apple.com/legal/internet-services/itunes/us/terms... The relevant clauses are: > You agree not to violate, circumvent, reverse-engineer, decompile, disassemble, or otherwise tamper with any of the security technology related to such Usage Rules for any reason—or to attempt or assist another person to do so. Again it only applies to "security technology", not the app itself. There is also a default license for apps themselves that has similar language, but it has an exception if "that App Store Product is covered by a valid end user license agreement between you and the Application Provider of that App Store Product". However, all apps are distributed encrypted and any attempt to decrypt them would presumably be considered circumventing "security technology". And the LGPL requires that the terms allow for: > modification of the work for the customer's own use and reverse engineering for debugging such modifications. The latter part is potentially more broad than reverse engineering the library itself, and is probably the biggest problem. Also, in the former, "the work" refers to the entire linked binary, which per above is distributed encrypted. But I (who ANAL) think there may be a valid argument that if the app submitter separately distributes unencrypted copies of the binary, these terms are satisfied. The "security technology" in question does not actually include any code linked into the binary - the only transformation to it is encryption - so the unencrypted and encrypted versions could be considered two different representations of the same work, rather than the latter being a derivative work. Thus it would still be possible to modify and reverse engineer it by referring to the unencrypted version. But not reverse engineer iOS to debug it, so that's still a problem. Maybe if the library was sufficiently isolated from the system that it could not be reasonably considered necessary to do so... You are incorrect about needing to give users the right to deploy modified versions. An App Store submitter can satisfy either 6a or 6b: 6a requires distributing object or source code to relink the app, but says nothing about installation of the relinked version; 6b merely says "will operate properly with a modified version of the library, if the user installs one", which is different from providing a means for the user to install one. (Anyway, this may often be accomplished by jailbreaking.) edit: Not that any of this matters much. Chances are Apple will be conservative and remove an app from the store if it has any ambiguity as to valid licensing - if someone asks. Meanwhile, right now nobody is asking, and some LGPLv2 apps and libraries are in the store. The exact terms only matter if it gets to court, and because of that conservatism, it won't.
- roel_v 11y ago
  "will have to help fund QT instead." Lol this is one of the worst cases of newspeak I've seen in months. Just say "will have to pay" because that's what you really mean.
- joosters 11y ago
  LGPLv2 is compatible with the app store. It certainly goes against the spirit of the licence, but does not break the letter. See the comments in https://lwn.net/Articles/526355/ https://lwn.net/Articles/526355/ for a discussion about LGPL and VLC on the app store.

zx2c4 11y ago

Plus they're open sourcing the previous commercial-only components: Qt Charts Qt Data Visualization Qt Virtual Keyboard QML Profiler Clang static analyzer Qt Test Integration Qt Quick 2D renderer Also, they're binding to the KDE Qt Free agreement all the editions of Qt, not just the X11 one. This is an important update, especially as Wayland takes off.

makomk 11y ago
Wait, the non-OpenGL renderer for Qt Quick was commercial-only? You literally had to pay them $$$ if you wanted to develop a modern Qt app that actually worked if OpenGL wasn't available or functional (which it far too often isn't)? That's ridiculous. And even now it's only available under the GPLv3, which means that if you need to use any non-GPL-compatible code you have to pony up - and also means that distros probably can't safely ship it.
- nilliams 11y ago
  Yeah it's really bad. I feel for anyone that has stuck with these old-school 'cross-platform toolkits' over the last few years, they have really been missing out for a while now. On top of this, the whole scene is just stagnant and decades out-of-date from my experience (trying to get into Qt a couple of years ago). There are no devs there, you're basically on your own. If you want to make cross-platform desktop apps (with opportunities for mobile too), I'd recommend hiring people who know web-dev and start looking at Electron [0] and NW.js [1]. Then you can tap into the web ecosystem with its (enormous, company-backed) massively vibrant frameworks, libraries, tools and communities. It really doesn't make sense to use things like Qt, wxWidgets, GTK anymore (opinion - willing to be proved wrong). [0] http://electron.atom.io/ http://electron.atom.io/ [1] http://nwjs.io/ http://nwjs.io/
  - twchupachup 11y ago
    I think you are wrong on pretty much everything you've stated here. > There are no devs there, you're basically on your own There is an extremely active mailing list and IRC channel (several official ones actually) where you can almost always get in touch with the actual Qt devs and others who use it for support without paying them anything. There are over 500 people in the IRC room right now. > If you want to make cross-platform desktop apps (with opportunities for mobile too), I'd recommend hiring people who know web-dev and start looking at Electron [0] and NW.js [1]. Maybe when Web Assembly (or whatever its called) becomes a thing performance will be tolerable but I have yet to come across a web application that doesn't run incredibly slowly. I use Atom for a basic code viewer right now and it is pathetically slow compared to any native applications (GEdit, Kate, Geany, etc)... and this is on a desktop machine. I can't imagine anyone creating a remotely complex web application on mobile and expecting any sort of reasonable performance. Text editors should be some of the faster applications -- imagine creating something that's media rich like a music player, a video or photo editor; it would be a disaster. Also regarding your "with opportunities for mobile too" comment, you know Qt is supported on iOS, Android, WinPho, BlackBerry, Sailfish right? > massively vibrant frameworks, libraries, tools and communities Yeah, its not like the native software community doesn't have that or anything. Unlike web tools, native tools have been developed for far longer and they are more robust and reliable. >It really doesn't make sense to use things like Qt, wxWidgets, GTK anymore Yes, if you don't care about performance and all the things web frameworks miss out on (how's that GL support looking? Native is getting ready to support Vulkan -- WebGL is still stuck on the ES2 equivalent) then jump on board the web app hype train. You're also completely overlooking embedded where Qt specifically is used extensively. Kiosks, IVIs, small displays for smart appliances, etc. I don't like the Qt model of using the GPL as a way to get people to go for their very expensive commercial offering and I think a model like Unreal Engine's (give us a share of your revenue) makes more sense as an additional option for smaller devs.

bonoboTP 11y ago

"Commercial license" is the wrong term. You (and they) should write "proprietary". You are allowed to use free software for commercial purposes. The copyleft licenses simply require you to keep your modifications also free. Many commercial business models aren't possible with copyleft licenses, though.

mwfunk 11y ago
When people talk about lowercase-f "free", they often aren't talking about copyleft- in my experience lowercase-f "free" is ambiguous to a lot of people. People who know nothing about open source software might assume free-as-in-price. Even people who know quite a bit about open source licensing might use lowercase-f "free" to refer to open source licenses in general, despite RMS and the FSF attempting to own that word in Orwellian fashion. 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.
- bonoboTP 11y ago
  You seem to be factually mistaken about an important point. Nobody, not even Richard Stallman or the FSF, uses the word "free" to mean "copyleft". The two are distinct concepts. For example the MIT license is free, but not copyleft. GPL is free and copyleft. Copyleft ensures that all the derived works (AND those derived from the derived etc.) must also be distributed with a free license. In practice licenses that people call "open source" are almost always considered "free" by the FSF's terms. I wouldn't say it's a very very specific brand of freedom. It's all necessary to have the user in control. But I agree that "free software" is not a good name, due to misunderstandings about price. It could also be called "user-freedom-respecting software" or "user-controlled software" or "the-users-have-the-final-say-in-how-their-computing-is-done-and-not-the-developer software", but it would be too long.