Eiffel Studio adds GPL version

Eiffel Studio looks like a nice IDE. This might make an interesting case study of the effects of a good IDE on the popularity of a language.

The GPL'd effort has its own site:
http://eiffelsoftware.origo.ethz.ch/

It has debian packages in progress:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=361001

For completeness. The press release can be found here:
http://www.eiffel.com/general/news/2006/2006_04_05_pr.html

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Unsavory license model

From what I can tell, if you use the IDE to build your application then your application must be GPLd, unless you buy the commercial license. Even if you aren't doing commercial apps this prevents you from choosing a different license, like BSD. Too bad they didn't go with the special exemption that gcc has.

Also, the only way they can offer dual licenses is by requiring all contributors to assign copyright to whoever owns the copyright for Eiffel. Not unheard of, but it does put a damper on the "open source" aspect.

It's the libraries that make your code GPL

Merely using the IDE to edit source code can't possibly infect it with the GPL; enough people develop closed-source software under Emacs to make that idea unconvincing. It has to be the libraries that are actually included in your compiled code that make the whole thing GPLed.

For this dual-licensing model, the BSD would be useless for EiffelSoft: Tentacle A could use the IDE to generate a BSD-licensed application, and distribute it solely to Tentacle B, which (in accordance with the BSD) sits on the source code and distributes just binaries.

Finally, there are plenty of open-source projects that require contributors to assign copyright, beginning with gcc and every other FSF project; I'm sure there are others.

Re: It's the libraries that make your code GPL

Merely using the IDE to edit source code can't possibly infect it with the GPL

For the most part, no, though I wouldn't be too cavalier about the issue. It would be very easy in an IDE to use a wizard, template, or some other kind of boilerplate code without even thinking about it.

Anyways, I just wanted to point out the limitations of the license model they chose. Of course Eiffel-corp will do what it thinks is best for Eiffel-corp, and GPL coders will be happy, but others will have some thinking to do.

GPL doesn't force you to GPL your code

It's a common misconception that because a library is GPL, you're forced into GPL'ng your code. Your code can be anything GPL compatible. What happens is (or what the FSF claims) is that the distribution of your code along with the libraries effectively GPLs the entire work.

Eiffel Studio seems to be doing the Trolltech thing with regards to a business model revolving around the viralness of the GPL. If it works for them so be it, but it's hurt KDE in the long run.

Not to get too off topic...

But don't make claims like Trolltech hurting KDE unless you're going to actually back them up with some reasoning or evidence. Trolltech employs the guy behind the Plasma desktop behind KDE 4.0. Somehow I think he'd disagree with you. If you read KDE hacker's blogs a lot of them speak glowingly of Qt, I've never once seen them rant against Trolltech. Once you've submitted some patches to the KDE project and have worked with Trolltech on fixing bugs or getting features into KDE you can be qualified to determine whether or not their model hurts the project. I realize it's more popular on LtU to credit project's success on the language used to implement them, and plenty of people debate Gtk+C vs. Qt+CPP, but if I had to point to the one major reason the latter is leap years ahead I'd have to say it's that Qt has a big commercial backer.

Take Eclipse...

Yet, I still agree it hurts KDE when some applications (both commercial and opensource - I find Eclipse/SWT a good example) cannot be “ported” to QT because of license issues. QT is too fundamental a library in a KDE environment to have GPLed. I wouldn't have a GPLed libc (etc...), no matter how well supported it was.

What about glibc

I wouldn't have a GPLed libc (etc...), no matter how well supported it was.

That's a good argument that I've used in the past. If some company owned glibc, like Trolltech owns Qt, then Linux would have never taken off on the server.

Just look at the big commercial distros

Novell and RedHat and Sun chose Gnome for their environments. It wasn't just such random event of why that occured. Some guy being employeed by Trolltech to work on KDE isn't someone that could give an objective view on the matter.

Let's face some facts. If Novell or RedHat or Sun or anybody else ever hopes to get desktop linux into the mainstream, that includes ISVs, shareware developers and others, and they weren't going to be held hostage by whatever pricing scheme that Trolltech had for the week.

So you might not like it, but having a dual-licensed GPL/commercial toolkit as the basis for KDEs desktop hasn't done it any favors.

Hostage?

The software is GPL. That only qualifies as being held hostage if you openly acknowledge that you're developing a platform intended for closed source software.

My point with the KDE hacker wasn't that he was a great objective source. My point was that he's evidence that KDE hackers aren't distraught by QT's licensing scheme.

Redhat choosing Gnome is almost insignificant. They are a server focused distribution. This becomes pretty obvious when you look at the usability pushes from Ubuntu and Novell and the complete lack of headlines about similar efforts from Redhat.

Novell's SUSE has been a KDE based distribution for longer than it has been a Gnome based one. The shift started when they bought Ximian, which was Gnome based. I haven't read anything that suggests the shift was due to licensing.

