LGPL has the issue of when you're linking to software which is LGPL it's basically impossible to say whether you're including LGPL code, some code from the headers may be included, some stubs may be included from the static .lib file and so on. LGPL is a compromise no one really wanted. The FSF themselves have stated that creating the LGPL was probably a mistake. No one will probably ever attack your for dynamically linking to a LGPL library and accidentally getting some LGPL code inserted into your binary as long as the LGPL library is replaceable the license accomplishes what it set out to do. Ambiguities like this is why companies prefer to pay for stuff. MIT, ZLIB and those are proven to be very permissible and used quite frequently in commercial software. Either should be fine if all you really want is for someone to use your code and still get some sort of credit.

Mona: I realize that the GPL is often called "viral," but what you quoted has nothing to do with the LGPL. The LGPL is very straightforward in this manner. Your link also doesn't address anything specifically related to GPL/LGPL interaction; while a consumer could release their altered version of his source under GPL (effectively forking it), this in no way affects anyone else's code unless they derive from the GPL fork--and in practice, I cannot think of a single situation where a fork occured over LGPL licensing issues. It's a non-issue.

Quote: LGPL has the issue of when you're linking to software which is LGPL it's basically impossible to say whether you're including LGPL code, some code from the headers may be included, some stubs may be included from the static .lib file and so on. LGPL is a compromise no one really wanted.

You are not supposed to link LGPL libraries statically under the standard license, but many organizations provide specific exceptions to this--Teem is a project I know of that includes a specific static linking exception. As for header files, at least under the LGPL v3 (I can't be arsed to look at v2, but I seem to recall it being the same), they are exempt. To wit:

3. Object Code Incorporating Material from Library Header Files.

The object code form of an Application may incorporate material from a header file that is part of the Library. You may convey such object code under terms of your choice, provided that, if the incorporated material is not limited to numerical parameters, data structure layouts and accessors, or small macros, inline functions and templates (ten or fewer lines in length), you do both of the following:

* a) Give prominent notice with each copy of the object code that the Library is used in it and that the Library and its use are covered by this License.
* b) Accompany the object code with a copy of the GNU GPL and this license document.

In other words--a LGPL library user's credits section should say "using library FooBar under the GNU Lesser General Public License, v3", and they should package copies of the GPL and LGPL with it (clearly marking what code is under this licensing agreement). Non-issue.

Quote: MIT, ZLIB and those are proven to be very permissible and used quite frequently in commercial software. Either should be fine if all you really want is for someone to use your code and still get some sort of credit.

I don't mean to be a jerk, but did you read the original post? I quote: My intent is to release this library as open source or public domain so that anyone can use it and to get, hopefully, some peer review or have other developers add code to it for the benefit of improving the code and my own know how. This is, in essence, exactly what the LGPL is for.

The point of the LGPL is to ensure that people using your libraries contribute back any changes they have made to your library. I don't personally care about the "freedom" aspect of the LGPL, but rather its pragmatism--they change your libraries that you provide, you may benefit from their changes.

Quote:
You are not supposed to link LGPL libraries statically under the standard license

LGPL allows for static linking. The only goal of LGPL is to make it so that the user can link in a new version or replace the LGPL library in the executable. Anyways, I wouldn't really be interested as long as I can't see an actual case that's been tried by a judge. Since I can't understand it, I don't trust it.

Quote:
-they change your libraries that you provide, you may benefit from their changes.

That's only true if they redistribute the work. You can get around it by only distributing the output, i.e via a server.


I'm not a GPL/LGPL expert, I just don't like the license in general. It's probably the only open source one that's actively enforced by a legal team though so it might be the only one with any actual teeth.

Quote: Original post by Edward Ropple
The point of the LGPL is to ensure that people using your libraries contribute back any changes they have made to your library. I don't personally care about the "freedom" aspect of the LGPL, but rather its pragmatism--they change your libraries that you provide, you may benefit from their changes.

Is it just me or is this idea silly? The idea that you have to license your software such that any changes to the code must be given back to the community seems wrong to me. I would want to make my users feel compelled to help the library, but I would never see the point in forcing them to do so.

