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.
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
> 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
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…
“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.
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.
Here’s some tips to study up
http://labs.trolltech.com/blogs/2007/12/11/top-code-maam-the-data-i…
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.
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).
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.
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).
Mac OS X doesn’t link to Samaba and the Samba version included with OSX is an older GPLv2 release.
http://trolltech.com/company/newsroom/announcements/press.2008-01-1…
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
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
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
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
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
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
And I wanted to make a DRM protected media player.
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
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
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.
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
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.
“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 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.
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.
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
Akonadi shouldn’t be a problem.
From the text Submitted by brad hards on Sat, 07/14/2007
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
I was referring to older KDE code by Berger and a few others that’s still GPLv2-only despite the Qt license change.
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 http://www.gnu.org website, Cyrille is correct in his understanding.
http://www.gnu.org/philosophy/license-list.html
I hope this helps.
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.
as a big fan of suse and kde i would like a default kde 4.1 suse release before 2Q 2009.
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.
no, i would have liked opensuse to tailor the release of 11.0 to the arrival of KDE 4.1.
Fair enough.
:-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!!!! 🙂
Sebastian posted recently in his blog with a pipeline of features that are planned to see light-of-day in 4.1:
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
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 
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.