Ubuntu, although primarily Gnome based at this time, has a spin off Kubuntu. Mark Shuttleworth, Ubuntu's creator, has stated that Kubuntu is now his primary desktop and he wants to make it a full fledged distribution. I would think ISV's would be something he's considering seeing as he's poured quite a bit of money into these projects. Linspire also helps fund KDE development.

If Trolltech's licensing was hurting KDE/Qt, then I would expect it to be of lower quality. GTK+/Gnome have been playing catch up up until very recently. Before Cairo, KDE clearly had fancier eye candy (and in some areas still does -- Metacity still doesn't support fading widgets for instance).

ISV's have proven in the past they will subject themselves to far greater lock in than they get with Qt. Developing MS software in the past has meant buying a compiler suite that was at one time more expensive than Qt, not getting any source code in the deal, and having your resultant software only run on one platform.

Also, just to clarify: the kdelibs are LGPL. If you buy a Qt license you can make closed source KDE apps.

These aren't business-level

These aren't business-level trade-offs!

If Trolltech's licensing was hurting KDE/Qt, then I would expect it to be of lower quality. GTK+/Gnome have been playing catch up up until very recently.

and your earlier post:

plenty of people debate Gtk+C vs. Qt+CPP, but if I had to point to the one major reason the latter is leap years ahead I'd have to say it's that Qt has a big commercial backer.

1. Gnome has big commercial support (the project's leader is the VP of Developer Technologies at Novell).
2. Gnome lost serious ground to KDE when the lead developers went down the Bonobo route, and KDE went with D-Bus.
3. Gnome's Object Model previously used languages with poor support for component-oriented programming; these languages lacked a Delphi-style Properties, Methods and Events (PME) Model. By contrast, GNU GNUstep, Apple Cocoa and Trolltech Qt frameworks had full-fledged compilers and languages. Qt had the Moc, and GNUstep and Cocoa both had Objective-C. Gnome has spent time investing in doing similar things with Vala, but this is more recent. Yet the call to create something like Vala (or just use Objective-C) was heard in 2001.

So, bringing this back to languages, the differences in the two platforms, in my eyes, boils down to languages, not licenses or business support!

As an aside, I don't understand why Public Domain isn't used more often. Most people want to contribute back, and don't want to be long-term responsible for maintaining their own source tree.

Public Domain

At least according to my IP lawyer, under the Berne Convention, it's pretty much impossible to intentionally release your work into the public domain. Only passage of time can do that, in any way that your users can trust. The best you can do is release your IP with an unencumbering license.

Licensing questions

For those wondering why using the IDE would require you to use GPL for software written with it... turns out that binaries built with EiffelStudio are linked against the EiffelStudio runtime (it is required). Thus under GPL terms said binaries must be GPL'd as well.

Licensing Issues

While I can fully appreciate that the makers of tools such as QT and ISE need to make a buck (don't we all), they are in competition now with Java, Groovy, Ruby, Python, etc. If their goal is to make that buck, then power to them, but my goal is not to spend that buck, so what's next in line?

If their goal is to sell an idea (and Eiffel is a bundle of great ideas!), then their licensing scheme is in the way, and my goal is to keep things simple and legal. So what's next in line?

The Free Stuff wins. The QT licensing is why I (and the company I work for) don't use QT. It is ambiguous and seems too dangerous to use the 'free' version, even (or especially) for software developed for in-house use only. And the cost per seat is very hefty when compared with (free) Java. And the same kind of licensing/control mindset has contributed to keeping Eiffel from being a mainstream language.

It has been a while since I've read through the TrollTech QT license, but at the time (and the time before) it was sufficiently unclear and mined with legal 'gotchas' that we passed. Twice. Not worth the effort and/or risk.

The ISE/GPL license encourages the same decision. Not that we'd be likely to develop in Eiffel, anyway: not enough programmers know the language. There is a certain corporate comfort level that comes from knowing that there are a few hundred thousand Java programmers out there to choose from.

But the reason not enough programmers know the language? Too expensive to work in, and licensing too Draconian to encourage independent development and exploration. As I said earlier: the free languages win. The free and ready availability and usability of C, then Java, and now Ruby make them much more attractive to the programmers who are likely to go out and learn new languages. If Eiffel is more broadly accepted in the future it will be because of the availability of SmartEiffel and such, not ISE's GPL licensing.

At least, that's what I think.

Does this help?

Not sure how this thread got re-started

But, Nokia has LGPL'd the Qt library.

Not really PLT-related, but it would be interesting to peer into an alternative universe where Qt had always been LGPL'd and Gnome had never been started. Miguel de Icaza had stated that one of the reasons he started the Gnome project was because of the funky license (before Qt was even GPL) that Qt had.

Sun had always worried about the fragmentation of Java. Maybe they considered the Linux desktop ecosystem a prime example of what they didn't want to happen.