For example, I download your library and make a few changes that are only really applicable to my application. Without the rest of my code (which isn't in your library nor an extension of your library), the edits won't make sense to anyone but me. Yet according to the LGPL I'm supposed to surrender my changes back to you anyway. So now your library contains worthless code (except to me), unless the LGPL requires me to give up my library as well, in which case you have a viral license because it is now taking my code and making it part of your library (I don't know if it does or not hence the 'unless' part of that sentence).

I strongly advise all people to release under something like MIT, MS-PL, or another unrestrictive license and simply encourage users to contribute back changes made. To me that seems to make a much friendlier community around your code. I know I consciously avoid any code licensed under either GPL or LGPL simply for this forced licensing and I'm sure others do as well.

Quote: LGPL allows for static linking. The only goal of LGPL is to make it so that the user can link in a new version or replace the LGPL library in the executable.

Yes, but then you have to provide your application in object code form. Teem, among others, specifically waives this requirement. By "not supposed", I meant the distribution of executable applications directly. Sorry for not being clear though.

Quote: Anyways, I wouldn't really be interested as long as I can't see an actual case that's been tried by a judge.

gpl-violations.org v. D-Link, District Court of Frankfurt, Germany - not a US case, but it does establish the validity of the GPL in the EU at the least.

From Groklaw: A GPL Win in Michigan - DrewTech v. SAE. While it is not specifically about the particulars of the GPL, the copyright underlying GPL software has been recognized as valid.

SFLC v. Monsoon - not settled yet, but I don't think there's a lawyer not working for Monsoon who thought Monsoon had any chance here. I don't think Monsoon's lawyers thought so, either: Monsoon settled. Makes me think you've got teeth in that license.

Quote: Since I can't understand it, I don't trust it.

There's nothing particularly difficult in the GPL or LGPL. The specific terminology is stated right up front.

Quote: Is it just me or is this idea silly? The idea that you have to license your software such that any changes to the code must be given back to the community seems wrong to me. I would want to make my users feel compelled to help the library, but I would never see the point in forcing them to do so.

I did not say I would use it for my code. My own code is released under various licenses; RogueSDL is LGPL because if someone else extends it I want to be able to avail myself of these extensions, but CLiMoMA is under the MIT License because the program is small enough and of so specific functionality that it would be foolish to restrictively license it (and the original code was under the MIT License to begin with; no reason to lock the original developers out).

I'm not recommending something based on my own favorite license. I'm recommending a license that does what he wants it to do. Did you read what the OP wants? Again I quote--he wants to "have other developers add code to it for the benefit of improving the code". This is, open-and-shut, what the LGPL is for.

Quote: For example, I download your library and make a few changes that are only really applicable to my application. Without the rest of my code (which isn't in your library nor an extension of your library), the edits won't make sense to anyone but me. Yet according to the LGPL I'm supposed to surrender my changes back to you anyway. So now your library contains worthless code (except to me), unless the LGPL requires me to give up my library as well, in which case you have a viral license because it is now taking my code and making it part of your library (I don't know if it does or not hence the 'unless' part of that sentence).

Your example is not a good one because you misunderstand the point of the LGPL. You are required to distribute changes to the source of an LGPL library. This does not mean they have to accept it. If an LGPL library wants to incorporate it, great. If the changes are useless in the mainline library, that's fine. You've fulfilled your part of the license, and whether they pick it up for inclusion into mainline is irrelevant. All you have to do is say "I've changed the library, this is how I've changed it." The value of the changes to anyone other than you doesn't matter one bit.

How is this "bad" in any way? It's simply fair. I agree that the GPL is a bit much, but the LGPL is simple fairness.

As for "virality"--the LGPL does not require you to disclose source to any of your own parts of the application, even if you include header files, so long as the distribution contains a notification that you are using a LGPL library and includes copies of the GNU GPL and LGPL for reference.

Quote: I strongly advise all people to release under something like MIT, MS-PL, or another unrestrictive license and simply encourage users to contribute back changes made. To me that seems to make a much friendlier community around your code.

Your "strong advice" doesn't address what the OP said he wanted. (As it happens I mostly agree with you, but that's not the point here.)

