Digia acquires Qt
Digia acquires Qt
Posted Aug 10, 2012 16:58 UTC (Fri) by rsidd (subscriber, #2582)In reply to: Digia acquires Qt by drag
Parent article: Digia acquires Qt
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.
Posted Aug 10, 2012 21:46 UTC (Fri)
by mikov (guest, #33179)
[Link] (42 responses)
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).
Posted Aug 10, 2012 22:16 UTC (Fri)
by gidoca (subscriber, #62438)
[Link] (2 responses)
Posted Aug 11, 2012 8:49 UTC (Sat)
by jospoortvliet (guest, #33164)
[Link] (1 responses)
Posted Aug 11, 2012 8:53 UTC (Sat)
by rsidd (subscriber, #2582)
[Link]
Posted Aug 11, 2012 10:07 UTC (Sat)
by krake (guest, #55996)
[Link] (38 responses)
Why would that be? I am not aware of any clause in the LGPL prohibiting its deployment on embedded or mobile devices.
Posted Aug 11, 2012 15:25 UTC (Sat)
by mikov (guest, #33179)
[Link] (37 responses)
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.
Posted Aug 11, 2012 15:53 UTC (Sat)
by krake (guest, #55996)
[Link] (12 responses)
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.
Posted Aug 14, 2012 21:14 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (11 responses)
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,
Posted Aug 15, 2012 7:12 UTC (Wed)
by krake (guest, #55996)
[Link] (10 responses)
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.
Posted Aug 16, 2012 12:59 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (9 responses)
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,
Posted Aug 16, 2012 13:34 UTC (Thu)
by krake (guest, #55996)
[Link] (8 responses)
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.
Posted Aug 16, 2012 15:01 UTC (Thu)
by mikov (guest, #33179)
[Link] (5 responses)
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.
Posted Aug 16, 2012 16:01 UTC (Thu)
by krake (guest, #55996)
[Link] (4 responses)
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.
Posted Aug 16, 2012 16:50 UTC (Thu)
by mikov (guest, #33179)
[Link] (3 responses)
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.
Posted Aug 16, 2012 18:02 UTC (Thu)
by krake (guest, #55996)
[Link] (2 responses)
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.
Posted Aug 16, 2012 19:11 UTC (Thu)
by mikov (guest, #33179)
[Link] (1 responses)
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.
Posted Aug 16, 2012 19:51 UTC (Thu)
by krake (guest, #55996)
[Link]
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.
Posted Aug 16, 2012 23:25 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (1 responses)
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,
Posted Aug 17, 2012 0:13 UTC (Fri)
by hummassa (subscriber, #307)
[Link]
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...
Posted Aug 11, 2012 17:48 UTC (Sat)
by scottt (guest, #5028)
[Link] (23 responses)
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.
Posted Aug 11, 2012 19:31 UTC (Sat)
by mikov (guest, #33179)
[Link] (22 responses)
Posted Aug 11, 2012 21:01 UTC (Sat)
by Jonno (subscriber, #49613)
[Link] (21 responses)
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).
Posted Aug 11, 2012 21:22 UTC (Sat)
by mikov (guest, #33179)
[Link] (20 responses)
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.
Posted Aug 11, 2012 22:58 UTC (Sat)
by khim (subscriber, #9252)
[Link] (8 responses)
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. 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
Posted Aug 13, 2012 21:14 UTC (Mon)
by paulj (subscriber, #341)
[Link] (7 responses)
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.
Posted Aug 14, 2012 17:30 UTC (Tue)
by khim (subscriber, #9252)
[Link] (6 responses)
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. 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?
Posted Aug 16, 2012 13:02 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (1 responses)
What it does mean is the loophole is plausible. To prevent it being tested and found valid, v3 shuts it down.
Cheers,
Posted Aug 16, 2012 21:45 UTC (Thu)
by khim (subscriber, #9252)
[Link]
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?
Posted Aug 16, 2012 19:18 UTC (Thu)
by mikov (guest, #33179)
[Link] (1 responses)
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.
Posted Aug 16, 2012 21:29 UTC (Thu)
by khim (subscriber, #9252)
[Link]
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!). 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. 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. It does not. Why should it? Re-linking requirements is just one option. There are others. For example 2b: 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.
Posted Sep 12, 2019 19:20 UTC (Thu)
by owendelong (guest, #134384)
[Link] (1 responses)
1. WebKit is licensed under a combination of LGPL 2.0 and BSD licenses. (https://webkit.org/licensing-webkit/)
There are significant differences in the LGPL 2 and 3 versions as well, so it is important to look at which LGPL the library(ies)
The sticking point in LGPL 2.0 is section 6. You are required to release your object code such that it can be relinked with the library or a compatibly modified library. The question is whether or not you have to make it possible for the end-user to load that newly linked binary onto the device released with your application built into it.
That's going to have to be one for the courts to decide. IANAL, but I think there's a case to be made that the clear intent is for the user to be able to then use the resulting binary. It's pretty clear that GPL and LGPL did NOT have embedded devices in mind when they were issued and that LGPL is written to provide some comfort to shared library uses on desktop and server style systems, but less interested in providing reasonable or useful relief to embedded devices.
The similar sticking point in LGPL 3.0 is a little better written and cleaner IMHO, but it's still fairly awkward. In LGPL 3.0, it's Section 4, specifically 4.d.0. (the 4.d.1 alternative doesn't really apply to embedded since there's no OS and no shared library facility in most cases). There's also some extra obligations under 4.e that could be a bit sticky in some situations. (You are required to provide "Installation Information", but only if you would otherwise be required to provide such information under section 6 of the GNU GPL and only to the extent that such information is necessary to install and execute a modified version of the "Combined Work"...
In other words, it looks like LGPL3.0 has taken specific aim at this theory on LGPL2 (that you advance using WebKit as an example) that there's no requirement to be able to run it on the device afterwards. (Specifically requiring the necessary instructions to "install and execute" seems to me that it would imply those two things must be possible.
Posted Sep 12, 2019 22:23 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link]
Don't see how. WebKit is a fork of KHTML under the LGPL license. They didn't choose LGPL actively for an original codebase. They inherited it. Apple doesn't own all of the copyright here for the license to not apply to them
Posted Aug 11, 2012 23:35 UTC (Sat)
by Jonno (subscriber, #49613)
[Link] (1 responses)
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.
Posted Aug 14, 2012 22:22 UTC (Tue)
by mikov (guest, #33179)
[Link]
Posted Aug 12, 2012 1:43 UTC (Sun)
by dlang (guest, #313)
[Link] (8 responses)
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.
Posted Aug 12, 2012 4:09 UTC (Sun)
by mjg59 (subscriber, #23239)
[Link] (7 responses)
If that were true then LGPLv2 wouldn't need the explicit GPLv2 relicense clause.
Posted Aug 12, 2012 4:34 UTC (Sun)
by dlang (guest, #313)
[Link] (6 responses)
If you are just working with the project itself, not copying bits of it elsewhere. Then that clause would not be needed.
David Lang
Posted Aug 12, 2012 4:42 UTC (Sun)
by mjg59 (subscriber, #23239)
[Link] (5 responses)
Posted Aug 12, 2012 5:09 UTC (Sun)
by dlang (guest, #313)
[Link] (4 responses)
"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.
Posted Aug 12, 2012 5:21 UTC (Sun)
by mjg59 (subscriber, #23239)
[Link] (3 responses)
Posted Aug 12, 2012 13:23 UTC (Sun)
by khim (subscriber, #9252)
[Link] (2 responses)
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. 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.
Posted Aug 12, 2012 14:57 UTC (Sun)
by mjg59 (subscriber, #23239)
[Link]
Posted Aug 12, 2012 15:52 UTC (Sun)
by BlueLightning (subscriber, #38978)
[Link]
The word is "really". Please don't intentionally mis-spell words, it does not lend credence to your argument.
Digia acquires Qt
Digia acquires Qt
Digia acquires Qt
Digia acquires Qt
Digia acquires Qt
Digia acquires Qt
Digia acquires Qt
Can you quote the passage of the LGPL that says that FOSS software is relieved from the obligation that user are allowed to change the library?
Digia acquires Qt
Wol
Digia acquires Qt
You seem to agree that one can replace/upgrade a LGPL library on such a system. Which would usually imply that you also agree with my assessment that the parent comment's theory of it not being possible being false.
Digia acquires Qt
Wol
Digia acquires Qt
Just the SoC without any connectors?
Digia acquires Qt
Digia acquires Qt
Digia acquires Qt
Digia acquires Qt
If you want to modify any Free Software program on a Linux Live CD, you have to copy the software from CD to modifiable media, apply your changes, remaster the CD image and burn that new image.
Digia acquires Qt
Digia acquires Qt
Some systems detect updates on a server (or even boot through from server), some require remote access (e.g. SSH), some can be updated through a physically connected media, some need swapping of their system drive, some need to be powered down, connected to an updater device and reprogrammed through that.
Digia acquires Qt
Wol
Digia acquires Qt
LGPL Libraries in Embedded Devices
LGPL Libraries in Embedded Devices
LGPL Libraries in Embedded Devices
LGPL Libraries in Embedded Devices
LGPL Libraries in Embedded Devices
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
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?
LGPL Libraries in Embedded Devices
LGPL Libraries in Embedded Devices
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 (L)GPLv3 was meant to address that locked-down hardware loop-hole, as you know.
LGPL Libraries in Embedded Devices
Wol
LGPL Libraries in Embedded Devices
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.
LGPL Libraries in Embedded Devices
LGPL Libraries in Embedded Devices
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.
Iff WebKit is only licensed under LGPL, I don't see how Apple satisfies the requirements for re-linking even nominally.
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.
LGPL Libraries in Embedded Devices
2. WebKit is Copyrighted by Apple, so Apple can give themselves different licensing terms than they give everyone else.
Just because you release something under LGPL doesn't mean you have to limit yourself to complying with LGPL
in your use of that thing.
you use are released under.
LGPL Libraries in Embedded Devices
LGPL Libraries in Embedded Devices
LGPL Libraries in Embedded Devices
LGPL Libraries in Embedded Devices
LGPL Libraries in Embedded Devices
LGPL Libraries in Embedded Devices
LGPL Libraries in Embedded Devices
LGPL Libraries in Embedded Devices
LGPL Libraries in Embedded Devices
LGPL Libraries in Embedded Devices
LGPLv2.1 has requirements that GPLv2 doesn't have.
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
Rilly?
LGPL Libraries in Embedded Devices