 |
LGPL, Java, Links, and Executables
Posted by rubys on July 18, 2003 at 07:59 AM | Comments (5)
There has been a lot of confusion regarding LGPL and how it applies to Java. This question is getting a lot more focus recently as it hit slashdot. ;-)
Hopefully, the end result will be a clarification. Hosted not by the potential benefiaries, as that opens up the possibility of such statements being perceived as self serving and open to question.
The terms 'link' and 'executable' have clear meanings in languages like 'C'. It would be real nice to have an unambiguous interpretation of how these concepts should map to Java.
Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
Viral LGPL?
Sam--I agree completely. I was going to write my own blog, but Dan suggested I rant in response to you.
Even in the C developer community, I know plenty of developers who are told by their companies that they can't use LGPL code because their lawyers can't figure out what the license means. A few years back, I sent a comment to RMS, and he fired back that they've made it as clear as it can. Well, I guess not.
A Java jar file is not linked in any way that's remotely analogous to the linking of a C executable. It's loaded by the class loader at runtime. It seems to me that the acid test for "linking" is really whether the application can be shipped without the library in question. Java applications certainly can; the user can install them separately, if it comes to that. (Not so much different than shared libraries, from this limited perspective). Or an installer could download the JAR files at install time. Or you could even load them over the network at run-time, if you were willing to deal with the security issues. There's nothing analogous to the C linker, which is really the central concept in the LGPL
So the LGPL clearly needs to be clarified. I wonder if the present dispute isn't in fact just smoke and hot air? In the posting on poi-dev, Andrew Oliver asks Dave Turner about the FSF's interpretation of a Java import of an LGPL class. Turner only says "This sort of linking falls under section 6 of the LGPL." Which, to me, says nothing at all. Is he saying it's OK? Is he saying it isn't? (Did Turner say more that Oliver didn't quote?) An update by Brad Kuhn to the slashdot article appears to say "it's OK."
But it would be nice to know. This sort of confusion certainly doesn't help anyone, least of all the FSF.
Posted by: mikel on July 18, 2003 at 10:59 AM
-
Confusing Licenses
A definite statement like Bradley Khun's on /. is very helpful to define the case as it is today; however, one problem with the FSF and perhaps RMS in particular is that so much is open to interpretation it scares people off.
I for one prefer the Apache license. It is clear and to the point. Perhaps there is a lesson in here for developers who wish to see their work picked up in as many places as possible: use the apache license.
Posted by: comforteagle on July 18, 2003 at 01:04 PM
-
More clarification...
http://www.theinquirer.net/?article=10574
"Clear alternative from the OSI: Larry Rosen, the well known general counsel and secretary for the Open Source Initiative has definitively stated that with regards to its reciprocity provisions, "The Open Software License (OSL) can be used for the same purposes as the LGPL and the GPL".
Rosen further clarifies the matter by offering the Academic Free License, which "addresses issues of patent, trademark, warranty, jurisdiction and venue, contributor recognition, etc., in ways entirely consistent with the "BSD" philosophy of open source. AFL-licensed software can be used in combination with any other software, open source *or* proprietary, for any purpose whatsoever, including to create derivative works. This new version of the AFL also helps eliminate possible confusion between academic-style licenses and reciprocal licenses [see, for example, the GPL, www.fsf.org/licenses/gpl.html, and the Open Software License (OSL), www.rosenlaw.com/osl2.0.html. Reciprocity requires that any Derivative Works be licensed under the same license as the Original Work. Reciprocal and non-reciprocal open source licenses ought to be the same -- except with respect to provisions dealing with reciprocity. Therefore, the new AFL is identical to the OSL except that the AFL does not contain a reciprocity provision. A redlined comparison of AFL2.0 and OSL2.0 is at http://rosenlaw.com/afl2.0-redline.pdf."
The inconsistencies surrounding the LGPL and GPL are a continued risk to the software community at large. The OSL and AFL resolve the matter quite thoroughly."
Posted by: comforteagle on July 21, 2003 at 12:25 PM
-
ok, what's equivalent to LGPL?
IANAL, so can someone please explain what license grants both the open-source community and proprietary developers the right to use a Java library while requiring modifications to be returned to the library developer(s)? Does the OSL guarantee this w/o being "viral"?
Posted by: escher9694 on July 28, 2003 at 12:25 PM
-
网络营销软件
网络营销软件
网络营销软件
群发软件
群发软件
---
群发软件
网络营销软件网络推广软件网站推广软件下载引擎登陆软件论坛群发软件下载免费版
论坛群发软件,信息群发软件,群发软件,网络营销软件,网站推广软件引擎登陆软件下载
网站排名软件网站推广软件信息群发软件博客群发软件论坛群发软件免费下载
群发软件,信息群发软件,博客群发软件,论坛群发软件,免费下载:群发软件系统
推广小助手破解版
论坛群发软件
网站排名软件
群发软件
推荐给你很好的群发软件和信息群发软件和供求群发软件
推荐给你很好的群发软件和信息群发软件和供求群发软件博客群发软件网络营销软件网络营销软件
网站排名软件网站排名软件网站优化软件信息群发软件信息群发软件信息群发软件论坛群发软件网站推广软件网站推广软件博客群发软件博客群发软件
群发软件群发软件博客群发软件论坛群发软件网络营销软件论坛群发软件
信息群发软件推广软件网站推广软件网络营销软件网站推广软件群发软件网站排名软件网站推广软件博客群发软件论坛群发软件群发软件网站排名软件网站推广软件博客群发软件论坛群发软件
网站排名软件
博客群发软件
网站排名软件
网站推广软件
群发软件信息群发软件
免费论坛群发软件
论坛群发软件
网站排名软件
免费博客群发软件
网站推广软件
群发软件
博客群发软件
网站排名软件
网站推广软件
群发软件信息群发软件
免费论坛群发软件
论坛群发软件
网站排名软件
免费博客群发软件
博客群发软件
信息群发软件
论坛群发软件
信息群发软件
博客群发软件
qq群发软件
邮件群发软件
博客群建软件
企业名录搜索软件
信息群发软件
邮件群发软件
论坛群发软件
博客群发软件
网站推广软件
网络营销软件
Posted by: xinxi123 on December 04, 2007 at 01:54 AM
|
java.net RSS Feeds
