User: Password:
|
|
Subscribe / Log in / New account

LGPL Libraries in Embedded Devices

LGPL Libraries in Embedded Devices

Posted Aug 11, 2012 21:22 UTC (Sat) by mikov (subscriber, #33179)
In reply to: LGPL Libraries in Embedded Devices by Jonno
Parent article: Digia acquires Qt

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.


(Log in to post comments)

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,
Wol

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 (subscriber, #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 (subscriber, #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 (subscriber, #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.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds