From: Ryan B. <rya...@gm...> - 2013-08-10 11:06:31
|
Based on Razor-Qt licensing policies that I read, the author of Razor-Qt prefer LGPL over GPL. How the merge of LXDE and Razor-Qt will affect the future of LXDE-Qt? Will it also prefer LGPL over GPL. I suggest both developers should consider it earlier before everything get more complicated. My opinion is to prefer LGPL over GPL, as it will help wider acceptance for LXDE-Qt especially from corporate support that may interested with LXDE or from non-Linux operating system that avoid GPL as possible (e.g. FreeBSD). Just for information, there are many notable projects which switch their license from GPL to more relaxed license : LibVLC, GEGL, ApacheOpenOffice, SDL, PySide, etc. Source: https://github.com/Razor-qt/razor-qt/wiki/Licensing-policy Regards, RyanBram |
From: Ryan B. <rya...@gm...> - 2013-08-12 00:44:12
|
Based on Razor-Qt licensing policies that I read, the author of Razor-Qt prefer LGPL over GPL. How the merge of LXDE and Razor-Qt will affect the future of LXDE-Qt? Will it also prefer LGPL over GPL. I suggest both developers should consider it earlier before everything get more complicated. My opinion is to prefer LGPL over GPL, as it will help wider acceptance for LXDE-Qt especially from corporate support that may interested with LXDE or from non-Linux operating system that avoid GPL as possible (e.g. FreeBSD). Just for information, there are many notable projects which avoid or switch their license from GPL to more relaxed license for wider acceptance reason : VLC, GEGL, ApacheOpenOffice, SDL, PySide, etc. Source: https://github.com/Razor-qt/razor-qt/wiki/Licensing-policy -- Best regards, Ryan Bram |
From: PCMan <pcm...@gm...> - 2013-08-12 09:26:50
|
On Mon, Aug 12, 2013 at 8:44 AM, Ryan Bramantya <rya...@gm...> wrote: > Based on Razor-Qt licensing policies that I read, the author of Razor-Qt > prefer LGPL over GPL. > > How the merge of LXDE and Razor-Qt will affect the future of LXDE-Qt? Will > it also prefer LGPL over GPL. > I suggest both developers should consider it earlier before everything get > more complicated. > My opinion is to prefer LGPL over GPL, as it will help wider acceptance for > LXDE-Qt especially from corporate support that may interested with LXDE or > from non-Linux operating system that avoid GPL as possible (e.g. FreeBSD). > Just for information, there are many notable projects which avoid or switch > their license from GPL to more relaxed license for wider acceptance reason : > VLC, GEGL, ApacheOpenOffice, SDL, PySide, etc. > > Source: > https://github.com/Razor-qt/razor-qt/wiki/Licensing-policy > > -- > > Best regards, > Ryan Bram As far as I know, almost all existing razor components are using LGPL. The only exception is razor-config, which contains GPL code. Besides, in razor-config-mouse component, there are some file licensed under WTFPL, which seems to be GPL compatible. On the lxde side, most components are GPL'd, and some contains LGPL and MIT code. Since we now well separated components into their own repos, it's easy to limit the scope of GPL code and prevent GPL infection. Cheers! |
From: Ryan B. <rya...@gm...> - 2013-08-12 10:54:42
|
Thanks, Hong Jen Yee for replying my messages. On the lxde side, most components are GPL'd, and some contains LGPL > and MIT code. > Did you have any plan to relicensing those GPL component from LXDE to LGPL (e.g. PCManFM, LXDM, LxImage-Qt, etc). I do not want to seem patronizing, but sometimes the selection of a license is become a political strategy for a free software to be widely accepted. For example is FreeBSD operating system. They moved almost all of their infrastructure from GCC to LLVM+Clang just for avoidng GPL software in their base system. It was a non trivial choice, but in reality they did it. GNOME and KDE licensed their component mostly in GPL, so people who avoid GPL (for whatever reason) will look for alternative desktop environment that fit they needs. Building another desktop environment just for avoiding GPL is unnecessary for them, so they will consider to support development of LXDE-Qt that will become a win-win solution. Long life LXDE-Qt. -- Best regards, Ryan Bram |
From: Kevin K. <and...@gm...> - 2013-08-12 11:18:54
Attachments:
signature.asc
|
On Monday, 2013-08-12, Ryan Bramantya wrote: > GNOME and KDE licensed their component mostly in GPL, so people who avoid > GPL (for whatever reason) will look for alternative desktop environment > that fit they needs. For KDE it depends on the type of component. All things that are part of the platform are LGPL, BSD or MIT licensed, only end user applications are often GPL licensed. See http://techbase.kde.org/Policies/Licensing_Policy Basic rule of thumb: anything a developer might use -> LGPL, anything only a user would use -> GPL Of course there are exceptions, e.g. application speciifc library that its author wants to be GPL or application code being LGPL because the author plans on making it a library, etc. Cheers, Kevin -- -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring |
From: Ryan B. <rya...@gm...> - 2013-08-12 12:50:02
|
> For KDE it depends on the type of component. > All things that are part of the platform are LGPL, BSD or MIT licensed, > only > end user applications are often GPL licensed. > > See http://techbase.kde.org/Policies/Licensing_Policy > > Basic rule of thumb: anything a developer might use -> LGPL, anything only > a > user would use -> GPL > Thanks, Levin for giving me clear explanation. But as far as I am aware as KDE user, some important parts of KDE still under GPL, such as KWin and Dolphin File Manager. Those are might be end user applications but sometimes developer needs to improve them with their specific needs without affected with GPL. You probably already know if the current trend of free software seems to move away from a very radical copyleft license for more relaxed license. WebKit and GoogleChrome which are basically derived from KHTML and Android OS with the Linux kernel as its core is a small example to prove that non-copyleft license helps the wider acceptance of free software. Non-GPL software will attract more developers to collaborate together, ranging from individual contributors to large-scale corporations for the benefit of each. Sometimes an individual's involvement is not enough to manage large-scale free software projects, so the involvement of large companies are sometimes required. This is where the LGPL serves as a compromise between the interests of free software activists with a corporate interests. Free software movement is still relevant today, but stay away from proprietary is something that is impossible in this era. Linux Torvlads said "*I use the best tool for the job, even if that includes proprietary software.*" Clement Lefebvre (Linux Mint Founder) also said: "*Freedom should be granted to the developer to decide whether he wants to distribute his source code or not. I don't see why he wouldn't (unless he's not familiar with open source and maybe scared of not generating profit... I don't know) but the thing is, this is his choice. Similarly it's your choice and your freedom to use his software or not. Having some political movement telling you to restrict your own choice and boycotting good and helpful software just because you didn't get the source code with it is simply going against your own freedom.*" After all, I didn't want to start license debate. I just want to share my opinion that might useful for LXDE-Qt contributors to consider. -- Best regards, Ryan Bram |
From: PCMan <pcm...@gm...> - 2013-08-12 12:59:11
|
On Mon, Aug 12, 2013 at 8:49 PM, Ryan Bramantya <rya...@gm...> wrote: > >> For KDE it depends on the type of component. >> All things that are part of the platform are LGPL, BSD or MIT licensed, >> only >> end user applications are often GPL licensed. >> >> See http://techbase.kde.org/Policies/Licensing_Policy >> >> Basic rule of thumb: anything a developer might use -> LGPL, anything only >> a >> user would use -> GPL > > > Thanks, Levin for giving me clear explanation. But as far as I am aware as > KDE user, some important parts of KDE still under GPL, such as KWin and > Dolphin File Manager. Those are might be end user applications but sometimes > developer needs to improve them with their specific needs without affected > with GPL. > > You probably already know if the current trend of free software seems to > move away from a very radical copyleft license for more relaxed license. > WebKit and GoogleChrome which are basically derived from KHTML and Android > OS with the Linux kernel as its core is a small example to prove that > non-copyleft license helps the wider acceptance of free software. Non-GPL > software will attract more developers to collaborate together, ranging from > individual contributors to large-scale corporations for the benefit of each. > Sometimes an individual's involvement is not enough to manage large-scale > free software projects, so the involvement of large companies are sometimes > required. This is where the LGPL serves as a compromise between the > interests of free software activists with a corporate interests. > > Free software movement is still relevant today, but stay away from > proprietary is something that is impossible in this era. > > Linux Torvlads said > > "I use the best tool for the job, even if that includes proprietary > software." > > > Clement Lefebvre (Linux Mint Founder) also said: > > "Freedom should be granted to the developer to decide whether he wants to > distribute his source code or not. I don't see why he wouldn't (unless he's > not familiar with open source and maybe scared of not generating profit... I > don't know) but the thing is, this is his choice. Similarly it's your choice > and your freedom to use his software or not. Having some political movement > telling you to restrict your own choice and boycotting good and helpful > software just because you didn't get the source code with it is simply going > against your own freedom." > > > After all, I didn't want to start license debate. I just want to share my > opinion that might useful for LXDE-Qt contributors to consider. > > -- > Best regards, > Ryan Bram No debate needed here. Your proposal is quite reasonable. For future development, we can be more careful in this part. For code that has been written, however, it's hard to relicense. Given the fact that some existing work contains code from various contributors, it's difficult to get conscent from everyone to change the license. For newly written code, I think LGPL is good. This approach has some drawbacks as well. When you choose LGPL, then you cannot use GPL'd code from other project, either. For example, if we find a good piece of code in KDE that suit our need, we cannot use it if it's GPL'd. It's the price we need to pay. |
From: Benjamin E. <b.e...@gm...> - 2013-08-12 16:57:31
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, just my two cents: In the same way it is possible to license a program as GPL2 and GPL3, it is also possible to license a program under LGPL and GPL. Then, if one wants to use a component, that is GPL only, one can simply drop the LGPL license from that point. So, if you want to use a copyleft license but have no prejudice about how strong the copyleft should be, you might triple license GPL2+/LGPL2+/MPL to cover the most widespread incompatible copyleft licenses and leave as many possibilities open as possible. (Incidentally, that is what LibreOffice does.) Cheers, Benjamin > For newly written code, I think LGPL is good. This approach has > some drawbacks as well. When you choose LGPL, then you cannot use > GPL'd code from other project, either. For example, if we find a > good piece of code in KDE that suit our need, we cannot use it if > it's GPL'd. It's the price we need to pay. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSCRPnAAoJEK27BRz67lmpA4AP/A6M5ys0yAHxrgyqGDL9PNU1 dtgJK+MKoTJMljbYgF7Tlraw5d7ZkVEjsfhlYmCjN/f6geyekaGyPHwiPbKBYtYN lxnPPkktEcLuPIiEQ+AufeYrl1Jtp/8IeGi14Di9eFAzljXNO/jEjggYbjsd8tpH WAuTUJwa+osd0bVQJZ8NbBSXzxDHy2gx6B13UGsjIDg8iGi4GC6LJhtIiKJeeXUz p2fF1a3cLmMIQ3FO8mK3zbCIxcoftZYsO5It01RH7JV5sqRS4+yKfFqc7c/bWKHc 6XukSC04hNE9WB9q+NC6s2Hs4Xc99YNZK0HSkeuZ1yCIpJqpcSFKgqm1xt7eDqTo ml2BHenvlkTaEq547e6ggrj5VA0YK2zEsAolWltuDWu6joa6z8hcuIPp/CI49BR/ M3zb1sJiJN2ZjnqCPj/JwItTKAH/QM+F3GF6EGkYEDRvUa1Ot4bugKKf+OXoIgAt gxwHurD5ohp1ZNWTXORBzIKCyf8Hhm1t+GJr/qbC+nYafJOp4Tha/rBErItNhxPQ UbPz8ASk7K1amPkGJbPm2kMaHCf+LUrtB/aTAA9yCuA8RJWJrciol5woJ/tcgxEK xWkySOJadjrPEhP15H6yFvY95s7F1jXI7UZGhtsb17e4J74Z1UUKbLE6ydL+iJ4+ V6RLmJ36pgjMpS9aoT74 =kZ0K -----END PGP SIGNATURE----- |
From: Kevin K. <and...@gm...> - 2013-08-12 13:28:23
Attachments:
signature.asc
|
On Monday, 2013-08-12, Ryan Bramantya wrote: > > For KDE it depends on the type of component. > > All things that are part of the platform are LGPL, BSD or MIT licensed, > > only > > end user applications are often GPL licensed. > > > > See http://techbase.kde.org/Policies/Licensing_Policy > > > > Basic rule of thumb: anything a developer might use -> LGPL, anything > > only a > > user would use -> GPL > > Thanks, Levin for giving me clear explanation. But as far as I am aware as > KDE user, some important parts of KDE still under GPL, such as KWin and > Dolphin File Manager. As the license policy says, only things in the KDE platform need to be LGPL/BSD/MIT/X11 licensed, applications like Dolphin or workspace components like KWin don't. > Those are might be end user applications but > sometimes developer needs to improve them with their specific needs without > affected with GPL. Not sure what you mean there, but a lot of plugin APIs are in fact LGPL licensed. Any change to the application's code itself would equally be "affected" by GPL and LGPL license rules. > You probably already know if the current trend of free software seems to > move away from a very radical copyleft license for more relaxed license. I've read claims to that effect, yes. > WebKit and GoogleChrome which are basically derived from KHTML and Android > OS with the Linux kernel as its core is a small example to prove that > non-copyleft license helps the wider acceptance of free software. Two of the above mentioned projects show that copyleft licenses are no obstacle to wide spread accpetance. Aside from the Linux kernel, which is basically running this planet, WebKit is probably even more impressive in uptake, due to it being used by even hardcode proprietary vendors like Apple. It has also nicely demonstrated that shipping a copyleft component on an embedded or mobile device is no problem either. > Non-GPL > software will attract more developers to collaborate together, ranging from > individual contributors to large-scale corporations for the benefit of > each. Probably, the Linux kernel seems to be doing fine, both in individual as well as corporate contributors. Not sure how good non-GPL non-proprietary kernels are doing out there. > Sometimes an individual's involvement is not enough to manage > large-scale free software projects, so the involvement of large companies > are sometimes required. Maybe, KDE is pretty large and is doing quite fine. But then again we have a lot of very committed people :) > Free software movement is still relevant today, but stay away from > proprietary is something that is impossible in this era. I wouldn't say it is impossible, but it can be beneficial if one can get proprietary software vendors to at least collaborate on infrastructure and base technologies instead of fragmentation, hence why most free software communities using respective licensing for their products in those areas. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring |
From: <chr...@su...> - 2013-08-12 14:07:29
|
2013/8/12 Kevin Krammer <and...@gm...> > On Monday, 2013-08-12, Ryan Bramantya wrote: > > > For KDE it depends on the type of component. > > > All things that are part of the platform are LGPL, BSD or MIT licensed, > > > only > > > end user applications are often GPL licensed. > > > > > > See http://techbase.kde.org/Policies/Licensing_Policy > > > > > > Basic rule of thumb: anything a developer might use -> LGPL, anything > > > only a > > > user would use -> GPL > > > > Thanks, Levin for giving me clear explanation. But as far as I am aware > as > > KDE user, some important parts of KDE still under GPL, such as KWin and > > Dolphin File Manager. > > As the license policy says, only things in the KDE platform need to be > LGPL/BSD/MIT/X11 licensed, applications like Dolphin or workspace > components > like KWin don't. > > > Those are might be end user applications but > > sometimes developer needs to improve them with their specific needs > without > > affected with GPL. > > Not sure what you mean there, but a lot of plugin APIs are in fact LGPL > licensed. Any change to the application's code itself would equally be > "affected" by GPL and LGPL license rules. > > > You probably already know if the current trend of free software seems to > > move away from a very radical copyleft license for more relaxed license. > > I've read claims to that effect, yes. > > > WebKit and GoogleChrome which are basically derived from KHTML and > Android > > OS with the Linux kernel as its core is a small example to prove that > > non-copyleft license helps the wider acceptance of free software. > > Two of the above mentioned projects show that copyleft licenses are no > obstacle to wide spread accpetance. > Aside from the Linux kernel, which is basically running this planet, > WebKit is > probably even more impressive in uptake, due to it being used by even > hardcode > proprietary vendors like Apple. It has also nicely demonstrated that > shipping > a copyleft component on an embedded or mobile device is no problem either. > > Also, one might add, had webkit been under a permissive license (like BSD) Apple probably wouldn't have contributed back their work on the code. br. Chr. > > Non-GPL > > software will attract more developers to collaborate together, ranging > from > > individual contributors to large-scale corporations for the benefit of > > each. > > Probably, the Linux kernel seems to be doing fine, both in individual as > well > as corporate contributors. Not sure how good non-GPL non-proprietary > kernels > are doing out there. > > > Sometimes an individual's involvement is not enough to manage > > large-scale free software projects, so the involvement of large companies > > are sometimes required. > > Maybe, KDE is pretty large and is doing quite fine. But then again we have > a > lot of very committed people :) > > > Free software movement is still relevant today, but stay away from > > proprietary is something that is impossible in this era. > > I wouldn't say it is impossible, but it can be beneficial if one can get > proprietary software vendors to at least collaborate on infrastructure and > base technologies instead of fragmentation, hence why most free software > communities using respective licensing for their products in those areas. > > Cheers, > Kevin > -- > Kevin Krammer, KDE developer, xdg-utils developer > KDE user support, developer mentoring > |
From: Ryan B. <rya...@gm...> - 2013-08-12 17:15:00
|
Hi Christian, Also, one might add, had webkit been under a permissive license (like BSD) > Apple probably wouldn't have contributed back their work on the code. > > br. Chr. > > I think it is fair for everyone if Apple wouldn't have contributed back their work on the code as large portion of Webkit itself which under BSD-like license are come from Apple itself. Just for information, a modern, BSD-like licensed Clang compiler which someday will become a popular replacement for GPL-ed GCC also sponsored by Apple. Some corporation probably wouldn't have contributed back their work on the code, but some other corporation wouldn't stupid enough to maintain the source code itself which will take a lot of cost. That's why some of them will release their contribution to the base code and collaborate with free software community for the benefit of each. GPL of course not as good as LGPL for this purpose. And this is what BSD community believe in their license for years. (See "Why you should use a BSD style license for your Open Source Project<http://www.freebsd.org/doc/en/articles/bsdl-gpl/article.html>" for more informations). Read Also: Linux-FAQ<http://web.archive.org/web/20120430113349/http://linux-faq.org/eng/index.html> -- Best regards, Ryan Bram |
From: Ryan B. <rya...@gm...> - 2013-08-12 17:02:46
|
Hi, Hong Jen Yee, Thank you very much. No matter how great GNU and Linux movement, but we still shouldn't forget the other free software community movement, which may have a different philosophy. BSD, Apache, Mozilla is just some example of the free software community who believe that the GPL is not the best solution for all the things, so that they choose to create their own license. LXDE as a community is expected to be neutral and choose the LGPL as a license which is expected to be a solution to improve collaboration among the communities. For newly written code, I think LGPL is good. > I hope this decission will bring a good sake for future LXDE-Qt and FLOSS movement. > This approach has some drawbacks as well. > When you choose LGPL, then you cannot use GPL'd code from other project, > either. > For example, if we find a good piece of code in KDE that suit our > need, we cannot use it if it's GPL'd. It's the price we need to pay. > I think you don't need to worry, because as Kevin has said: "Anything a developer might use -> LGPL, anything only an end user would use -> GPL". It means KDELibs, KParts (library for building KDE applications such as Okular, Kopete, etc), and other good library things from KDE wasn't GPL. The only thing that may be worth for building a desktop environment, but under GPL is KWin. After all, I just want to convey that LXDE isn't GNU/Linux centric, LXDE is for everyone in mind (BSD community, Apache community, common user, etc) even though it may be developed in Linux environment. -- Best regards, Ryan Bram |
From: Kevin K. <kr...@kd...> - 2013-08-12 17:34:27
Attachments:
signature.asc
|
On Monday, 2013-08-12, Ryan Bramantya wrote: > > This approach has some drawbacks as well. > > When you choose LGPL, then you cannot use GPL'd code from other project, > > either. > > For example, if we find a good piece of code in KDE that suit our > > need, we cannot use it if it's GPL'd. It's the price we need to pay. > > I think you don't need to worry, because as Kevin has said: "Anything a > developer might use -> LGPL, anything only an end user would use -> GPL". > It means KDELibs, KParts (library for building KDE applications such as > Okular, Kopete, etc), and other good library things from KDE wasn't GPL. > The only thing that may be worth for building a desktop environment, but > under GPL is KWin. Sure, but in such a case it might be more viable to use KWin as a whole instead of taking some pieces of it and then maintaining them yourself. It might also not be easy to extract that code, application code tends to depend on other parts of the application, e.g. singletons. It will likely also come without API docs. > After all, I just want to convey that LXDE isn't GNU/Linux centric, LXDE is > for everyone in mind (BSD community, Apache community, common user, etc) > even though it may be developed in Linux environment. Sure, but that isn't a licensing problem. KDE software, for example, is being used on operating system ranging from extremely persmissive to fully proprietary. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring |
From: Ryan B. <rya...@gm...> - 2013-08-12 17:24:08
|
Hi Benjamin, Thanks for join in this discussion. just my two cents: In the same way it is possible to license a program > as GPL2 and GPL3, it is also possible to license a program under LGPL > and GPL. Then, if one wants to use a component, that is GPL only, one > can simply drop the LGPL license from that point. So, if you want to > use a copyleft license but have no prejudice about how strong the > copyleft should be, you might triple license GPL2+/LGPL2+/MPL to cover > the most widespread incompatible copyleft licenses and leave as many > possibilities open as possible. (Incidentally, that is what > LibreOffice does.) > I think there is no need to use tri-license. Based on LGPL licensing policy, it said that LGPL can be converted to GPL (but not vice versa). Therefore, by chosing LGPL as license, if someone want to create GPL software, the just converting it to GPL and if some one want to create BSD or proprietary software and avoid LGPL, the just dynamically linking their software to LGPL component which wouldn't affect their BSD or proprietary license. This is what I see as the advantage of LGPL from any other license. -- Best regards, Ryan Bram |
From: Stephan S. <gma...@sp...> - 2013-08-12 17:28:45
|
On 13-08-12 01:24 PM, Ryan Bramantya wrote: > > I think there is no need to use tri-license. Based on LGPL licensing > policy, it said that LGPL can be converted to GPL (but not vice versa). > Therefore, by chosing LGPL as license, if someone want to create GPL > software, the just converting it to GPL and if some one want to create > BSD or proprietary software and avoid LGPL, the just dynamically linking > their software to LGPL component which wouldn't affect their BSD or > proprietary license. This is what I see as the advantage of LGPL from > any other license. > In fact, one of the bloggers on Planet Mozilla just (as in within the last hour) announced that they'd finished retiring the LGPL/GPL/MPL tri-license in favor of the MPL2. http://blog.gerv.net/2013/08/mpl-2-upgrade-process-complete/ (The MPL2 was specifically written to support that kind of conversion chain so the tri-license wouldn't be necessary) https://en.wikipedia.org/wiki/Mozilla_Public_License#Compatibility_with_other_licenses |
From: Kevin K. <kr...@kd...> - 2013-08-12 17:30:36
Attachments:
signature.asc
|
On Monday, 2013-08-12, Ryan Bramantya wrote: > I think there is no need to use tri-license. Based on LGPL licensing > policy, it said that LGPL can be converted to GPL (but not vice versa). It doesn't have to be converted, it is compatible. > Therefore, by chosing LGPL as license, if someone want to create GPL > software, the just converting it to GPL and if some one want to create BSD > or proprietary software and avoid LGPL, the just dynamically linking their > software to LGPL component which wouldn't affect their BSD or proprietary > license. This is what I see as the advantage of LGPL from any other > license. Which is why libraries are usually LGPL licensed. Can you give an example where one would want to use application code to create a new library and link against it when the original source of the code is not using said library? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring |
From: Ryan B. <rya...@gm...> - 2013-08-12 18:52:52
|
Hi Kevin, [^_^] Yes :) > Btw, I recommend to keep the attribution lines intact. > I'm sorry I didn't know what it (attribution lines) means There is simply no such thing as "better" when it comes to licensing. > There is such thing. If not, there is no point for Richard Stallman to suggest Vorbis Library licensing under BSD-like license and not under GPL or even the Lesser GPL. Well, if we were simple media representatives than yes, that would probably > our view. Fortunately, as IT professionals, we have a way bigger picture > and > know that Linux has been a tremendous success in a lot of fields long > before > mobile device vendors started using it. > Those are basically just the tip of the iceberg, the part that is visible > by > the uneducated population. > The advantage of technology is not just to be enjoyed by some professionals in a particular field, but for every class of user. We can enjoyed an advantages of Ferrari or Duccati without needed to become a mechanical engineer as we can enjoyed an advantages of Linux Kernel in Android without needed to become an IT professionals. We cannot said someone as uneducated just because they didn't know what Linux kernel was. What you say as uneducated may be a doctor, a biologist, a lawyer, a historian, a president, a pastor, etc. who just have no time to examine what Linux was. Just like an IT professionals who may didn't know about *Osteoprotegerin*, TNFRSF11B gene, *pacta sunt servanda*, history of mongol, etc. > Sure, if there hadn't been KHTML or if it had been permissively licensed > then > there would be not WebKit. Fortunately a team of dedicated engineers at KDE > created a world class HTML render engine plus a JavaScript engine and > licensed > it in a way that both allowed usage in prorprietary context but also > ensured > that improvements would become available under the same terms as well. > If KHTML licensed under GPL in the first place, Apple wouldn't interested to take its source code and enhance it. Obviously we at KDE (myself included) wouldn't put tons of our code under > LGPL > license terms if we thought it would be bad license, wouldn't we? >From this point of view, I think we are same. I never persuade LXDE-Qt developers to use permissive license. I only convinced them to use LGPL instead of GPL, both for libraries and for its native (non-3rd party) applications. So there is no need to worry about KWin, Konqueror, Dolphin, etc because they weren't native LXDE-Qt applications. Sure, but that isn't a licensing problem. KDE software, for example, is > being used on operating system ranging from extremely persmissive to fully > proprietary. Sometimes license can become a problem. The depreciation of GCC in FreeBSD base system is one of the example. And I never hear a fully proprietary operating system with copyleft component in it. -- Best regards, Ryan Bram |
From: Ryan B. <rya...@gm...> - 2013-08-12 18:54:27
|
Hi Kevin, [^_^] Yes :) > Btw, I recommend to keep the attribution lines intact. > I'm sorry I didn't know what it (attribution lines) means There is simply no such thing as "better" when it comes to licensing. > There is such thing. If not, there is no point for Richard Stallman to suggest Vorbis Library licensing under BSD-like license and not under GPL or even the Lesser GPL. Well, if we were simple media representatives than yes, that would probably > our view. Fortunately, as IT professionals, we have a way bigger picture > and > know that Linux has been a tremendous success in a lot of fields long > before > mobile device vendors started using it. > Those are basically just the tip of the iceberg, the part that is visible > by > the uneducated population. > The advantage of technology is not just to be enjoyed by some professionals in a particular field, but for every class of user. We can enjoyed an advantages of Ferrari or Duccati without needed to become a mechanical engineer as we can enjoyed an advantages of Linux Kernel in Android without needed to become an IT professionals. We cannot said someone as uneducated just because they didn't know what Linux kernel was. What you say as uneducated may be a doctor, a biologist, a lawyer, a historian, a president, a pastor, etc. who just have no time to examine what Linux was. Just like an IT professionals who may didn't know about *Osteoprotegerin*, TNFRSF11B gene, *pacta sunt servanda*, history of mongol, etc. > Sure, if there hadn't been KHTML or if it had been permissively licensed > then > there would be not WebKit. Fortunately a team of dedicated engineers at KDE > created a world class HTML render engine plus a JavaScript engine and > licensed > it in a way that both allowed usage in prorprietary context but also > ensured > that improvements would become available under the same terms as well. > If KHTML licensed under GPL in the first place, Apple wouldn't interested to take its source code and enhance it. Obviously we at KDE (myself included) wouldn't put tons of our code under > LGPL > license terms if we thought it would be bad license, wouldn't we? >From this point of view, I think we are same. I never persuade LXDE-Qt developers to use permissive license. I only convinced them to use LGPL instead of GPL, both for libraries and for its native (non-3rd party) applications. So there is no need to worry about KWin, Konqueror, Dolphin, etc because they weren't native LXDE-Qt applications. Sure, but that isn't a licensing problem. KDE software, for example, is > being used on operating system ranging from extremely persmissive to fully > proprietary. Sometimes license can become a problem. The depreciation of GCC in FreeBSD base system is one of the example. And I never hear a fully proprietary operating system with copyleft component in it. -- Best regards, Ryan Bram |
From: Stephan S. <gma...@sp...> - 2013-08-12 19:17:34
|
Keep in mind that there are other viewpoints on licensing. For example, this blog post by Zed Shaw does a great job of explaining why I GPL so many of my end-user applications and scripts when, strictly speaking, I wouldn't otherwise mind releasing them under an MIT license. http://zedshaw.com/essays/why_i_gpl.html |
From: Ryan B. <rya...@gm...> - 2013-08-12 19:31:17
|
2013/8/13 Stephan Sokolow <gma...@sp...> > Keep in mind that there are other viewpoints on licensing. For example, > this blog post by Zed Shaw does a great job of explaining why I GPL so > many of my end-user applications and scripts when, strictly speaking, I > wouldn't otherwise mind releasing them under an MIT license. > > http://zedshaw.com/essays/why_i_gpl.html This is why I see LGPL as a compromise for satisfying GPL, BSD, and even proprietary supporters. I didn't support only GPL activists, nor only BSD activists, I supported both as a free software activists. -- Best regards, Ryan Bram |
From: Andrej N. G. <an...@re...> - 2013-08-12 19:31:52
|
Hello! Ryan Bramantya has written on Tuesday, 13 August, at 1:54: >Hi Kevin, [^_^] >Yes :) >> Btw, I recommend to keep the attribution lines intact. >> >I'm sorry I didn't know what it (attribution lines) means The next text after 'Hello!' in this letter is something that is called "attribution line". It shows who I reply to. :) Cheers! Andriy. |
From: Ryan B. <rya...@gm...> - 2013-08-12 19:37:50
|
2013/8/13 Andrej N. Gritsenko <an...@re...> Hello Andrej [^_^], Hello! > > Ryan Bramantya has written on Tuesday, 13 August, at 1:54: > >Hi Kevin, [^_^] > > >Yes :) > >> Btw, I recommend to keep the attribution lines intact. > >> > > >I'm sorry I didn't know what it (attribution lines) means > > The next text after 'Hello!' in this letter is something that is called > "attribution line". It shows who I reply to. :) > > Cheers! > Andriy. Thanks for the informations. -- Best regards, Ryan Bram |
From: Kevin K. <kr...@kd...> - 2013-08-13 07:27:50
Attachments:
signature.asc
|
Hi, On Monday, 2013-08-12, Ryan Bramantya wrote: > Hi Kevin, [^_^] > > Yes :) > > > Btw, I recommend to keep the attribution lines intact. > > I'm sorry I didn't know what it (attribution lines) means As Andrej explained it is the line that says who wrote what in a thread. > > There is simply no such thing as "better" when it comes to licensing. > > > There is such thing. If not, there is no point for Richard Stallman to > suggest Vorbis Library licensing under BSD-like license and not under GPL > or even the Lesser GPL. Better is dependent on context on the what goals one wants to achieve, etc. Richard Stallman's goal is always to protect the four freedoms he identified as important decades ago. In your example taking away the excuse of licensing on code dealing with an open format helps the user's freedom (no data lock-in) more than ensuring all of the products using the format respect the freedoms as well. It is a trade-off, a compromise. > > Well, if we were simple media representatives than yes, that would probably > > > our view. Fortunately, as IT professionals, we have a way bigger picture > > and > > know that Linux has been a tremendous success in a lot of fields long > > before > > mobile device vendors started using it. > > Those are basically just the tip of the iceberg, the part that is visible > > by > > the uneducated population. > > The advantage of technology is not just to be enjoyed by some professionals > in a particular field, but for every class of user. We can enjoyed an > advantages of Ferrari or Duccati without needed to become a mechanical > engineer as we can enjoyed an advantages of Linux Kernel in Android without > needed to become an IT professionals. We cannot said someone as uneducated > just because they didn't know what Linux kernel was. What you say as > uneducated may be a doctor, a biologist, a lawyer, a historian, a > president, a pastor, etc. who just have no time to examine what Linux was. > Just like an IT professionals who may didn't know about *Osteoprotegerin*, > TNFRSF11B gene, *pacta sunt servanda*, history of mongol, etc. I wasn't using uneducated in terms of higher education but to categorize "not knowing about it". It is not about enjoing the benefits of something, rather the opposite. People enjoy the benefits of Linux and other Free Software without knowing that they do. They might know about it within certain limits, e.g. that Firefox is Free Software or that Android is. We as IT professionals see a greater picture, we know that it is being used in tons of devices that normal people do not even consider to be computer equipment, etc. > > Sure, if there hadn't been KHTML or if it had been permissively licensed > > then > > there would be not WebKit. Fortunately a team of dedicated engineers at > > KDE created a world class HTML render engine plus a JavaScript engine > > and licensed > > it in a way that both allowed usage in prorprietary context but also > > ensured > > that improvements would become available under the same terms as well. > > If KHTML licensed under GPL in the first place, Apple wouldn't interested > to take its source code and enhance it. That wouldn't have made sense in the first place, would it? A HTML render engine is clearly something that is used by developers rather than end users directly, hence falling under the platform consideration of the license policy. > > Obviously we at KDE (myself included) wouldn't put tons of our code under > > LGPL > > license terms if we thought it would be bad license, wouldn't we? > > From this point of view, I think we are same. I never persuade LXDE-Qt > > developers to use permissive license. I only convinced them to use LGPL > instead of GPL, both for libraries and for its native (non-3rd party) > applications. Sure, I don't have any issue with that. I just don't see what difference it would make, application code is not something anyone will link against, any modification is equally affected by LGPL or GPL license terms. > > Sure, but that isn't a licensing problem. KDE software, for example, is > > being used on operating system ranging from extremely persmissive to > > fully proprietary. > > Sometimes license can become a problem. The depreciation of GCC in FreeBSD > base system is one of the example. And I never hear a fully proprietary > operating system with copyleft component in it. KDE software is known to run on proprietary platforms such as Mac OSX or Microsoft Windows, WebKit is known to be part of Mac OSX, Apple iOS, and BlackBerry10. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring |
From: PCMan <pcm...@gm...> - 2013-08-13 08:07:49
|
On Tue, Aug 13, 2013 at 3:27 PM, Kevin Krammer <kr...@kd...> wrote: > Hi, > > On Monday, 2013-08-12, Ryan Bramantya wrote: >> Hi Kevin, [^_^] >> >> Yes :) >> >> > Btw, I recommend to keep the attribution lines intact. >> >> I'm sorry I didn't know what it (attribution lines) means > > As Andrej explained it is the line that says who wrote what in a thread. > >> > There is simply no such thing as "better" when it comes to licensing. >> >> >> There is such thing. If not, there is no point for Richard Stallman to >> suggest Vorbis Library licensing under BSD-like license and not under GPL >> or even the Lesser GPL. > > Better is dependent on context on the what goals one wants to achieve, etc. > Richard Stallman's goal is always to protect the four freedoms he identified > as important decades ago. > In your example taking away the excuse of licensing on code dealing with an > open format helps the user's freedom (no data lock-in) more than ensuring all > of the products using the format respect the freedoms as well. > It is a trade-off, a compromise. > >> > Well, if we were simple media representatives than yes, that would > probably >> >> > our view. Fortunately, as IT professionals, we have a way bigger picture >> > and >> > know that Linux has been a tremendous success in a lot of fields long >> > before >> > mobile device vendors started using it. >> > Those are basically just the tip of the iceberg, the part that is visible >> > by >> > the uneducated population. >> >> The advantage of technology is not just to be enjoyed by some professionals >> in a particular field, but for every class of user. We can enjoyed an >> advantages of Ferrari or Duccati without needed to become a mechanical >> engineer as we can enjoyed an advantages of Linux Kernel in Android without >> needed to become an IT professionals. We cannot said someone as uneducated >> just because they didn't know what Linux kernel was. What you say as >> uneducated may be a doctor, a biologist, a lawyer, a historian, a >> president, a pastor, etc. who just have no time to examine what Linux was. >> Just like an IT professionals who may didn't know about *Osteoprotegerin*, >> TNFRSF11B gene, *pacta sunt servanda*, history of mongol, etc. > > I wasn't using uneducated in terms of higher education but to categorize "not > knowing about it". > It is not about enjoing the benefits of something, rather the opposite. People > enjoy the benefits of Linux and other Free Software without knowing that they > do. They might know about it within certain limits, e.g. that Firefox is Free > Software or that Android is. > We as IT professionals see a greater picture, we know that it is being used in > tons of devices that normal people do not even consider to be computer > equipment, etc. > >> > Sure, if there hadn't been KHTML or if it had been permissively licensed >> > then >> > there would be not WebKit. Fortunately a team of dedicated engineers at >> > KDE created a world class HTML render engine plus a JavaScript engine >> > and licensed >> > it in a way that both allowed usage in prorprietary context but also >> > ensured >> > that improvements would become available under the same terms as well. >> >> If KHTML licensed under GPL in the first place, Apple wouldn't interested >> to take its source code and enhance it. > > That wouldn't have made sense in the first place, would it? > A HTML render engine is clearly something that is used by developers rather > than end users directly, hence falling under the platform consideration of the > license policy. > >> > Obviously we at KDE (myself included) wouldn't put tons of our code under >> > LGPL >> > license terms if we thought it would be bad license, wouldn't we? >> >> From this point of view, I think we are same. I never persuade LXDE-Qt >> >> developers to use permissive license. I only convinced them to use LGPL >> instead of GPL, both for libraries and for its native (non-3rd party) >> applications. > > Sure, I don't have any issue with that. > I just don't see what difference it would make, application code is not > something anyone will link against, any modification is equally affected by > LGPL or GPL license terms. This indeed makes differences. Sometimes you may want to take some code from a GPL'd application, and put that piece of code in your own library. It's not a rare case. If your lib is LGPL, you cannot reuse GPL'd code in it. Otherwise your lib will be infected and need to use GPL instead. Using a more permissive license make your code easier to utilize for others, and this is always good. The drawback, however, is you cannot reuse any infectious GPL code from other projects. We may gain more users and possibly more developers who like a more permissive license, but we lose much potentially reusable code at the same time. Making lib code LGPL is reasonable and I support the idea. Making application code LGPL is also reasonable since it's possible in the future to move some code from the app to a lib, and keep it LGPL. However, one should consider the risk that we'll not be able to reuse GPL'd code from others. In conclusion, I support the idea of: 1. libs use LGPL or MIT 2. apps can use GPL or LGPL. 3. develop new apps with LGPL if possible, and do not relicense existing GPL'd apps. 4. linking GPL and LGPL'd components is easy. Just use dbus. Calling a GPL'd program from a non-GPL one via dbus is perfectly legal and do not involve lib linking at all. It's safe for system services to be in GPL as long as it can be called via IPC. >> > Sure, but that isn't a licensing problem. KDE software, for example, is >> > being used on operating system ranging from extremely persmissive to >> > fully proprietary. >> >> Sometimes license can become a problem. The depreciation of GCC in FreeBSD >> base system is one of the example. And I never hear a fully proprietary >> operating system with copyleft component in it. > > KDE software is known to run on proprietary platforms such as Mac OSX or > Microsoft Windows, WebKit is known to be part of Mac OSX, Apple iOS, and > BlackBerry10. > > Cheers, > Kevin > > -- > Kevin Krammer, KDE developer, xdg-utils developer > KDE user support, developer mentoring |
From: Kevin K. <kr...@kd...> - 2013-08-13 08:49:01
Attachments:
signature.asc
|
On Tuesday, 2013-08-13, PCMan wrote: > On Tue, Aug 13, 2013 at 3:27 PM, Kevin Krammer <kr...@kd...> wrote: > > Hi, > > > > On Monday, 2013-08-12, Ryan Bramantya wrote: > >> > Obviously we at KDE (myself included) wouldn't put tons of our code > >> > under LGPL > >> > license terms if we thought it would be bad license, wouldn't we? > >> > >> From this point of view, I think we are same. I never persuade LXDE-Qt > >> > >> developers to use permissive license. I only convinced them to use LGPL > >> instead of GPL, both for libraries and for its native (non-3rd party) > >> applications. > > > > Sure, I don't have any issue with that. > > I just don't see what difference it would make, application code is not > > something anyone will link against, any modification is equally affected > > by LGPL or GPL license terms. > > This indeed makes differences. > Sometimes you may want to take some code from a GPL'd application, and > put that piece of code in your own library. It's not a rare case. > If your lib is LGPL, you cannot reuse GPL'd code in it. Otherwise your > lib will be infected and need to use GPL instead. Well, you always have the option of putting it into a second library and link with both. But it might be even better to check with the original authors if they are interested in working on a shared library, for the benfit of both projects. Code can usually be relicensed for that (has been done numerous times in KDE). In most case I've seen myself the extraction of application code into a library is serious work since most application code was not implemented with library considerations in mind (API and ABI stability, etc). > Using a more permissive license make your code easier to utilize for > others, and this is always good. The drawback, however, is you cannot > reuse any infectious GPL code from other projects. Foruntately most infectious code is never released under GPL, actually I have never heard of any virus being released under GPL. Those are mostly closed source. > We may gain more users and possibly more developers who like a more > permissive license, but we lose much potentially reusable code at the > same time. I don't think this would be a huge loss, it would only apply to code with authors who don't want their code to be reused. > Making lib code LGPL is reasonable and I support the idea. > Making application code LGPL is also reasonable since it's possible in > the future to move some code from the app to a lib, and keep it LGPL. > However, one should consider the risk that we'll not be able to reuse > GPL'd code from others. In applications you could. Since they are usually not something that is linked against there is no pratical difference in the two licenses. Once you look at indivudual code pieces their individual licenses kick in. > In conclusion, I support the idea of: > 1. libs use LGPL or MIT > 2. apps can use GPL or LGPL. Right, this part has served very well at KDE Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring |