Linked by Thom Holwerda on Fri 18th Jan 2008 22:33 UTC, submitted by Michael Larabel
Qt Breaking from the KDE 4.0 release event right now is word that Trolltech will be releasing Qt under the GPLv3 license. An official announcement will be made by Trolltech regarding this GPLv2 to GPLv3 license update on Monday, January 21, 2008. Additionally, KDE 4.1 is now planned for a July 2008 release.
Order by: Score:
aweseom!
by rhavenn on Fri 18th Jan 2008 22:55 UTC
rhavenn
Member since:
2006-05-12

Not a fan of the GPL, but awesome none the less. Props to Trolltech and the KDE team! Look forward to KDE 4.1.

Edited 2008-01-18 22:56 UTC

Reply Score: 2

RE: aweseom!
by eikehein on Sat 19th Jan 2008 01:13 UTC in reply to "aweseom!"
eikehein Member since:
2005-10-19

> Not a fan of the GPL, but awesome none the less.

BTW, since this is often overlooked: The fact that Qt is GPL actually does not mean that your app must be, too. Trolltech grants a rather broad exception to the GPL that allows you to use various other free software licenses, including BSD, X11, Mozilla, Eclipse, and many more:

http://doc.trolltech.com/4.3/license-gpl-exceptions.html

Reply Score: 14

RE[2]: aweseom!
by Dubhthach on Mon 21st Jan 2008 16:55 UTC in reply to "RE: aweseom!"
Dubhthach Member since:
2006-01-12

And according to the changelog for 4.3.3 the CDDL (think OpenSolaris) has been added to the list of GPL Exception
http://trolltech.com/developer/notes/changes/changes-4.3.3/?searcht...

Reply Score: 1

v2 + v3, not v2 -> v3
by eikehein on Fri 18th Jan 2008 22:56 UTC
eikehein
Member since:
2005-10-19

"GPLv2 to GPLv3 license update" is a somewhat misleading wording. The GPL v3 license option will be available in addition to GPL v2, not replace it.

Reply Score: 15

RE: v2 + v3, not v2 -> v3
by segedunum on Sat 19th Jan 2008 15:08 UTC in reply to "v2 + v3, not v2 -> v3"
segedunum Member since:
2005-07-06

"GPLv2 to GPLv3 license update" is a somewhat misleading wording. The GPL v3 license option will be available in addition to GPL v2, not replace it.


That's an important point. Qt already has many exceptions to allow Qt's usage with other software of different licenses.

Reply Score: 5

Thumbs up for Trolltech
by porcel on Fri 18th Jan 2008 22:56 UTC
porcel
Member since:
2006-01-28

Great news and brings both kde, samba and qt back in sync, which was one of the remaining sticking points.

Trolltech seems like a cool, forward-looking company that I would love to work for.

Reply Score: 11

RE: Thumbs up for Trolltech
by leos on Fri 18th Jan 2008 23:06 UTC in reply to "Thumbs up for Trolltech"
leos Member since:
2005-09-21

Trolltech seems like a cool, forward-looking company that I would love to work for.


Here's some tips to study up ;)
http://labs.trolltech.com/blogs/2007/12/11/top-code-maam-the-data-i...

Reply Score: 5

RE: Thumbs up for Trolltech
by emerson999 on Sat 19th Jan 2008 01:04 UTC in reply to "Thumbs up for Trolltech"
emerson999 Member since:
2007-12-08


Trolltech seems like a cool, forward-looking company that I would love to work for.


I read their blogs, about how interesting and groundbreaking some of their code is and instantly want to work there. I think about how much I love their documentation, and how well done it is, and find the feeling fading in a flood of documentation flashbacks.

Reply Score: 2

RE[2]: Thumbs up for Trolltech
by PlatformAgnostic on Sat 19th Jan 2008 10:35 UTC in reply to "RE: Thumbs up for Trolltech"
PlatformAgnostic Member since:
2006-01-02

I don't understand. Do you mean that you'd mind writing the documentation, or is there some other problem?

I think good documentation shows a certain pride in your work (of course modulo the demand from bosses and the outside to do more other work).

Reply Score: 2

Whew
by leos on Fri 18th Jan 2008 22:57 UTC
leos
Member since:
2005-09-21

