OSNews

> 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...

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

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).

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.

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

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

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.

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 www.gnu.org website, Cyrille is correct in his understanding.

http://www.gnu.org/philosophy/license-list.html


I hope this helps.

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.

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.

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