| |||||||||||||
Digia acquires QtDigia acquires QtPosted Aug 9, 2012 13:00 UTC (Thu) by am (guest, #69042)Parent article: Digia acquires Qt
This mostly seems like good news to me - I'm sure that with Digia, Qt will be much better than it was in what has become of Nokia. What seems to be upsetting is this: As part of the transaction, a maximum of 125 Qt people from Nokia will transfer to Digia, mostly based in Oslo, Norway and Berlin, Germany. According to last year's blog [1], Qt had 260 employees, so it seems it's getting cut in half. Additional, it seems they're cutting the Brisbane office, which focused on QML and QtDeclarative. [1] http://labs.qt.nokia.com/2011/02/18/buckets-of-cold-water/
(Log in to post comments)
Digia acquires Qt Posted Aug 9, 2012 13:12 UTC (Thu) by tajyrink (subscriber, #2750) [Link]
It's probably not that clear cut. The referred blog entry was written immediately after the elopcalypse in Feb 2011, after which the original non-free Qt licensing and development moved to Digia in March. Several other Qt developers have also left Nokia for Intel and other companies during the 1.5 years, and continue contributing to Qt.
So it's not clear with this data at least how large the actual Qt organization has been nowadays at Nokia. Since the Qt project (.org) launched last autumn, non-Nokia contributions have been constantly rising.
Digia acquires Qt Posted Aug 9, 2012 13:54 UTC (Thu) by dgm (subscriber, #49227) [Link]
After reading the blog you link the use of "plasma" for the KDE desktop makes a lot more sense.
Digia acquires Qt Posted Aug 9, 2012 18:46 UTC (Thu) by mikov (subscriber, #33179) [Link]
260 employees for a GUI toolkit? Isn't that a bit excessive? I am actually a big fan for Qt (and a full time user of KDE), but 260 developers seems like an incredible number to me. By comparison, how many people are maintaining GTK - 2 or 3? Of course GTK is nowhere close to Qt in features and performance, but still it isn't 100 times worse :-)
Digia acquires Qt Posted Aug 9, 2012 20:16 UTC (Thu) by marduk (subscriber, #3831) [Link]
260 employees != 260 developers.
Digia acquires Qt Posted Aug 9, 2012 20:36 UTC (Thu) by Kit (guest, #55925) [Link]
Beyond marduk's point, Qt is quite far from just a GUI toolkit. Check out the list of Qt modules to get a bit of an idea. It's very nice when writing cross platform applications to be able to have a single go-to framework that has excellent support for all the major platforms (and, hopefully, finally the mobile platforms that anyone actually uses as well), instead of a random hodge-podge of libraries, each with questionable support for non-Linux platforms.
Digia acquires Qt Posted Aug 9, 2012 21:46 UTC (Thu) by cmccabe (guest, #60281) [Link]
For better or worse, QT has grown into more than a GUI toolkit. It now encompasses networking, multimedia, an XML parser, a Javascript engine, a GUI designer, and so forth. In a way, QT's original concept is a lot like "GNOME OS" or Java-- putting a layer between you and rest of the operating system.
Digia acquires Qt Posted Aug 10, 2012 7:33 UTC (Fri) by boudewijn (subscriber, #14185) [Link]
There is one full-time developer on GTK, and he seems to be getting pretty burned out (https://lwn.net/Articles/508393/).
As for Qt, it's not just Trolltech^WNokia^Digia working on it, companies like KDAB and organizations like KDE provide a healthy amount of work as well: http://www.macieira.org/blog/qt-stats/.
Digia acquires Qt Posted Aug 10, 2012 10:07 UTC (Fri) by drag (subscriber, #31333) [Link]
If GTK fails it isn't going to make QT better or make KDE more popular. Free software isn't a zero sum game.
Digia acquires Qt Posted Aug 10, 2012 10:56 UTC (Fri) by boudewijn (subscriber, #14185) [Link]
Er, how did I suggest that?
Mikov asked two things, namely how many people were maintaining GTK, for which the answer is as far as full-time people go, one. His other question was whether the number of people working on Qt is excessive, to which the answer is two-fold: Qt is bigger than a UI toolkit, and just the number of digia/nokia/tt employees doesn't tell the whole story, since other companies and organizations are also putting in considerable manpower.
How those answers can be construed into saying "If GTK fails, it's going to make Qt better" is beyond me.
Digia acquires Qt Posted Aug 10, 2012 11:01 UTC (Fri) by rsidd (subscriber, #2582) [Link]
You didn't in the slightest way suggest that. But some people will read what they want into it.
Digia acquires Qt Posted Aug 10, 2012 16:40 UTC (Fri) by drag (subscriber, #31333) [Link]
Seeing how often certain people bring up GTK in a QT discussion or suggest that the world would be better off if people abandoning GTK for whatever reason it seems that it is certainly implied.
If that is truly not the intent, the sorry.
But it's worth stating that under no uncertain terms that nobody will ever get success through another person/group's failure in open source or free software. Success only comes through individual merit. The 'versus' game is a waste of time.
Digia acquires Qt Posted Aug 10, 2012 16:58 UTC (Fri) by rsidd (subscriber, #2582) [Link] You obviously did not read the post by mikov that boudewijn was replying to. It's true that lwn's layout makes it hard to identify the parent, but it's not that hard.If boudewijn said that out of nowhere and lacking any context, then maybe you'd have a point. But it's obvious in this case that he was only clarifying the numbers.
Digia acquires Qt Posted Aug 10, 2012 21:46 UTC (Fri) by mikov (subscriber, #33179) [Link]
Yes, let's not get carried away. My own post was more in the sense that while it is sad that half of the QT staff is going away, QT should be able to continue improving fine with a 100 people working on it full time. I am actually not aware of any (popular?) open source project with this number of full time contributors, other than the Linux kernel itself.
One of the reasons QT is very important is that GTK cannot be used by closed source apps in embedded or mobile devices (since it is only LGPL licensed).
Digia acquires Qt Posted Aug 10, 2012 22:16 UTC (Fri) by gidoca (subscriber, #62438) [Link]
Well, Mozilla Inc. allegedly has 600 employees: http://twitter.com/paulrouget/status/116110841669099520
Digia acquires Qt Posted Aug 11, 2012 8:49 UTC (Sat) by jospoortvliet (subscriber, #33164) [Link]
Yup. And how about Apache, or WebKit - they must sport similar numbers...
Digia acquires Qt Posted Aug 11, 2012 8:53 UTC (Sat) by rsidd (subscriber, #2582) [Link]
I'm sure dozens hundreds of people have worked on GTK in its history -- the worry is that only one person currently does. It's a worry because a huge amount of software depends on Gtk. Moving everything to Qt or something else is not an option. But for that reason, I expect Gtk will get support when a crisis becomes obvious :)
Digia acquires Qt Posted Aug 11, 2012 10:07 UTC (Sat) by krake (subscriber, #55996) [Link]
"One of the reasons QT is very important is that GTK cannot be used by closed source apps in embedded or mobile devices (since it is only LGPL licensed)."
Why would that be? I am not aware of any clause in the LGPL prohibiting its deployment on embedded or mobile devices.
Digia acquires Qt Posted Aug 11, 2012 15:25 UTC (Sat) by mikov (subscriber, #33179) [Link]
LGPL requires that the end user be able to replace the LGPL-licensed shared library, or it turns into GPL. The problem is, end users have no access to replace shared libraries in embedded or even mobile devices, so LGPL ==GPL there.
Of course this only matters to closed source software.
As an example of the above restriction, for closed source Mono requires a paid commercial license in embedded or mobile, because its runtime is LGPL. That is why I wouldn't touch it with a ten foot pole :-)
Given the raising importance of embedded and mobile, one might as well assume that LGPL is GPL. Nothing inherently wrong with that, but it does mean LGPL software is less commercially adopted.
Digia acquires Qt Posted Aug 11, 2012 15:53 UTC (Sat) by krake (subscriber, #55996) [Link]
"LGPL requires that the end user be able to replace the LGPL-licensed shared library..."
So far I am with you
"...or it turns into GPL"
Can you quote the passage of the LGPL that says that?
"The problem is, end users have no access to replace shared libraries in embedded or even mobile devices"
If one takes an embedded device, say a Raspberry Pi, and puts a Qt based application on it, how exactly is the end user of said device prohibited from changing any LGPL library?
"Of course this only matters to closed source software."
How so? I was under the impression that the licence clauses of the LGPL for a library applied totally independent of what licence the application code is using.
Digia acquires Qt Posted Aug 14, 2012 21:14 UTC (Tue) by Wol (guest, #4433) [Link]
You've missed the point. If you put a LGPL library on RaspberryPi, you can of course put a replacement/upgrade on.
The problem arises if I want to sell an app with a LGPL library in it. I have to make sure my customers can replace the LGPL component if they wish. If the only way they can do it is to download a new app from the appstore, then I'm stuffed.
Cheers,
Digia acquires Qt Posted Aug 15, 2012 7:12 UTC (Wed) by krake (subscriber, #55996) [Link]
"You've missed the point."
I don't think so, but let see.
"If you put a LGPL library on RaspberryPi, you can of course put a replacement/upgrade on."
According to the comment I was replying to, this is not possible: "...end users have no access to replace shared libraries in embedded or even mobile devices..."
I would consider the Raspberry Pi to be an embedded device.
So I conclude that neither you nor the parent comment's author consider the Raspberry Pi an embedded device.
Digia acquires Qt Posted Aug 16, 2012 12:59 UTC (Thu) by Wol (guest, #4433) [Link]
Because, aiui, it isn't.
It is, and is sold as, "a system on a chip" near enough. If I buy a Pi, *I* have to provide the SSD. *I* have to program the SSD. etc etc.
In other words, as supplied, the Pi is as functional as a normal desktop without a hard disk.
I can then turn it into an embedded system (for which purpose it is eminently suitable), but it isn't that in and of itself.
Cheers,
Digia acquires Qt Posted Aug 16, 2012 13:34 UTC (Thu) by krake (subscriber, #55996) [Link]
So what does qualify as an embedded system in your definition then?
Just the SoC without any connectors?
From my point of view the Raspberry Pi, the Beagleboard/Pandaboard, Shiva Plug and similar are classical embedded systems: more or less fixed hardware (often no such things as an PCIe slot), to be used without a screen or hooked up to a screen that is not a traditional PC monitor, etc.
Digia acquires Qt Posted Aug 16, 2012 15:01 UTC (Thu) by mikov (subscriber, #33179) [Link]
An embedded system is a typically fixed function device where the end user is not provided with the ability to service the software. Think a microwave oven or a TV. It is a description of functionality and intent, not hardware form factor.
A PC without a general purpose OS is embedded and the Raspberry PI with Debian and Gnome desktop isn't.
In any case it doesn't matter how you call it, as that is the kind of system I meant in my initial post. We use words to convey shared meaning and that is what embedded means traditionally.
Digia acquires Qt Posted Aug 16, 2012 16:01 UTC (Thu) by krake (subscriber, #55996) [Link]
Well, of course if you specifically choose a definition that has as its primary characteristic that the system is not changable, then you remove all the other alternatives which would make your theory falsifyable.
A lot of systems used in modern control panel type applications run general purpose operating systems such as Windows CE, Linux, or QNX and on COTS (commerical off the shelf) boards. Most machine vendors deploying such panels for their machines are investing in DRM measures to prevent system alteration.
I consider those to be embedded systems as well, thus disagreeing with the statement that all embedded systems be unmodifyable.
Digia acquires Qt Posted Aug 16, 2012 16:50 UTC (Thu) by mikov (subscriber, #33179) [Link]
Your assertion that "modifiable systems are modifiable" is meaningless in the context of this discussion.
The issue at hand is using LGPL on the very common type of system where the software is not end user serviceable. It doesn't matter whether we call that "embedded" or not.
Digia acquires Qt Posted Aug 16, 2012 18:02 UTC (Thu) by krake (subscriber, #55996) [Link]
How can that assertion be meaningless?
An unmodifiable system will never satisfy the requirement, a modifiable system will.
There is no passus in either the LGPL or the GPL that says it has to be easy.
Modifying an OS image and reflashing a device is no different.
"It doesn't matter whether we call that "embedded" or not"
Indeed. Embedded does not imply unmodifiable or vice versa. Hence my objection to the original statement. Neither embedded nor mobile devices are by definition unmodifiable.
Digia acquires Qt Posted Aug 16, 2012 19:11 UTC (Thu) by mikov (subscriber, #33179) [Link]
By your definition any system is modifiable because it can be modified after an arbitrary amount of effort. For example, it might require breaking a encryption key which takes years. But no matter, it is still *possible*, the only difference is the amount of time and effort it takes. Where do you draw the line?
Clearly such a definition is meaningless.
What matters is the intent. Does the device deliberately provide the user with the ability to service the software? A desktop PC running a standard desktop does. A desktop PC running kiosk software *does not*.
Granted, Jonno has posted some thoughtful arguments that modifying the actual device might not be strictly required in the legal sense for LGPL2. That is a line of reasoning that deserves serious consideration.
Digia acquires Qt Posted Aug 16, 2012 19:51 UTC (Thu) by krake (subscriber, #55996) [Link]
"By your definition any system is modifiable because it can be modified after an arbitrary amount of effort."
No.
"What matters is the intent."
Exactly!
"A desktop PC running kiosk software *does not*."
I think you are over generalizing again. I know of quite some Kiosk PCs which are installed, configured and updated by their respective owners or their employees and have not been rendered unmodifiable (neither technically nor legally) by the device's manufacturer.
Just like with embedded devices, the device category does not imply the availability or absence of customizability.
Since you like general statements so much I'd say that the majority of systems is designed that way and only a very small portion has been artifically restricted by technical (e.g. cryptography) or legal (e.g. renting instead of selling) measures.
Digia acquires Qt Posted Aug 16, 2012 23:25 UTC (Thu) by Wol (guest, #4433) [Link]
What qualifies as an "embedded system" to me? Basically, a system where you have little to no control over the software.
Let's take a PC. I build my own, put my own software on it, do as I like. THIS IS THE RASPBERRY PI! It comes with a slot for an SD card or whatever, which you use as your hard disk, and you have FULL CONTROL over it. What goes on the raspberry pi's "hard drive" is fully under the owner's control.
Then you get locked systems. My wife's just acquired a Google Nexus 7. I'm not going to bother rooting it, but the point is that it is not easy to access its "hard drive" and change the OS or stuff like that. Would you call a Nexus 7 embedded? To my mind it's far closer to embedded than the Pi!
Then there's what most people consider embedded systems. That come, for all intents and purposes, with the software hard-coded in ROM.
By my definitions, an embedded system is perfectly okay with the GPL - no-one can update the software, so there's no problem.
Equally, an open system is perfectly okay. Whether it's a PC or a Raspberry Pi, the user has FULL ACCESS to the hard drive or equivalent, so can update things as they please.
It's the things in the middle, like the Nexus 7, that are the problem. If I can download apps, and get access to the source, then that's fine with GPL2. If I can cross-compile the source and replace the original version of the app with my version that's okay with GPL3 too. That's probably possible with the Nexus. It's probably NOT possible with the iPad.
And that is the crux of the problem with these locked systems. The LGPL requires that you have the ability to modify PART of the app. So if you can't replace the LGPL library (like you probably can't on an iPad), then the LGPL is useless for iPad apps.
I think the trouble with your view is that your definition of "embedded" is very different from most. To me, the Pi is very much an open system - I have full access to the hard disk. Its small size makes it very easy to embed it in a box and make physical access difficult, to the extent that it would be reasonable to call it an embedded system WHEN PART OF SOMETHING ELSE, but the Pi on its own is, imho, absolutely NOT an embedded system - as I say, it's an OPEN system.
Cheers,
Digia acquires Qt Posted Aug 17, 2012 0:13 UTC (Fri) by hummassa (subscriber, #307) [Link]
> It's the things in the middle, like the Nexus 7, that are the problem. If I can download apps, and get access to the source, then that's fine with GPL2. If I can cross-compile the source and replace the original version of the app with my version that's okay with GPL3 too. That's probably possible with the Nexus. It's probably NOT possible with the iPad.
Yes, it's possible with the iPad, just it's not encouraged and Apple will try to break it with every update. That is what jailbreaking is: running in the iPad software not signed by Apple.
> I think the trouble with your view is that your definition of "embedded" is very different from most.
I think your definition is different from "most", but "most" is a weasel word. I'll say that you and krake just are telling different things about different things that both of you *think* can be called by the same name ("embedded systems") and the discussion will get nowhere, because you lack a common vocabulary to discuss issues with...
LGPL Libraries in Embedded Devices Posted Aug 11, 2012 17:48 UTC (Sat) by scottt (subscriber, #5028) [Link]
> Given the raising importance of embedded and mobile, one might as well assume that LGPL is GPL. Nothing inherently wrong with that, but it does mean LGPL software is less commercially adopted.
I hope you can take one look at the link below and realize this reasoning is false: http://opensource.apple.com/release/ios-433/
To state it explicitly, Webkit is an example of an LGPL licensed library that is enormously successful in mobile. Likewise for "GPL with Linking exceptions" licensed libraries like GNU libstdc++. LGPL licensed libraries are shipped in every copy of Apple and Google's current mobile products.
LGPL Libraries in Embedded Devices Posted Aug 11, 2012 19:31 UTC (Sat) by mikov (subscriber, #33179) [Link]
The LGPL requires that the end user be able to upgrade the library independent from the app. Either by replacing the shared lib or by relinking. You can figure out for yourself whether that requirement can be met on an embedded system or the iPhone.
LGPL Libraries in Embedded Devices Posted Aug 11, 2012 21:01 UTC (Sat) by Jonno (subscriber, #49613) [Link]
> The LGPL requires that the end user be able to upgrade the library independent from the app. Either by replacing the shared lib or by relinking.
Yes, but it does *not* require you to be able to run the "upgrade" on the same HW (so providing the app binary or object files together with the library source is enough, even if you can't put the modified library into the embedded HW).
LGPL Libraries in Embedded Devices Posted Aug 11, 2012 21:22 UTC (Sat) by mikov (subscriber, #33179) [Link]
That is highly debatable. IANAL, but is not obvious to me at all after from reading the LGPL. Can you point to a trustworthy source which supports that interpretation?
As a counter point, at the very minimum, the Mono and QT owners don't seem to believe that you can escape your LGPL responsibilities in that way. E.g. see http://www.mono-project.com/FAQ:_Licensing
Don't get me wrong, I would love it if the legal interpretation of the LGPL allows that, even though it it also strikes me as "wrong" in the moral sense. Clearly the notion of upgrading a library is meaningless if you can't actually run the result.
LGPL Libraries in Embedded Devices Posted Aug 11, 2012 22:58 UTC (Sat) by khim (subscriber, #9252) [Link] As a counter point, at the very minimum, the Mono and QT owners don't seem to believe that you can escape your LGPL responsibilities in that way. E.g. see http://www.mono-project.com/FAQ:_Licensing It's the same story as with MySQL AB: they need this FUD to actually sell commercial licenses! Find similar FUD on the site of someone who does not use LGPL or GPL as club to sell you commercial license - then you'll have a point. That is highly debatable. IANAL, but is not obvious to me at all after from reading the LGPL. Can you point to a trustworthy source which supports that interpretation? Have you missed the previous pointer? I can repeat it: http://opensource.apple.com/release/ios-433/. Android and iOS (and countless other embedded systems like webOS and other) include WebKit as one of it's cornerstones. WebKit uses LGPL. End of discussion. P.S. Note that LGPL 2.x and LGPL 3.x are quite different in this regard. That's why Android does not include libstdc++'s shared library but includes WebKit's shared library. Think about it. And Gtk uses LGPL 2.1, not LGPL 3.0
LGPL Libraries in Embedded Devices Posted Aug 13, 2012 21:14 UTC (Mon) by paulj (subscriber, #341) [Link]
If the point you're responding to can be disregarded because it is made by organisations who have it in their commercial interest to argue for one interpretation of the LGPL, such as MySQL, then how is your point any different? For your argument relies on us believing Apples' interpretation, which suits them commercially just as much, by allowing them to re-use LGPL code with fewer obligations than otherwise?
The LGPLv2 certainly does appear to want the end-user recipient of the software to be able to modify the software. However, its language doesn't appear to have envisaged locked-down hardware. How that all works out, well there's one "organisation" whose opinion really counts on this - but no one has brought it to court yet. (The GPLv2 seems to be more clear about requiring installation scripts, yet no Linux kernel copyright holders have taken any action against various vendors of locked-down hardware).
The (L)GPLv3 was meant to address that locked-down hardware loop-hole, as you know.
LGPL Libraries in Embedded Devices Posted Aug 14, 2012 17:30 UTC (Tue) by khim (subscriber, #9252) [Link] If the point you're responding to can be disregarded because it is made by organisations who have it in their commercial interest to argue for one interpretation of the LGPL, such as MySQL, then how is your point any different? For your argument relies on us believing Apples' interpretation, which suits them commercially just as much, by allowing them to re-use LGPL code with fewer obligations than otherwise? Because stakes are very different. If MySQL is caught in a lie and even brought to the court the biggest penalty they can get is public slap on the wrist: there are no penalty for writing incorrect facts on your websites - especially if you can not prove malicious intent (you can not get much for negligence). If Apple is caught in lawsuit with LGPL violation then it loses the central piece of MacOS and iOS. The (L)GPLv3 was meant to address that locked-down hardware loop-hole, as you know. Exactly. And this is how GPLv3 cleared the confusion. Recall the exceptio probat regulam in casibus non exceptis principle. The very fact that GPLv3 was needed to explicitly close the aforementioned loophole means that loophole is valid - otherwise why change anything there at all?
LGPL Libraries in Embedded Devices Posted Aug 16, 2012 13:02 UTC (Thu) by Wol (guest, #4433) [Link]
The fact that GPLv3 closed the loophole does NOT mean it is valid. We haven't had a court case, which could conclude it is invalid.
What it does mean is the loophole is plausible. To prevent it being tested and found valid, v3 shuts it down.
Cheers,
LGPL Libraries in Embedded Devices Posted Aug 16, 2012 21:45 UTC (Thu) by khim (subscriber, #9252) [Link] The fact that GPLv3 closed the loophole does NOT mean it is valid. We haven't had a court case, which could conclude it is invalid. After this? And this? And this? Dream on. The question is not simply about GPLv3 text per se. The question is about presentation. FSF basically always presented GPLv3 as our weapon against "tivoization and Treacherous Computing" not as simple clarification. That's why now if you want to prove that loophole does not exist in GPLv2.1 you must first go to court and prove that you interpretation of the license is somehow have more weight then the interpretation of the same license made by people who wrote said license in first place! Does it look to you like a sensible course of actions?
LGPL Libraries in Embedded Devices Posted Aug 16, 2012 19:18 UTC (Thu) by mikov (subscriber, #33179) [Link]
I think there is a huge problem with your reasoning.
MySQL, Trolltech, Xamarin, etc, are the actual copyright holders of the sources they release under LGPL. Certainly they have the moral right to dictate the terms of the distribution. This is how they interpret the LGPL with respect to their own source. Their intent is what matters, at least ethically.
You might argue that in a court of law you could get away with violating their intent because the license they chose does not clearly represent it. I don't know if that is a valid legal argument or not, especially considering that they have made their intent clear. But it is not morally valid.
In a similar vein, if I release my software under LGPL, it doesn't prevent me from simultaneously distributing it under different license myself. I am not exactly sure which parts of WebKit are copyrighted by Apple, under what terms, etc.
Iff WebKit is only licensed under LGPL, I don't see how Apple satisfies the requirements for re-linking even nominally.
LGPL Libraries in Embedded Devices Posted Aug 16, 2012 21:29 UTC (Thu) by khim (subscriber, #9252) [Link] You might argue that in a court of law you could get away with violating their intent because the license they chose does not clearly represent it. Absolutely. That's why companies spend millions on license creation. Intent only matters if text of the license itself have no clear legal meaning. Otherwise why bother with all these expenses if owner can change rules at any time by publishing new interpretation of the license? You can give additional permissions at any time (it effect you are just creating brand new license which does not affect anyone who does not use your newfound generosity), but additional restrictions... that's entirely different thing. And the ability to actually install new library on the target system is most definitely new restriction (from the POV of distributor, not from POV of end user!). I don't know if that is a valid legal argument or not, especially considering that they have made their intent clear. It really depends on many things. They have not even added this explanation to the downloadable package, they have not made any movements to make sure potential user will actually see (let alone agree) to this novel interpretation, etc. Hard to see this tightening of the license valid. It may even be considered extortion in some jurisdictions if the other side will prove that it got the software before the appropriate entry in FAQ was added. But it is not morally valid. Moral is in eyes of the beholder. It differs from person to person and from society to society. That's why we need all the laws, treatises and licenses: to decide what to do when two persons claim opposite things yet both feel they are right. Iff WebKit is only licensed under LGPL, I don't see how Apple satisfies the requirements for re-linking even nominally. It does not. Why should it? Re-linking requirements is just one option. There are others. For example 2b: Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. Note how this requirements says literally nothing about your ability to actually put this library on the user's computer system, it just dictates that if library is somehow found a way there then it must be used. And yes, WebKit is most definitely available only under LGPL (see Wikipedia for the explanation WRT why). Apple is not sole copyright holder by far.
LGPL Libraries in Embedded Devices Posted Aug 11, 2012 23:35 UTC (Sat) by Jonno (subscriber, #49613) [Link]
> IANAL, but is not obvious to me at all after from reading the LGPL.
I'm not either, but you should probably take another look at LGPL v2.1 section 6, which is the section giving you the additional right to create a combined work under a license other than LGPL (eg proprietary).
The first paragraph makes clear that you get these rights iff you follow the rest of paragraph 6. It then makes some requirements about the licence of the combined work. It says nothing of what the user must be able to do, only what you must not forbid the user to do.
The second paragraph deals exclusively with copyright notices, entirely irrelevant to this case.
6a makes a series of requirements ending with "then relink to produce a modified executable". It says nothing about putting said executable on any particular hw.
6b does implicitly assume that the user is able to install a modify library. There seems to be different legal opinions if you can fulfil this paragraph if you ship your software on hardware where the user is not able to do so, but that is irrelevant, as 6b is an *optional* *alternative* to 6a. If you do follow 6a you can completely ignore 6b.
6c through 6e gives you optional alternatives as to when and how to provide the 6a and 6b requirements, entirely irrelevant to this case.
The next paragraph deals with the tools needed to *generate* the executable. It says nothing about the tools needed to putting said executable on any particular hw.
The last paragraph only states that you can't avoid fulfilling the requirements above because of a different license makes contradicting demands.
To conclude, in some embedded systems you might have a problem fulfilling 6b (depending on legal interpretation), but if you provide the object files (or source code) to the non-LGPL'ed parts together with the source code to the LGPL'ed parts you are fulfilling 6a, so 6b is of no issue.
LGPL Libraries in Embedded Devices Posted Aug 14, 2012 22:22 UTC (Tue) by mikov (subscriber, #33179) [Link]
Thanks, this makes sense. I wonder though, how does Apple satisfy the requirements for mobile Safari? I don't think they ship object files, etc.
LGPL Libraries in Embedded Devices Posted Aug 12, 2012 1:43 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
> Clearly the notion of upgrading a library is meaningless if you can't actually run the result.
If that were the case, then there would be no need for the 'anti-tivo' provisions of the GPLv3 as the existing v2 requirements could be used to prevent the devices from being locked down.
There is nothing you can do with GPLv2 code that you can't also do with LGPLv2.x code, so the fact that GPLv2 code (like the kernel) is widely used in embedded devices, exactly of the type that you are concerned about, should be clear precedence showing that you don't have to worry about that.
LGPL Libraries in Embedded Devices Posted Aug 12, 2012 4:09 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
"There is nothing you can do with GPLv2 code that you can't also do with LGPLv2.x code"
If that were true then LGPLv2 wouldn't need the explicit GPLv2 relicense clause.
LGPL Libraries in Embedded Devices Posted Aug 12, 2012 4:34 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
That has to do with coopying bits of code into other projects, allowing the code to flow from LGPL projects into GPL projects.
If you are just working with the project itself, not copying bits of it elsewhere. Then that clause would not be needed.
David Lang
LGPL Libraries in Embedded Devices Posted Aug 12, 2012 4:42 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
So firstly, you're wrong about that. But secondly, if "There is nothing you can do with GPLv2 code that you can't also do with LGPLv2.x code" then there'd be no additional restrictions in LGPLv2.x and you'd be able to copy it into GPLv2 code without requiring the relicensing clause.
LGPL Libraries in Embedded Devices Posted Aug 12, 2012 5:09 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
Ok, being pedantic.
"Other than copying the code into programs with a different license than the original, there is nothing that you can do with a GPLv2 binary that you can't do with a LGPLv2 binary"
does that cover the bases sufficiently?
and if there is something you can do with a GPLv2 binary that you can't do with a LGPLv2 binary, it doesn't matter because the LGPL allows you to convert the license to GPLv2 and then you only have to comply with the GPLv2
so any worries that you can't use the LGPLv2 code in an embedded system are foolish in light of the extensive use of GPLv2 code (busybox and the linux kernel being two HUGE example) in exactly that space.
LGPL Libraries in Embedded Devices Posted Aug 12, 2012 5:21 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
LGPLv2.1 has requirements that GPLv2 doesn't have. You can't link GPLv2 code into proprietary binaries. So there's plenty of code in embedded devices that's distributed under the terms of LGPLv2.1, and so you have to be concerned about the additional requirements that LGPLv2.1 contains.
LGPL Libraries in Embedded Devices Posted Aug 12, 2012 13:23 UTC (Sun) by khim (subscriber, #9252) [Link] LGPLv2.1 has requirements that GPLv2 doesn't have. Rilly? This means all Linux distributions are blatant copyright violators because they link LGPL2.1-covered crt1.o with mass of GPLv2-licensed and GPLv3-licensed code and GPL is quite adamant about “any further restrictions”. Usual “system libraries” excuse does not help here because it's only applicable “unless that component itself accompanies the executable”. Sorry, but no: LGPLv2.1 contains only additional permissions. So there's plenty of code in embedded devices that's distributed under the terms of LGPLv2.1, and so you have to be concerned about the additional requirements that LGPLv2.1 contains. Only if you use additional options given to you by LGPLv2.1… Yes, they are conditional, but so what? It's still additional options, not additional restrictions. If you feel safe distributing GPLv2 code (such as Linux kernel) then you should feel yourself equally safe distributing LGPLv2.1 code.
LGPL Libraries in Embedded Devices Posted Aug 12, 2012 14:57 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
That's why LGPLv2.1 has an explicit clause that allows you to relicense it as GPLv2.
LGPL Libraries in Embedded Devices Posted Aug 12, 2012 15:52 UTC (Sun) by BlueLightning (subscriber, #38978) [Link] Rilly?The word is "really". Please don't intentionally mis-spell words, it does not lend credence to your argument.
Digia acquires Qt Posted Aug 11, 2012 8:47 UTC (Sat) by jospoortvliet (subscriber, #33164) [Link] If GTK fails it isn't going to make QT better or make KDE more popular. Free software isn't a zero sum game.Duh, even IF that one developer on GTK would move to Qt, it wouldn't make much difference on the few hundred people already working on Qt ;-) But I do, like the others here, wonder why you come up with that response to Boudewijn?!?
Digia acquires Qt Posted Aug 11, 2012 10:09 UTC (Sat) by anselm (subscriber, #2796) [Link] It stands to reason that if GTK, due to developer scarcity or for whatever other reason, stops being a viable proposition for the development of graphical applications for Linux, people will eventually have to use something else instead. Of course whether that would be Qt or something different altogether, or whether that would be a reason for exultation on anybody's part, is an open question.
Digia acquires Qt Posted Aug 9, 2012 22:21 UTC (Thu) by armijn (subscriber, #3653) [Link]
According to press releases I saw this deal excludes some 500 software patents, which are sold to Vringo, who are currently suing Google for patent infringement. Makes you wonder what's coming up next...
|
|||||||||||||