Thank god. This enables KDE to switch to GPLv3, which means it can link to stuff like new version of Samba. I was afraid that if Trolltech didn't allow v3, it would shut KDE out of integrating with any GPL3 software.

Reply Score: 7

RE: Whew
by PlatformAgnostic on Sat 19th Jan 2008 10:36 UTC in reply to "Whew"
PlatformAgnostic Member since:
2006-01-02

Huh? OS X links to Samba and definitely isn't GPL3!

I think one of us has a misconception of what's allowed and disallowed (it could be me).

Reply Score: 1

RE[2]: Whew
by KugelKurt on Sat 19th Jan 2008 14:57 UTC in reply to "RE: Whew"
KugelKurt Member since:
2005-07-06

Huh? OS X links to Samba and definitely isn't GPL3!
Mac OS X doesn't link to Samaba and the Samba version included with OSX is an older GPLv2 release.

Reply Score: 5

It's official
by superman on Fri 18th Jan 2008 23:26 UTC
superman
Member since:
2006-08-01
KDE4.1
by Sabz on Fri 18th Jan 2008 23:57 UTC
Sabz
Member since:
2005-07-07

KDE4.1 release to early i think, should of been a 9 month wait for it, makes you wonder how stable/polished 4.1 will be

Reply Score: 0

RE: KDE4.1
by rhavenn on Sat 19th Jan 2008 00:14 UTC in reply to "KDE4.1"
rhavenn Member since:
2006-05-12

You sound just like Bender ;) Seriously though, I hope that's a Troll. The base foundation and libraries are complete. The devs can now focus on bug fixes on those and then focus on application building / porting. I don't think July is too unrealistic, but it will probably slide a month or so.

Reply Score: 3

RE[2]: KDE4.1
by Sabz on Sat 19th Jan 2008 00:32 UTC in reply to "RE: KDE4.1"
Sabz Member since:
2005-07-07

You sound just like Bender ;) Seriously though, I hope that's a Troll. The base foundation and libraries are complete. The devs can now focus on bug fixes on those and then focus on application building / porting. I don't think July is too unrealistic, but it will probably slide a month or so.

i am bender ;) i hope KDE4.1 is much better than its 4.0 release or the KDE team will cop lots of flac, we'll soon see if its unrealistic or not when they release it, but right now im in no great rush to use 4.0 release

Reply Score: 1

RE[3]: KDE4.1
by smitty on Sat 19th Jan 2008 01:17 UTC in reply to "RE[2]: KDE4.1"
smitty Member since:
2005-10-13

I'll be happy if 4.1 can get feature parity with the 3.5 series, which I think is mostly possible by July. We'll see.

I think the minor point releases each month might end up having big Plasma updates in them, because they were talking about wanting a 4.1 release in April/May.

Edited 2008-01-19 01:20 UTC

Reply Score: 3

RE[4]: KDE4.1
by Sabz on Sat 19th Jan 2008 06:03 UTC in reply to "RE[3]: KDE4.1"
Sabz Member since:
2005-07-07

I'll be happy if 4.1 can get feature parity with the 3.5 series, which I think is mostly possible by July. We'll see.

I think the minor point releases each month might end up having big Plasma updates in them, because they were talking about wanting a 4.1 release in April/May.

but i rread a lot of KDE Fanboys w over at KDE blogs wanted the KDE4.1 release a 9 month apart from the 4.0.0 release , lets hope there isnt anything major that goes into the 4.0.x releases otherwise i cant see fedora9 having KDE4 in its final release if its gonna break

Reply Score: 0

RE: KDE4.1
by da_Chicken on Sat 19th Jan 2008 09:14 UTC in reply to "KDE4.1"
da_Chicken Member since:
2006-01-01

If you think 4.1 won't be stable/polished enough for you, you can always wait for 4.2, which should come out six months after 4.1.

Reply Score: 8

RE[2]: KDE4.1
by Sabz on Sat 19th Jan 2008 10:51 UTC in reply to "RE: KDE4.1"
Sabz Member since:
2005-07-07

If you think 4.1 won't be stable/polished enough for you, you can always wait for 4.2, which should come out six months after 4.1.

i think 4.2 will be the best one to date to use

OffTopicwho made this board? you can only edit a Previous Post you posted, older post's you cannot edit

Edited 2008-01-19 10:54 UTC

Reply Score: 0

RE[3]: KDE4.1
by stestagg on Sat 19th Jan 2008 12:07 UTC in reply to "RE[2]: KDE4.1"
stestagg Member since:
2006-06-03

V3 was made by Eugina IIRC, v4 by Adam.

You can't edit posts after a certain time/only last post on purpose. This is to prevent abuse. I'm sure you can work out why this is a goo thing

Reply Score: 2

Well there goes my idea.
by theTSF on Sat 19th Jan 2008 03:14 UTC
theTSF
Member since:
2005-09-27

And I wanted to make a DRM protected media player.

Reply Score: 2

RE: Well there goes my idea.
by borker on Sat 19th Jan 2008 04:47 UTC in reply to "Well there goes my idea."
borker Member since:
2006-04-04

i know this was just a joke, but I can't help myself...

there is nothing in the gplv3 that stops you implementing DRM. Nothing.

I'm guessing this was meant to refer to the aspect of gplv3 that seeks to prevent a third party from commandeering the rights (notably to study and run gplv3 licensed code) the gplv3 seeks to protect, through the use of digital locks

Edited 2008-01-19 04:48 UTC

Reply Score: 3

PlatformAgnostic Member since:
2006-01-02

It seems like a practical reality of DRM software, though, that it will violate the desires of GPL3 advocates (and perhaps any anti-tivo clause in the license). I am not an expert in DRM crypto algorithms or anything along those lines, but it seems to me that you can make a modification of the decoder and get the unencrypted stream if you can arbitrarily change the software. The only way to avoid this is multi-stage decoding with the last unencryption done on the hardware itself. But I can think of some issues here as well. It's a lot easier to make DRM work when you ensure that the decoder and lower layers of the OS do not work against the desired usage policy and sign the relevant software so that it cannot be modified.

Edited 2008-01-19 10:45 UTC

Reply Score: 2

RE[3]: Well there goes my idea.
by lemur2 on Sat 19th Jan 2008 11:09 UTC in reply to "RE[2]: Well there goes my idea."
lemur2 Member since:
2007-02-17

It seems like a practical reality of DRM software, though, that it will violate the desires of GPL3 advocates (and perhaps any anti-tivo clause in the license). I am not an expert in DRM crypto algorithms or anything along those lines, but it seems to me that you can make a modification of the decoder and get the unencrypted stream if you can arbitrarily change the software. The only way to avoid this is multi-stage decoding with the last unencryption done on the hardware itself. But I can think of some issues here as well. It's a lot easier to make DRM work when you ensure that the decoder and lower layers of the OS do not work against the desired usage policy and sign the relevant software so that it cannot be modified.


In order to write DRM software you have a number of choices:
(1) write your DRM application as proprietary code. To do that for a KDE target requires only that you pay Trolltech for a developer license, and you avoid statically linking to any other GPL'ed code. LGPL is OK, and dynamic linking is OK.

(2) write your DRM application as open-source code. This means that you do not have to pay Trolltech for a developer license, but it becomes trickier to write your application. If you write your application as BSD code, then anyone can steal it from you. If you write it as GPL'ed code, then you must not apply the DRM to the code itself. Therefore, you must put all of the DRM cleverness into the decryption key, which you c must keep a secret. In that way, anyone downstream removing your decryption will also remove access to DRM'd content.

Reply Score: 3

PlatformAgnostic Member since:
2006-01-02

Who cares if someone steals the decoder code from you? The money here is to be made from the content that is being encrypted. I'm sure the AACS-LA would release their code in a heartbeat if they could get foolproof DRM on client machines. The money to be made for the studios is from the content, not the software. For the producers if the DRM software, the financial payoff is through access to the blessed keys that go out to all computers.

I'm pretty bothered by your claim of the GPL preventing someone from "stealing" code by using it in a proprietary product. As far as I can tell, Google and anyone else running a large public linux server utility is "stealing" your code every day because they don't have to publish source to their modifications or additions to their kernel. If you're so worried about people stealing the precious source, you should be an advocate of closing the server-side loophole in the GPL.