Quote: I know I consciously avoid any code licensed under either GPL or LGPL simply for this forced licensing and I'm sure others do as well.

That's rather foolish of you. Not GPL so much, as that affects your code directly, but the LGPL only requires returning the favor of granting use of code. It's pretty basic respect and kindness, and I agree that it would be nice if requiring it wasn't considered necessary, but I can entirely understand people not wanting others to profit off of work that isn't their own without contributing changes back.

Quote: Original post by asp_
Anyways, I wouldn't really be interested as long as I can't see an actual case that's been tried by a judge. Since I can't understand it, I don't trust it.

Huh?

I can't think of ANY of the major F/OSS licenses that have been through the complete legal process in the US. A few of them have been mentioned as a minor issue in a few lessor cases, but none have been put through the low courts, the appellate courts, and considered for review at the US Supreme Court.

As was mentioned, they have been addressed in other nations, but not here.

The closest case I know of is the BSD license back two decades ago (by AT&T and Berkeley), but even that was settled before the lower courts could give a ruling.


Of course, there are very few commercial licenses that have been used in completed court cases either.


Note that the GPL is very clear on its intent, and judges strongly consider the stated intent when ruling on contracts. Even if the contract were held invalid the standard copyright protections would remain in effect, which is more restrictive than the grants provided by the GPL.

Quote: Original post by Edward Ropple
Did you read what the OP wants? Again I quote--he wants to "have other developers add code to it for the benefit of improving the code". This is, open-and-shut, what the LGPL is for.

My point is that you can have the same scenario without forcing people to release their changes. I did read what the OP said and it is still my belief that you can release code under a less restrictive license like MIT and still have people return code changes to the library. I've had that happen on both of my moderately popular open source projects. Both are MIT and in both cases I have had people email me changes they have made to them.

Quote: How is this "bad" in any way? It's simply fair. I agree that the GPL is a bit much, but the LGPL is simple fairness.

I guess I'm more of a "good will" person. I don't believe in making people redistribute their changes. If they see value in the code, I trust that they will want to help the code and community be releasing their changes. Again it's just the difference of encouraging vs. forcing.

Quote: Your "strong advice" doesn't address what the OP said he wanted.

Yes, my advice does. It is an open source license that would allow for the scenario asked for. Just because my recommendation doesn't require users to share changes doesn't mean that changes won't be returned to him. As I have seen with my own code, people who really like what you release will be inclined to help expand it by giving back changes and improvements. You don't need to force people to contribute to get them to do so.

EDIT:
Also take into consideration what the OP said in their second post:

Quote: GPL is not what I'm looking for because i don't want to force users of my code to release their source code too.

So they have a desire to not force the release of source code from users. This would obviously not be possible with the LGPL since any changes to the code are, by the license, required to be open sourced.

Quote: As I have seen with my own code, people who really like what you release will be inclined to help expand it by giving back changes and improvements.

And others take advantage of your generosity. That's the point of the LGPL: to ensure fairness for all parties.

Quote: So they have a desire to not force the release of source code from users. This would obviously not be possible with the LGPL since any changes to the code are, by the license, required to be open sourced.

I take "their source code" to mean "code linked with the library", not "changes to the library itself". I assume that if he had meant changes to the library, he would have specified that, or likewise stricken LGPL.

Quote: Original post by Edward Ropple

Quote: As I have seen with my own code, people who really like what you release will be inclined to help expand it by giving back changes and improvements.

And others take advantage of your generosity. That's the point of the LGPL: to ensure fairness for all parties.

Because nobody would ever dare break the LGPL license. In seriousness there is no license you can put on there to stop those people. If someone doesn't want to give back then they won't no matter what license you put on your code.

I'll admit that there is no amount of arguing that could convince me that either GPL or LGPL are ever worth using, so I'll just leave the OP with the comments I've presented and let them choose which license they feel more aligns with what they want for their library.

Quote: If someone doesn't want to give back then they won't no matter what license you put on your code.

I imagine Monsoon thought the same until the SFLC came after them. How'd that go for them?

Quote: I'll admit that there is no amount of arguing that could convince me that either GPL or LGPL are ever worth using

Shortsighted and regrettable, but it is your choice.