Qt Becomes LGPL 828
Aequo writes "Qt, the highly polished, well documented, modern GUI toolkit owned by Nokia, will be available under the LGPL starting with version 4.5! It was previously only mainly available under the GPL and a commercial license. Selling licenses was an important part of Qt under Trolltech as it was the company's main source of income, but Trolltech is a fruit-fly compared to Nokia, who want to encourage and stimulate the use of Qt Everywhere [PDF]. This is fantastic news for all commercial developers looking to create cross-platform applications without the need to buy a $4950 multi-platform license per developer."
Large uptick in Qt usage? (Score:5, Interesting)
The only complaint I've seen before about Qt is that it's too expensive for proprietary apps, and that's not an issue anymore. I won't be surprised to see a large uptick in Qt usage now, and that's a big plus for cross platform apps, as Qt is quite portable.
Wow, great news (Score:5, Interesting)
Over the years I have said many times that TrollTech should have lowered their prices considering things like the Apple Developer's kit and MSDN are significantly cheaper for more functionality.
I have been in need of a good GUI toolkit for years. I have used just about all of them but for my own projects I either use the native toolkit of the OS I'm working on or FLTK for cross-platform stuff. Qt is much more functional than FLTK though with all their SQL and other utility classes. This is really cool. I bet Qt is now going to become the defacto GUI toolkit for everything.
I wonder how long until someone makes a Qt version of GNOME (ha, I can't imagine how much work that would take). You could start with making a Qt version of The GIMP.
Comment removed (Score:3, Interesting)
Re:time to port gnome! (Score:5, Interesting)
Since GNOME is currently brainstorming over how to make GNOME 3, I'd say this announcement come right on time.
Let's focus on the applications and not on reinventing the wheel.
The toolkit feud has gone on for far too long. Let's share a common toolkit. GNOME is using more Vala and C#/Mono these days and Vala/C#/Mono on top of Qt would make gnomies very happy I think.
Re-implementing GNOME on top of Qt with the traditional focus on HIG should not be all that hard.
This is an exiting opportunity for GNOME. I wonder if they'll embrace it and make the Linux desktop go forward.
Die Gnome (Score:3, Interesting)
Perhaps now we can finally get enough momentum to end this Gnome\KDE battle and get KDE to win so we can settle on ONE desktop environment so we can get back to writing 40 different window managers.
QT + KDE = 1 Desktop Standard Linux (hell even Windows) folk can get behind.
Gnome + KDE = Goblin Desktop (You can thank me for coming up with that name
Merge the teams, move forward with KDE and lets get Linux on the desktop in earnest.
Re:Large uptick in Qt usage? (Score:4, Interesting)
The only complaint I've seen before about Qt is that it's too expensive for proprietary apps
Then you've not been listening. Many don't like the noteworthy long start up times of Qt apps compared to say Gtk. Many don't like the need for obtuse tools like SIP. I know for a while they were working to address the long start up times I've not followed where that went. Perhaps it's no longer an issue.
Frankly, the API of Qt make Gtk look like a pile of vomit, but simple fact is, Qt is not the perfect GUI programming environment.
Excellent news! (Score:4, Interesting)
Excellent news!
And a sensible move - the best way for any technology to become a standard (defacto or otherwise) is for it to be freely available and demonstrably good.
Now this is both we can predict swift adoption of it. Some firms may view Linux as a hobby, but even that is changing - my new job I started last week has two Ubuntu PCs in this very room I am typing from.
Strategy fail (Score:5, Interesting)
Of course, porting GNOME would take so long that people would forget that GNOME even exists. The unfortunate reality is that this split will only be resolved when either GNOME and all of the associated GTK applications die, or KDE and its associated applications die (unfortunately, that would mean a loss of K3B, one of the applications that made open source desktops usable for non-technical users).
Kills any idea of using Qt in our products (Score:0, Interesting)
However, the company has a strict policy of no LGPL or GPL software. Nothing more restrictive than BSD or Apache when it comes to using free software. So, any talk of using Qt would have been a non-starter.
PyQt? (Score:5, Interesting)
Finally! (Score:4, Interesting)
I considered QT when I was looking for a good GUI for an open source project I was considering, but ended up rejecting it on licensing agreements. It has actually gotten better licensing twice since then, and now I would actually choose it.
That project, sadly, never happened because I never found a GUI toolkit I thought would do what I needed. How many other projects were similarly stalled like this?
This is indeed good news.
Jump onboard Firefox and Adobe! (Score:5, Interesting)
With this development, I hope Firefox and Adobe developers will jump on board...fast. I would also like to see the folks at OpenOffice.org on board the QT bandwagon as well. The interfaces I see on Openoffice and Adobe's PDF reader would look better with QT in my opinion.
Re:Strategy fail (Score:3, Interesting)
Re:Strategy fail (Score:5, Interesting)
Which is just not possible. Where is the CD burning program in GNOME that beats K3B? Where is the music player that beats Amarok? In the other direction, where is the office suite that beats OpenOffice.org? You cannot avoid mixing GTK and Qt apps on a desktop without hurting yourself.
"Honestly, I have no trouble using mixed apps on the same desktop."
Just three days ago at FUDCon, I saw someone try to use KGPG on their GNOME desktop. He had localized GNOME in Dutch, and when KGPG pops up...everything was in English. The localization settings are stored in different places, which is a problem that goes beyond "installing themes to make it look the same." There is also the failure to have OLE across Qt and GTK, which has so far only been solved by disparate hacks in specific applications, and only works for certain cases. The copy and paste problems being solved was a good thing, but that is only one of many issues that arise from mixing GTK and Qt apps on a single system.
Re:time to port gnome! (Score:2, Interesting)
Furthermore, both Gnome and KDE could share many core underlying technologies if this happened.
If I recall, Gnome was created because people didn't feel the Qt/KDE license was "Free" enough. Oddly enough, Qt and KDE are the "free" ones now, where as Gnome is now firmly entrenched with Mono.
Even Mark Shuttleworth has said there is something to said for a Gnome built on Qt. It would be faster, use less memory, and they could start on it tomorrow. Redesigning a GTK+ 3.0 from the ground up would take time, and slow down Gnome.
Qt ships with a Clearlooks engine. Please, please someone make this happen.
GTK is not the target... (Score:5, Interesting)
I have a hunch Nokia is looking at XCode and Apple instead. After all, the main battle for them is in the mobile market, and Apple made a big deal about the iPhone being based on OS X. So this is a bid to win over the talented developers.
QT is available on more platforms, true, and it always has been. Still, XCode was free for anyone with a Mac, and the developer kits for the iPhone only required that you own a Mac and that you registered as a developer.
Re:Large uptick in Qt usage? (Score:4, Interesting)
Re:Large uptick in Qt usage? (Score:4, Interesting)
GTK, wxWidgets, XForms, V, Motif, MFC, Borland VCL, Visual Basic, Swing, AWT, GNUStep and Qt,
I've used most of those, although NEXTStep rather than GNUStep. I used Qt very heavily in the late 90's and early 2000's, but moved to wxWidgets a few years ago, in part due to Qt's licensing costs, and now never plan to go back.
I've found wx easy to use, well-documented, well-supported across platforms and languages (using wxPython heavily at the moment as well as C++) and generally lighter weight than Qt.
The things wx "lacks" are things that I don't need and don't want anyway, like a nice GUI builder--although arguably BOAConstructor fits the bill for wxPython, and I guess maybe DialogBlocks for C++. I use code generators for all my UI coding, which gives me far more flexible and robust layouts much more rapidly than a GUI builder can.
Re:time to port gnome! (Score:3, Interesting)
"Not using C++" is still an argument for GTK.
Re:Jump onboard Firefox and Adobe! (Score:5, Interesting)
Re:time to port gnome! (Score:5, Interesting)
Qt supports more than just Windows/Linux/Mac OSX... It also supports embedded applications (Qt/Embedded - used for Qtopia, which assumes nothing more than a framebuffer graphics interface), and most recently also Windows CE.
I think Google's decision to go with their own graphics API for Android is looking very much like "not invented here". The Qt API is excellent (I've been using the free version for years), and it's available pretty much everywhere. Now with LGPL licensing, any remaining objection has pretty much disappeared. Qt Jambi (the Java API for Qt) would be perfect for Android.
Re:Strategy fail (Score:5, Interesting)
That is the chance and duty of freedesktop.org. Combining the parts that are common and the platforms can agree upon. Defining the standards (like trash, cache, drag+drop, etc.).
It is getting better and better (e.g. I think KDE+GNOME both use DBUS now? ), some services/libs (NetworkManager) are already commonly used.
What I'd really like to see is a common password storage.
Re:Strategy fail (Score:4, Interesting)
What I'd like to see is a decoupling of basic stuff like dialogs from the toolkit.
the idea is that filechoosers, print dialogs and other stuff like that should be separate applications, that comunicates with the calling app using a standard way, adopted by all.
this way GTK, QT, GNUStep, etc. apps. all would have _AT LEAST_ those items in common. that'll make the user able to use muscular memory to use those elements no matter wich toolkit was used to build the app, something that we don't have right now.
Re:Excellent news! (Score:3, Interesting)
Some firms may view Linux as a hobby
I am working on a Qt application right now. Previously, we planned to release only for Windows since each additional platform cost extra in licensing fees. Now, we can support Linux and OS X as well.
That's cool... (Score:1, Interesting)
I guess that's cool.
But I have to admit. I'm not a big fan of Qt. I kind of see it as an oversized, bloated library. I suppose someone could probably argue reasons for every class and functionality that's present in the library, but some of the things in Qt I look at and get turned off. When there's good cross-platform libraries present for things, I don't really get the reasoning behind rewriting those things.
I know most people look at Qt as a GUI library, but I look over everything, and it's so much more than that. And yet, a lot of those other pieces, I've spent a lot of my programming experience learning things that are just as good and at times, in my personal opinion, better than what Qt offers for the same. Even pieces of the C++ standard that I'm sure Qt added on extra functionality in their equivalent, but it gets really hard for me to reason not using the standard libraries that are nearly (nearly because it does depend on what the implementation of the standard libraries on the system supports--not a problem if each platform goes for compliance with the standard, which I believe most go at least pretty damn close) guaranteed to work anywhere the standard libraries are present.
Just for example, I read they now have a whole parallel/multi-threading library going. But I sit here and ask myself with that over and over, what's wrong with boost::thread (which is going to be included in the C++0x standard anyway)? Even more, there's OpenMP for even further niceness. And having plenty of experience to the point that boost::thread comes naturally to me and OpenMP is getting more and more natural, why the hell would I want to go through learning a whole new set of libraries to do the same thing? But at the same time, why would I want to link against 2-3 libraries that do the same thing?
I guess someone could also argue the niceness of having it all in one place, as well. But I find multiple libraries each focused on their specific task much easier to sift through for documentation and examples than the crap of a library that tries to be everything. The flip-side being when you use one thing and another library you want to use uses something different (which I don't run into often enough for it to be a serious problem, honestly).
I wrote a library in C++ that any time I find something (other than GUI, as that's a whole mess of it's own in my opinion) that is difficult to implement for cross-platform purposes due to the different platforms, I write a little class which I can just take out and put in any of my apps. Of course, it also has a few other things like a couple classes such as a multiple-read, single-write access interface (using boost::mutex, the const volatile keywords, and some const_cast action), but it has maybe 4 other things, which mostly compose of other cross-platform libraries that left just a few capabilities I ended up needing out (like Sleep, though I can't say I'm aware of a good Windows equivalent to nanosleep yet, and it kinda makes my code on Windows not as nice when I'm sleeping in milliseconds but meaning to sleep in microseconds or nanoseconds, meaning dividing by 1000 or 1000000).
That's one thing I do like about GTK, though I am annoyed by so many other pieces of it. At least, a lot of what is implemented in GTK and glib isn't really there a million times over already. Partly just because they're using C, which doesn't have some of the nice stuff in the standard already, and doesn't have Boost ;). But I don't feel like I'm having to justify to myself either learning a whole new thing I've already learned multiple other alternatives to or linking to a whole 'nother library to do something that's already present in another library I'm linking against.
That's my only gripe about "Hopefully we can get rid of GTK now!" Otherwise, I'm actually happy about this. I do like the GPL, but for libraries and such things, I always felt the LGPL was the better choice (in some cases, I even prefer BSD or MIT type licenses over that, but whatever). So, despite my gripes about Qt, I view this as a good thing.
Re:Constrained by the LGPL? (Score:2, Interesting)
Presumably, if folks want to make changes to the libraries themselves, they'd need to make those changes public when redistributing the binaries.. Sort of defeats the purpose if you ask me, but I'm sure there's potential customers who would demand commercial licenses for dopey legal reasons, and perhaps they'll only offer support on the non-LGPL?
Re:time to port gnome! (Score:3, Interesting)
Thanks for the clarification. I recall reading that years back, but I didn't recall the specifics.
GTK wasn't designed to power a full desktop platform originally. Gnome is at a crossroads where they either completely rewrite GTK, they bandage it while trying to preserve some compatibility, or they consider a move to Qt.
The single largest objection I hear from Gnome devs about Qt isn't that Qt isn't a good toolkit, but rather that they prefer to code in C. Color me ignorant, but aren't there language bindings that allow you to use Qt in C?
I'd really love to see a proof-of-concept simple app like GEdit converted to Qt, but I assume that would also mean porting the Gnome libs to Qt first.
Re:Yeah but KDE doesn't work. (Score:3, Interesting)
Screwed up kernel... BTW, what distro are you running, and what version of KDE 4.x did you run?
I am running Ubuntu Hardy Heron with nVidia drivers. The problem was the KDE, and I think it was 4.0, went and updated my kernel. This in turn hosed my nVidia drivers for some god aweful reason and brought down my whole desktop.
I used to use OpenSuse before Ubuntu and that was where I really liked KDE the best. It was nice because under OpenSuse you could switch between KDE and Gnome quite effortlessly and this has never really worked under Ubuntu. However, there's a lot that I do like about Ubuntu, in particular, the whole package management system is out of this world good compared to OpenSUSE when I used it, and honestly, I think Gnome desktop just looks a lot more polished even though KDE has a lot of features to it.
Re:Strategy fail (Score:3, Interesting)
AFAIK it's only using GTK to graphically draw the widgets, not to do layout or things like that.
Re:Nokia did not purchasee Trolltech for reselling (Score:3, Interesting)
http://en.wikipedia.org/wiki/HTML_5#Ogg_controversy [wikipedia.org]
I realize that Nokia bought Trolltech for Qtopia. Nokia is now trying to push a mobile GTK platform while owning the Qt platform. I did think it was a really smart move to give Nokia n810 tablets to KDE devs. Then the KDE devs worked on getting KDE 4 to work on the n810. Nokia could easily ship a full KDE 4 based desktop on future smart phones and tablets.
Re:Strategy fail (Score:4, Interesting)
Re:It's official... (Score:4, Interesting)
...no reason for Gnome to exist anymore! ;)
KDE is Qt-based but with a lot of CRAP added on top, just for desktop integration reasons, much like GNOME on top of GTK+. I do not need GNOME to run many GNOME apps; this is not so much the case with KDE (at least with version 3).
I love Qt 4 by itself. It's stylish, looks good on Windows and Mac, very portable and a VERY easy API IMO. (Only thing I do not like very much is C++.)
My problem with desktop environments (which is the problem interoperability is SUPPOSED to solve) is there is barely any. You might be able to IMPORT settings from one desktop email app to another's (say they both use MBOX format). I found that KMail imports Thunderbird MBOX files terribly. Besides, if you have Kaffeine for a media player, how do you import those settings to another? Do we need standards here too (a standard settings file for media players)? (Personally I think it is a bit over the line, but could be very useful). Maybe a whole set of standard preferences files?
Right now I cannot move to KDE 4 or GNOME. I am a little bit stuck on KDE 3 (at least till KDE 4 can do everything correctly) and my life is in Kontact. I love KDE, but the ability to switch at any time with ease would be great.
meanwhile (Score:3, Interesting)
Rich Internet Application platforms, like Adobe Flex, are making it easier to get rid of client-side GUI libraries entirely.
Have a browser? Most apps can be done in AJAX, the remaining apps can be done in Flex. Why use GTK or QT?
Re:time to port gnome! (Score:4, Interesting)
The Linux kernel has flourished without any real competitors for while now...
Re:time to port gnome! (Score:3, Interesting)
Last time i checked kubuntu still had 30% of ubuntus users (or 40% if you want to play numbers) but it is poorly maintained.
Re:How would *you* know? (Score:2, Interesting)
How is it trolling to say I don't use a Linux desktop? I've tried it. It's not good. I wish it were; I don't like Windows any better (Windows currently wins based on applications more than anything) and the OS X user interface makes me cringe. But it's bad. It's not usable.
"Troll" is not a synonym for "disagrees with me and therefore is bad".
Re:Hello Moto (Score:5, Interesting)
I don't have a problem with the GPL, I usually use more liberal licensing like BSD, Creative Commons Attr. or MIT myself, and find GPL incompatible for inclusion. If you use GPL code, your code is GPL, it's that simple... if you don't like it, don't use it. There's LGPL, MPL, BSD, MS-PL and a host of other options. You have no place to bitch about it. I like the GPL for applications, it prevents people from subverting your application without giving back (not so great in web/SaaS models though). I think that SaaS using modified GPL apps does subvert GPL a bit. It's a balancing act, trying to preserve your rights as the original developer, while allowing people to utilize your code.
I happen to kind of like MS's MS-PL license. It's kind of like BSD with a nuclear deterrent clause (anti-patent/anti-lawsuit). I feel it's probably more appropriate in most cases over BSD. Since it would allow you to protect yourself, at least a little, from the patent trolls. Sure it works better for larger companies like MS, but is a kind of cool idea just the same.
Re:Hello Moto (Score:4, Interesting)
I personally think it sucks to see that those who are materially acting contrary to those ideals are sharing the benefits of this code.
Out of curiosity, how do you feel about Samba? Or Wine?
I have somewhat different priorities -- I would rather see end-users benefit. Most often, this means I'd rather see something open than closed (I'm looking at you, Flash), but not always.
For example, many games, by their very nature (FPS, for instance), are only secure against cheating through obscurity. It might be possible to make a dual-licensed version of that work, given sufficient "trusted computing" to ensure that only the official binary is used in certain settings. A GPL3'd version wouldn't work at all.
I would like to see the day arise where the closed source commercial software industry dies because it's forced to re-invent more and more wheels that open source software developers do not have to re-invent
That actually has very little to do with open or closed, and everything to do with communication and cooperation.
I've been doing a lot of Rails work lately... Seems just about everything Ruby (especially Rails stuff) is MIT-licensed. The idea is that if an idea is good, and generic enough, you'll release it back to the community rather than try to maintain it yourself -- but when you use that stuff in your own proprietary project, you don't have to worry about licensing.
The net result is, only the stuff which is actually relevant to the site in question are at all subject to re-invention. And even then, not necessarily -- provide an API, and others will just use your service instead of reinventing it.
Nor is an aversion to the GPL strictly a proprietary thing. If you've got a large codebase in an OSI-approved, but GPL-incompatible license, it's a problem, and the GPL is about the least compatible FOSS license out there.
As a simple example: We absolutely do have to reinvent the wheel with ZFS, if it's to ever exist in the Linux kernel, largely because the kernel is GPL'd. And if btrfs ends up being good, and anyone wants to port it to OS X, BSD, or OpenSolaris, they're going to run into the same problem. We do each of those using things like FUSE, not for any technical reason, but to avoid licensing problems.
The only way to avoid reinventing the wheel is to follow sqlite's example, and go public domain -- or to define "proprietary" as "not using the GPL", which is just stupid.
Re:time to port gnome! (Score:1, Interesting)
Qt/Embedded, especially with WebKit allows you to make some really nice apps that you can run on your Linux console WITHOUT X. You just need to enable the framebuffer and setup the environment properly. You can run all types of GUI programs directly on the console with minimal additional libs required for your server, for example DBS status/config, system admin, system test, etc. WebKit allows for you to even include browser capabilities and using Arora allows you a full browser capability -- on the console!
Weird license restriction: (Score:5, Interesting)
Nokia DOES presume to tell you what you can do with your LGPL code. Read this quote [qtsoftware.com]:
"Can I switch from using Qt under the LGPL to commercial afterwards?
"Users of the LGPL versions of Qt need to comply with the LGPL licensing terms and conditions. Qt's commercial license agreement contains a restriction that prohibits customers from initially beginning development with the LGPL licensed version of Qt and then transitioning to a commercial version of Qt."
Wow! How do they know how you "initially" began development?
It seems as though some lawyer or marketing guy with no technical understanding got involved.
How does this affect the open source cross-platform GUI toolkit WxWidgets [wxwidgets.org]?
Re:Kills any idea of using Qt in our products (Score:3, Interesting)
Your company has a very silly policy.
At first glance, it sounds that way, but we have to be careful because we don't know all the details. I've seen companies rejecting all sorts of external software based on apparently permissive licence agreements. One example is companies that produce libraries rather than end-user products, who can't necessarily impose any changes on their entire customer base without rewriting every contract they ever signed; this can be triggered by something as simple as a required attribution clause in the licence of a sub-library.
Re:Ars Technica report (Score:4, Interesting)
Replying to myself:
Personally I think the LGPL is not doing what it was intended to do, because when it was written they were thinking only about libc and not libraries that might not be included with the operating system.
Static linking should be allowed. The requirement that should be enforced is that if you modify the code in the LGPL library itself, you have to distribute the modifications. The rules are a bit more complicated so that you are not allowed to modify it to call a pointer that is set to point at a secret implementation, and other tricks.
The LGPL requirement for shared libraries is actually a big hindrance to complex libraries. It pretty much requires the binary api to be frozen. As anybody who has tried to write anything that complicated knows, that is quite impossible.
The other popular solution is to add a "linking exception" to the GPL/LGPL. Something called Classpath has the most popular wording. This pretty much makes the LGPL work like most people expect. One problem with this is that the "linking exception" completely hides all the differences between the GPL and LGPL (ie the result is exactly the same if you add the linking exception to either one). But without the name "LGPL" people don't think they can use the code in closed source. I think it would help a lot if GNU would standardize the wording of the "linking exception" and make it commonly known, so that people who see "GPL+linking exception" would know that it is even more useful than LGPL.
QT 4 bindings for Ruby (Score:3, Interesting)
Here: https://rubyforge.org/frs/?group_id=181&release_id=23283 [rubyforge.org]
No need to stick with C++ and Java, the QT bindings for Ruby work like a charm.
Re:Kills any idea of using Qt in our products (Score:3, Interesting)
Your company has a very silly policy. I've worked in quite a few places that did commercial closed-source development, and none of them had any problems with LGPL; after all, it was written precisely so that closed-source apps can use it! Why waste time re-writing the code somebody has already written before, and allowed you to use?
They may have been feeling very cautious about the possible issue of developers not only "linking with" but actually "deriving from" LGPL code...
Basically when code is open-source, but with a license restrictive enough to make the lawyers uncomfortable, there's a bit of a liability there - the developers, of course, have total freedom to read and learn from that code. But not all of them will be disciplined enough, when reading a piece of code which does exactly what they need a closed part of their app to do, to not reuse that information inappropriately.
Some would be careless enough to misinterpret the LGPL and either link it improperly or reuse it within closed portions of the code. Aggressively warning employees to avoid GPL/LGPL code is easier that teaching the proper discipline in handling it - and even if a violation didn't wind up costing them a lot of money, it does tend to raise a bit of a stink when it's discovered...
Re:Hello Moto (Score:4, Interesting)
The GPL is a true quid pro quo. It says "I will give you my code if you give me yours."
"Give back your changes to my code", on the other hand, is an unequal bargain. You can't realistically claim that a handful of bug fixes are of equal value to an entire library.
You don't have to like the GPL, but please stop spreading FUD. There is nothing "immoral" about a license that merely requires repayment in kind.
Re:Vala makes the creating widgets argument moot (Score:3, Interesting)
Vala is hardly a failure if you examine why it exists and what is used for (and how it relates to the post I was originally answering). Well Vala is really syntactic sugar over C and the existing gobject facilities. So yes, memory management isn't going to be like C#, and it's not like C++ either, alhough C++ doesn't have a garbage detector or a cycle detector... nothing big ever gets written in C++ for those reasons. Like Qt Apps. Right. Big applications can and have been written in straight C with GTK and have done fine. Worst case, Vala just makes writing such applications easier, though you do have to manage memory yourself.
But I should have been more clear when I was promoting Vala. Vala could be used to write big apps I'm sure, but like you say with real nice languages like Python, there's really no point. However I was addressing the concern expressed that creating new widgets in GTK or even extending widgets is very painful in C. Vala is intended to address this and make it easier to develop GTK libraries and extend GTK. That's the point.
Sure if you want to compare GTK to Qt you'd be better off to compare GTKmm to Qt. But of course if you were to write widgets in GTKmm you're locked to C++ and can never offer them to other languages without a port.
Re:Hello Moto (Score:3, Interesting)
The only safe work around for the GPL IMO (IANAL OMGWTFBBQ) if to *not* distribute anything GPLd. Distribute your code with a readme that directs the user where to get the GPL code. Even that makes me nervous.
I *really* like the Boost license
Permission is hereby granted, free of charge, to any person or organization obtaining a copy of the software and accompanying documentation covered by this license (the "Software") to use, reproduce, display, distribute, execute, and transmit the Software, and to prepare derivative works of the Software, and to permit third-parties to whom the Software is furnished to do so, all subject to the following:
The copyright notices in the Software and this entire statement, including the above license grant, this restriction and the following disclaimer, must be included in all copies of the Software, in whole or in part, and all derivative works of the Software, unless such copies or derivative works are solely in the form of machine-executable object code generated by a source language processor.
[warranty disclaimer snipped]
That's the entire license. The Boost team hired a lawyer to write this in such a way as to be calming and soothing to other lawyers. If you don't distribute your own source, you don't have to distribute the Boost source - simple as it gets.
this isn't enough (Score:1, Interesting)