I don't want anyone to take this to mean that I'm against the GPL per se. I agree with Butters in that it's a good means of damping the prisoner's dilemma that would otherwise stop two software competitors from contributing to a shared codebase. I'm just against the class of GPL advocates who believe that everything ought to be either under the GPL or compatible with it.

Edited 2008-01-19 11:34 UTC

Reply Score: 3

RE[5]: Well there goes my idea.
by lemur2 on Sat 19th Jan 2008 14:04 UTC in reply to "RE[4]: Well there goes my idea."
lemur2 Member since:
2007-02-17

Who cares if someone steals the decoder code from you? The money here is to be made from the content that is being encrypted. I'm sure the AACS-LA would release their code in a heartbeat if they could get foolproof DRM on client machines. The money to be made for the studios is from the content, not the software. For the producers if the DRM software, the financial payoff is through access to the blessed keys that go out to all computers.


Understood. If you are not bothered about someone "stealing" your code then any sort of permissive license is OK. Note however that if you are not bothered bothered about someone "stealing" your code, then a proprietary license for it makes absolutely no sense.

I'm pretty bothered by your claim of the GPL preventing someone from "stealing" code by using it in a proprietary product. As far as I can tell, Google and anyone else running a large public linux server utility is "stealing" your code every day because they don't have to publish source to their modifications or additions to their kernel. If you're so worried about people stealing the precious source, you should be an advocate of closing the server-side loophole in the GPL.


"Stealing" code in this context would mean taking some developers work that was released with a permissive BSD-style license, and then including it in a larger commercial work and charging end users for it. You are not so much "stealing" the actual code (because the original author permitted you), but rather you are taking the effort of the original coders and giving nothing in return, yet you are profiting from still other people. Not nice.

"I don't want anyone to take this to mean that I'm against the GPL per se. I agree with Butters in that it's a good means of damping the prisoner's dilemma that would otherwise stop two software competitors from contributing to a shared codebase. I'm just against the class of GPL advocates who believe that everything ought to be either under the GPL or compatible with it.


I am not one who would come anywhere close to such a position.

My own position is strictly this: if you intend to charge people for a software product, then do your own work in creating that product, or alternatively ensure that you compensate the original authors for their work in your product.

If you write your own code ... then it is your code so license it however you please.

If you include other code in your product, then come to an agreement with the authors of that code. If the code is GPL, then you must either make your own product GPL since it includes other GPL code, or you must obtain a separate license from the original authors.

In the case of Qt from Trolltech ... this is exactly what they ask. If you include Trolltechs Qt code in your product, then you must either release your product as GPL or you must pay Trolltech for a developer license for Qt.

I have no problem at all with that.

I have no problem with developers writing closed-source applications in general ... as long as they write their own code.

The ONLY potential problem is including open source code to try to make a closed-source proprietary product (that is, not writing your own code). Even that is OK, as long as you follow the copyright rules and get the required permissions from the original authors.

Note that Google are NOT "including open source code to try to make a closed-source proprietary product" and then selling that product to other parties. So I have no problem with what Google does, either. The GPL, after all, does say that you may USE (that is, run it and/or modify it for your own use) the code however you wish. The GPL only comes into effect when you re-distribute (or facilitate redistribution of) GPL'ed source code.

Reply Score: 3

RE[3]: Well there goes my idea.
by borker on Mon 21st Jan 2008 19:50 UTC in reply to "RE[2]: Well there goes my idea."
borker Member since:
2006-04-04

weather the reason for wanting to lock up software is to provide a 'better' DRM or anything else, it goes against the idea of being able to modify and run GPL'd code.

If an author wants to release their code and ensure that the rights of others to modify and run that code are protected and not taken away through a back door like 'tivoization' (or to my mind, the far more potentially dangerous 'trust computing' platforms) then GPL3 is a stronger choice than GPL2.

Now, like all code, if someone wants to incorporate my code into a product and the 'price' I've set on the use of my copyrighted work is that certain end user rights are protected, then I expect that price to be paid, no differently than would any software supplier who charged $ for a software license. If someone takes my code and adheres to the letter of the license but, to mind, doesn't 'pay' me the price I'm charging (in this case, end use rights) then I'm going to look to make sure that that can't happen in the future. Which is basically how the anti-digital locks part of GPL3 came about.

