Depends what you call "heavly". BSD still has some restrictions on the licensing - not many, but some. To my mind GPL has few enough restrictions that I'm happy to work on programs that use it. In fact I'm happy to work on programs that use any free software license, even "you get a limited license but have to give us an unlimited license" ones like the Netscape and Apple ones.
WxWidgets is getting there, but it's not yet as powerful as Qt. I can still write a similar program ~1.2x as fast with Qt. That may just be me, but I feel I've made an equivalent effort to learn both.
Just try programming in it. Write an mp3 player or something (that's how I learnt). I found I enjoyed it a lot more than doing the same thing in GTK, and just found it simpler. But it's your choice.
- GTK has GTKMM, C++ bindings that follow STL conventions so will be more familiar to C++ developers.
- GTK while being C based has excellent C++ bindings.
Anyone who has used them will tell you the Qt way, despite being nonstandard, is much easier to write an actual program in.
- GTK can rely on glade/libglade / any editor of your choice, including KDevelop
That's a sign of the quality of KDevelop rather than the toolkit.
- Anjuta is an excellent IDE, many GTK developers also make use of Eclipse.
True; however, KDevelop is an even better one.
- GTK 2.x works fine on windows, not sure on the MacOS X status, but people seem to run Gimp just fine.
IIRC it will only work under X on Macs, wheras Qt can be "properly native" on Macs.
- GTK has no internal support for scripting because it is a GUI toolkit, no added bloat, you want scripting? embed perl / python / language of your choice, which provides a scripting language that people know and use that have significantly more power than QTs
I think this is the core difference. GTK aims to be purely a GUI toolkit, wheras Qt tries to include anything that most people want. I've used Qt purely for its threading and networking libraries without needing it for GUI at all. This doesn't mean bloat, especially with this new version, as the libraries are split up and you don't have to link against them all.
- gnome-db not being part of GTK is an advantage, if you don't need it, you don't have the bloat.
The libraries are there if you need them, if you don't don't link against them.
- GTK based applications can talk to each other via the freedesktop.org DBUS protocol, which KDE will be migrating to as well. DBUS bindings exist for glib, python, c# so you can talk to other non GTK applications as well, not just limited to QT apps like DCOP.DCOP is incredibly easy to embed, more mature although DBUS is now getting there, and included by default with your actions, so the IPC is there with zero effort from the programmer. Yes this means bloat, but it's worth it. CORBA is far bloatier to include, and limits you to applications which have explicitly included corba support, which is very few.
- GTK is completly available on Windows, even following the WinXP theme.
You use GLX under X. And composition is done using opengl when it's available, but Xcomposite is still basically beta. I can't see how having other non-opengl windows would mess up an opengl one - have you never used the xmms opengl visualiser with other windows open?
I have tried both of those, but for ease of development I've found something which beats both is Qt/Python. Give it a try if you haven't - it's actually easier than Qt/C++ because you don't have to worry about moc and declaring slots.
Qt is truly free. It's GPL, GPL, GPL. If you're not happy with them also providing a propriety/commercial version, then you can fork the GPL version and release it only under GPL. Go on. Find enough people who really think it isn't free enough as-is, and fork it. Trolltech wrote most of Qt and they're the ones who get paid when people buy it, exactly like MySQL etc.
As for Qt being doomed, having programmed with Qt and the alternatives I could find, I don't think so. Qt is still much, much nicer to program with than GTK, especially since you now have to implement your own confirmation dialog box. Wx is getting there but still a nightmare to install (IME of course) and working through GTK rather than natively hurts it. As for SDL, it's great for 3d renderers etc, but would you seriously want to write a word processor (for example) with SDL widgets? I'm not sure where eclipse comes in, I thought that was a java IDE, in which case Qt is still the best toolkit to use with java on linux, IME, it's much faster than swing and fits in with the most popular desktop environment.
The kernel people take the position that they won't do anything extra to support binary stuff, but they won't make it deliberately difficult either. To my mind that's a pretty consistent policy. It's what RMS originally did with glibc after all.
He can try and persuade him though, if he thinks that that is a better position. If people's opinions were unchangeable, what would be the point of debates?
Re:The GPL should be a little friendler.
on
Revising the GPL
·
· Score: 1
Because I do care about some megacorporation co-opting it. I want everyone who uses my code to have access to the source. I tend to just use GPL, but that causes problems when there's another similar license and someone with a program under that license wants to use my code. If it's purely my code I just relicense it, but if I've had contributions from others it gets messy.
Re:The RPL Already Solves the Fundamental Problem
on
Revising the GPL
·
· Score: 1
"Company property" is using the company-as-a-person fiction. And much as we may dislike it, since it's a legal thing there's not much the GPL can do about it. After all, a fundamental point of the GPL is that you can privately modify your program without having to release it, and I'm pretty sure the FSF rejects as non-free a license that doesn't allow private versions of a program.
Re:exactly, license patent to GPL software only
on
Revising the GPL
·
· Score: 2, Informative
The GPL does not need usage rights because they exist anyway and there's a "no additional restrictions" clause. Of course it's possible that a really messed up country would say you're not allowed to read source code you own, but in that case I don't think a license would be enough to help them.
Good point about the bug. But as for the last thing, if as successful projects do my project is being used for other things, and has had many contributions from various people, then relicensing is going to be very hard. It would probably be doable when copyrights are being assigned to a single entity, as with the GNU programs, but for the kernel I think it's more or less impossible.
Re:The RPL Already Solves the Fundamental Problem
on
Revising the GPL
·
· Score: 1
That's not a problem, it's a feature. The GPL is meant to be a true license in that it doesn't restrict any of the end-user's rights, only give them more rights (subject to some conditions). Why shouldn't my company be able to have their own internal, *private* version of a program? And all the employees using the program have access to the GPLed source, so if the program's good and the company's big enough, one of them will make a copy public.
Re:Definition of sourcecode of graphics files.
on
Revising the GPL
·
· Score: 1
I certainly hope so, and I would say: if that's the file *you* modify when modifying the image, then that's the file you should distribute. That would seem to me to be what it implies. Certainly that's the spirit of the GPL.
There's no way to stop MS Office being derived from B though. Treat the patent separately, and license it to end users individually, or license it only for programs released under GPL. The GPL is about copyright, not patents, and it's better to have something that does one thing well than something that tries to do several things and does them badly.
Re:The GPL should be a little friendler.
on
Revising the GPL
·
· Score: 1
The trouble is it's hard to have it both ways - if you can combine non-gpl and gpl stuff, it's going to have to be able to be included in MS Office as well. Should there be an evil bit on licenses so people know which ones they can combine your program with and which they can't?
I've sometimes wondered about "meta-licensing" my programs with something like "This program may be released under any open source license approved by OSI, provided such a license would not enable the program or a derivative therof to be released under a non OSI approved license". Good idea? Bad idea? Anyone?
The BSD places restrictions and requirements too - you have to keep the original author's name in the source code. If you're going to say "no restrictions and requirements" then you can only really use stuff for which the source code is in the public domain. If copyrights hadn't been extended this might not be that much of a problem, but as things stand you're going to have to accept some restrictions to be able to get anything done. A license which gives you the four freedoms is good enough for me.
The Linux kernel is actually different - it is released under v2.0 only. This means it's more certain that Linux will remain free and copyleft, but could be a problem if a serious bug is found in v2.0
Sorry, how is that a problem? What if it was a closed source project that had just been GPLed, and so had no changelog as yet? The current version is GPL, so surely Debian can use it?
Slashdot Mirror
Depends what you call "heavly". BSD still has some restrictions on the licensing - not many, but some. To my mind GPL has few enough restrictions that I'm happy to work on programs that use it. In fact I'm happy to work on programs that use any free software license, even "you get a limited license but have to give us an unlimited license" ones like the Netscape and Apple ones.
WxWidgets is getting there, but it's not yet as powerful as Qt. I can still write a similar program ~1.2x as fast with Qt. That may just be me, but I feel I've made an equivalent effort to learn both.
Bzzt. Academics may say that, anyone who's actually tried to program with them knows different.
Glibc doesn't give free software an advantage since there are plenty of equivalently functional libraries around. With Qt that's not the case.
Just try programming in it. Write an mp3 player or something (that's how I learnt). I found I enjoyed it a lot more than doing the same thing in GTK, and just found it simpler. But it's your choice.
- GTK while being C based has excellent C++ bindings.
Anyone who has used them will tell you the Qt way, despite being nonstandard, is much easier to write an actual program in.
- GTK can rely on glade/libglade / any editor of your choice, including KDevelop
That's a sign of the quality of KDevelop rather than the toolkit.
- Anjuta is an excellent IDE, many GTK developers also make use of Eclipse.
True; however, KDevelop is an even better one.
- GTK 2.x works fine on windows, not sure on the MacOS X status, but people seem to run Gimp just fine.
IIRC it will only work under X on Macs, wheras Qt can be "properly native" on Macs.
- GTK has no internal support for scripting because it is a GUI toolkit, no added bloat, you want scripting? embed perl / python / language of your choice, which provides a scripting language that people know and use that have significantly more power than QTs
I think this is the core difference. GTK aims to be purely a GUI toolkit, wheras Qt tries to include anything that most people want. I've used Qt purely for its threading and networking libraries without needing it for GUI at all. This doesn't mean bloat, especially with this new version, as the libraries are split up and you don't have to link against them all.
- gnome-db not being part of GTK is an advantage, if you don't need it, you don't have the bloat.
The libraries are there if you need them, if you don't don't link against them.
- GTK based applications can talk to each other via the freedesktop.org DBUS protocol, which KDE will be migrating to as well. DBUS bindings exist for glib, python, c# so you can talk to other non GTK applications as well, not just limited to QT apps like DCOP.DCOP is incredibly easy to embed, more mature although DBUS is now getting there, and included by default with your actions, so the IPC is there with zero effort from the programmer. Yes this means bloat, but it's worth it. CORBA is far bloatier to include, and limits you to applications which have explicitly included corba support, which is very few.
- GTK is completly available on Windows, even following the WinXP theme.
So is QT. You just have to pay for it.
You use GLX under X. And composition is done using opengl when it's available, but Xcomposite is still basically beta. I can't see how having other non-opengl windows would mess up an opengl one - have you never used the xmms opengl visualiser with other windows open?
I have tried both of those, but for ease of development I've found something which beats both is Qt/Python. Give it a try if you haven't - it's actually easier than Qt/C++ because you don't have to worry about moc and declaring slots.
As for Qt being doomed, having programmed with Qt and the alternatives I could find, I don't think so. Qt is still much, much nicer to program with than GTK, especially since you now have to implement your own confirmation dialog box. Wx is getting there but still a nightmare to install (IME of course) and working through GTK rather than natively hurts it. As for SDL, it's great for 3d renderers etc, but would you seriously want to write a word processor (for example) with SDL widgets? I'm not sure where eclipse comes in, I thought that was a java IDE, in which case Qt is still the best toolkit to use with java on linux, IME, it's much faster than swing and fits in with the most popular desktop environment.
As others have said, it is being ported. However, GDI is very different from X, so it's a lot of work.
The kernel people take the position that they won't do anything extra to support binary stuff, but they won't make it deliberately difficult either. To my mind that's a pretty consistent policy. It's what RMS originally did with glibc after all.
He can try and persuade him though, if he thinks that that is a better position. If people's opinions were unchangeable, what would be the point of debates?
Because I do care about some megacorporation co-opting it. I want everyone who uses my code to have access to the source. I tend to just use GPL, but that causes problems when there's another similar license and someone with a program under that license wants to use my code. If it's purely my code I just relicense it, but if I've had contributions from others it gets messy.
"Company property" is using the company-as-a-person fiction. And much as we may dislike it, since it's a legal thing there's not much the GPL can do about it. After all, a fundamental point of the GPL is that you can privately modify your program without having to release it, and I'm pretty sure the FSF rejects as non-free a license that doesn't allow private versions of a program.
The GPL does not need usage rights because they exist anyway and there's a "no additional restrictions" clause. Of course it's possible that a really messed up country would say you're not allowed to read source code you own, but in that case I don't think a license would be enough to help them.
Good point about the bug. But as for the last thing, if as successful projects do my project is being used for other things, and has had many contributions from various people, then relicensing is going to be very hard. It would probably be doable when copyrights are being assigned to a single entity, as with the GNU programs, but for the kernel I think it's more or less impossible.
That's not a problem, it's a feature. The GPL is meant to be a true license in that it doesn't restrict any of the end-user's rights, only give them more rights (subject to some conditions). Why shouldn't my company be able to have their own internal, *private* version of a program? And all the employees using the program have access to the GPLed source, so if the program's good and the company's big enough, one of them will make a copy public.
I certainly hope so, and I would say: if that's the file *you* modify when modifying the image, then that's the file you should distribute. That would seem to me to be what it implies. Certainly that's the spirit of the GPL.
There's no way to stop MS Office being derived from B though. Treat the patent separately, and license it to end users individually, or license it only for programs released under GPL. The GPL is about copyright, not patents, and it's better to have something that does one thing well than something that tries to do several things and does them badly.
I've sometimes wondered about "meta-licensing" my programs with something like "This program may be released under any open source license approved by OSI, provided such a license would not enable the program or a derivative therof to be released under a non OSI approved license". Good idea? Bad idea? Anyone?
The BSD places restrictions and requirements too - you have to keep the original author's name in the source code. If you're going to say "no restrictions and requirements" then you can only really use stuff for which the source code is in the public domain. If copyrights hadn't been extended this might not be that much of a problem, but as things stand you're going to have to accept some restrictions to be able to get anything done. A license which gives you the four freedoms is good enough for me.
The Linux kernel is actually different - it is released under v2.0 only. This means it's more certain that Linux will remain free and copyleft, but could be a problem if a serious bug is found in v2.0
Sometimes it is. More often it's just people being stupid.
Yes, but there seem to be an awful lot of cretins who will say "could care less" and confuse me.
Sorry, how is that a problem? What if it was a closed source project that had just been GPLed, and so had no changelog as yet? The current version is GPL, so surely Debian can use it?