You, me, the DRM implementers, Linus, Trolltech, the BSD guys and everyone else in the world may (almost certainly do) all have different ideas on what it is they want to receive in recompense for their effort and what they think makes up a good license to build upon. GPL3 is one choice among many and like all others, involves certain pros and cons for both those seeking to license their work under it and those seeking to use work licenses under it.

Reply Score: 2

New KDE license policy
by KugelKurt on Sat 19th Jan 2008 11:09 UTC
KugelKurt
Member since:
2005-07-06

A week ago the KDE project also adopted a new license policy. Now every bit of source code submitted into KDE's SVN has to be GPLv3 compatible.
Details can be found at http://kdedevelopers.org/node/3201 and http://techbase.kde.org/Policies/Licensing_Policy

Most old code that was GPLv2-only in the past has already been re-licensed. The code not re-licensed is from people who could not have been reached yet -- with the exception of Cyrille Berger who is the only one who refuses to open up the licensing of his code. http://techbase.kde.org/Projects/KDE_Relicensing#Current_Reply_List
I hope his resusal doesn't prevent the adoption of MS Exchange capability for Kontact/Akonadi. http://www.kdedevelopers.org/node/2881

Reply Score: 5

RE: New KDE license policy
by lemur2 on Sat 19th Jan 2008 11:18 UTC in reply to "New KDE license policy"
lemur2 Member since:
2007-02-17

A week ago the KDE project also adopted a new license policy. Now every bit of source code submitted into KDE's SVN has to be GPLv3 compatible.

I hope his resusal doesn't prevent the adoption of MS Exchange capability for Kontact/Akonadi. http://www.kdedevelopers.org/node/2881


Akonadi shouldn't be a problem.

From the text Submitted by brad hards on Sat, 07/14/2007
"Based on my understanding, that means that KDE4 can't use anything from Samba4 (or Samba3.2+) and Qt4 in the same application."


That was when Samba 4 was GPLv3 and Qt was GPLv2 only.

Now that Qt4 is GPLv3, all is sweet again.

Edited 2008-01-19 11:19 UTC

Reply Score: 5

RE[2]: New KDE license policy
by KugelKurt on Sat 19th Jan 2008 11:38 UTC in reply to "RE: New KDE license policy"
KugelKurt Member since:
2005-07-06

Now that Qt4 is GPLv3, all is sweet again.

I was referring to older KDE code by Berger and a few others that's still GPLv2-only despite the Qt license change.

Reply Score: 2

RE[3]: New KDE license policy
by boudewijn on Sat 19th Jan 2008 12:02 UTC in reply to "RE[2]: New KDE license policy"
boudewijn Member since:
2006-03-05

Cyrille's lgplv2 code is all in Krita plugins -- the code in pigment and krita itself is gplv3 compatible. His current understanding is that lgplv2 plugins can always be used with any application, even if it as a GPLv3-only application. If that understanding turns out to be wrong -- and I wouldn't know -- then he will have to move his plugins outside the KDE source repository and we won't be able to release his plugins with Krita or KOffice.

Reply Score: 5

RE[4]: New KDE license policy
by lemur2 on Sat 19th Jan 2008 14:13 UTC in reply to "RE[3]: New KDE license policy"
lemur2 Member since:
2007-02-17

Cyrille's lgplv2 code is all in Krita plugins -- the code in pigment and krita itself is gplv3 compatible. His current understanding is that lgplv2 plugins can always be used with any application, even if it as a GPLv3-only application. If that understanding turns out to be wrong -- and I wouldn't know -- then he will have to move his plugins outside the KDE source repository and we won't be able to release his plugins with Krita or KOffice.


According to the www.gnu.org website, Cyrille is correct in his understanding.

http://www.gnu.org/philosophy/license-list.html
" GNU Lesser General Public License (LGPL) version 2.1

This is the previous version of the LGPL: a free software license, but not a strong copyleft license, because it permits linking with non-free modules. It is compatible with GPLv2 and GPLv3."


I hope this helps.

Reply Score: 5

RE[3]: New KDE license policy
by lemur2 on Sat 19th Jan 2008 13:40 UTC in reply to "RE[2]: New KDE license policy"
lemur2 Member since:
2007-02-17

"Now that Qt4 is GPLv3, all is sweet again.

I was referring to older KDE code by Berger and a few others that's still GPLv2-only despite the Qt license change.
"

I know you were.

You also said this: "I hope his resusal doesn't prevent the adoption of MS Exchange capability for Kontact/Akonadi."

I was pointing out that that "older KDE code by Berger and a few others" has nothing to do with Akonadi, Kontact, Exchange or Samba4.

Reply Score: 5

My only concern is over opensuse 11.0.
by REMF on Sat 19th Jan 2008 12:18 UTC
REMF
Member since:
2006-02-05

as a big fan of suse and kde i would like a default kde 4.1 suse release before 2Q 2009.

Reply Score: 2

Erunno Member since:
2007-06-22

So what you basically want is a patched version of KDE 4.0 with all the features planned for 4.1 still missing? Shortering the development cycle doesn't make the missing features materialize any quicker.

Reply Score: 4

REMF Member since:
2006-02-05

no, i would have liked opensuse to tailor the release of 11.0 to the arrival of KDE 4.1.

Reply Score: 2

Erunno Member since:
2007-06-22

no, i would have liked opensuse to tailor the release of 11.0 to the arrival of KDE 4.1.


Fair enough.

Reply Score: 1

7 months !!!!
by antwarrior on Sat 19th Jan 2008 18:08 UTC
antwarrior
Member since:
2006-02-11

:-0 !!!!
i know,i am man-child,and so are you. Kudos to Trolltech for alway staying current with the OSS world and being a responsible beneficiary. Now back to my moan. let me moan. I need my KDE fix. 7months. Oh well. So much for being a spectator in this one, need to go the drawer and dust out my coding gloves, my bug reporting manual and start partioning drives.... just when you think your transformation from the life as a volunteer in the free OSS world to moaning customer is complete, they do THIS!!!! :-)

Reply Score: 2

Tentative Feature Plan for 4.1
by elsewhere on Sat 19th Jan 2008 21:05 UTC
elsewhere
Member since:
2005-07-13

Sebastian posted recently in his blog with a pipeline of features that are planned to see light-of-day in 4.1:


* Mac Port
* Windows Port
* OpenSolaris Port
* Plasma with widgets on canvas, makes things like layouting much easier, and generally integrating widgets into plasmoids
* Webkit in plasma
* Apple dashboard widgets support in Plasma
* Decibel VOIP and real-time communication framework
* Dragon Player multimedia player
* More polished kopete
* KDevelop and KDevplatform
* KDE-PIM, based on Akonadi
* GetHotNewStuff2 / DXS
* Plasmagik plasma packages and add-on creator
* Lots of smaller features


In addition, he goes on the mention the additional benefits simply from utilizing Qt 4.4 (phonon backends, improved svg and widget performance, etc.)

He does include the prudent disclaimer that this isn't an official list, nor is there a concrete guarantee it will all appear, but does point out that most of the work has already been done but couldn't be finalized in time for 4.0

Anyways, thought it may provide some idea of where the devs are going with 4.1, other than making it "better".

Link to his blog is http://vizzzion.org/?blogentry=804

Reply Score: 6

RE: Tentative Feature Plan for 4.1
by WereCatf on Sat 19th Jan 2008 21:39 UTC in reply to "Tentative Feature Plan for 4.1"
WereCatf Member since:
2006-02-15

All this talk about KDE4 has piqued my interest and I read a little about it on the KDE website. All the work they've done to improve those frameworks seem pretty impressive and will probably prove very useful. I kinda would like to try programming something myself too just to try them out ;) Too bad though that I probably won't be migrating to KDE, I just simply like the GTK+/GNOME look-and-feel. And atleast that default theme would stop me from migrating: unless I could find some nice theme to replace it with I would just get a migraine from looking at that ;)

Reply Score: 2

Momentum Towards GPL3
by RIchard James13 on Sun 20th Jan 2008 09:08 UTC
RIchard James13
Member since:
2007-10-26

For each large project that moves from GPL2 to GPL3 their is more incentives for smaller developers to make the switch.

I haven't switched yet because I haven't taken the time out to read up on all the differences, but if everyone else is using it then by deduction we can infer that either they see nothing wrong with it or they are all fools. I would tend to discount the second possibility when large projects and corporations make the switch.

Reply Score: 1