AUG
19
2006

The In-Good-Faith License?

I've got some code around that I'm thinking about shuffling a bit and putting out in a library. But I can't find the right license. I basically want to say, "Try to give back any changes that you make in a sufficiently demonstable way." (i.e. patch to the publicly archived project list with a template of information that needs to be there)

Requirements for source distribution, a la [L]GPL, aren't really all that effective in actually making projects move forward and they're annoying for users of the library. At best, you end up with improved source on some random server or CD somewhere and the (proprietary) user is forced to distribute the library sources for. Despite RMS's take on the issue, I don't personally think that does users a lot of good.

What I'd like is to get the changes -- a patch, basically, in a good faith effort to contribute them back and for that to be an acceptable substitute for source distribution. What I haven't seen is a pre-existing license for that. LGPL is cumbersome for proprietary use. BSD is too permissive. Artistic comes pretty close but then says, "Or you can just change the name."

Thoughts?

(Note: Anything that I would release on such a license would be dual-licensed with one of the more vanilla licenses like LGPL, so there wouldn't be any license conflicts.)

Comments

I suggest licensing it the way the Free Software Foundation suggests:

http://www.gnu.org/copyleft/gpl.html#SEC4

The GPL is the best license in my opinion because it has strong copyleft protections so that improvements are shared back to the community. The GPL also ensures that your software will always remain free for users to enjoy. I also suggested leaving the "or (at your option) any later version" phrase because the FSF is working their butts off to make sure version 3 of the GPL will be the best tool we have in protecting the users' rights from the evils of software idea patents and treacherous computing.


By vladc at Sun, 08/20/2006 - 00:06

Go easy on the Kool Aid; I'm naturally familiar with the FSF's rhetoric. But the whole point of my entry was that I'm looking for something less, not more, restrictive than the LGPL.


By Scott Wheeler at Sun, 08/20/2006 - 11:33

The problem in your license description is that it can't really be expressed consistently. On the one hand you're saying "you don't have to give the code back, and you may do whatever you want with it in proprietary apps" and on the other hand you're saying "You have to give your changes back, or something similar to it (?)".

It's just not compatible. Either you allow this and that for certain aspects, or you disallow it. Good faith is a moral value, and can't really be translated to legalese. If you want to stick with good faith, then a notice "Please contribute something back, even if it's BSD" next to the download link probably wouldn't be such a bad idea.

Although I really don't see why the LGPL is "cumbersome for proprietary use", because it's 1. widely known and 2. really just made for this usecase: contribute back your changes, and don't have a viral effect on the code that's using it. And as you're planning to do a library, they don't need to make a library out of your code by themselves.

I think there's a reason that you don't find the license that you're describing.


By jakob petsovits at Sun, 08/20/2006 - 14:54

Well, I don't think, "Allow with conditions." is fundamentally tricky. I mean, that's what the GPL does as well. I mostly just want different conditions.

If I were to hack up such a license (which I'm hesitant to do, but we'll see) it would most likely contain rather specific instructions on how to demonstrate that the contributions had been submitted. i.e. a legalese-ified version of the following:

"You must send a patch to the development mailing list with the product name and version where this library is incorporated, a unified diff or collection of unified diffs with your changes to the library and this must appear in the public archives of said mailing list. Subsequent versions of your product, if they contain additional modifications to the library, must repeat the process above."

The LGPL really is cumbersome for proprietary use, to the extent that it's very widely avoided. I've seen this many times over in my OSS stuff (i.e. the fact that everyone and their dog is still using the old public domain implementation of id3lib rather than the slightly less broken LGPL version) and job (SAP, for instance was not comfortable with redistributing source for third party products -- IBM is another prominent example in that they do a lot of work for the Linux kernel, but you can't get a copy of it from them.).


By Scott Wheeler at Mon, 08/21/2006 - 09:10

Forcing people to send patches to a mailinglist is a bad idea. What if your domain name expires and the mailinglist mentioned in the license shuts down? This would also make your license non-free and incompatible with the GPL. Not to mention making license proliferation worse and having a snowball's chance in hell of being accepted by the Open Source Initiative (OSI). I think giving the source to the people who receive the binary is a tried-and-tested method, and it invariably leads to the modified source being in the hands of FOSS developers (I can't think of any example where it hasn't worked this way).

Of course SAP doesn't want to distribute GPL software -- they're Micro$oft's lapdog, and the worst peddler of Software Idea Patents in Europe!


By vladc at Tue, 08/22/2006 - 00:04

> Forcing people to send patches to a mailinglist is a bad idea.
> What if your domain name expires and the mailinglist mentioned in
> the license shuts down?

When kde.org expires, I probably won't care anyway. Not that people will be forced to send patches; they simply will have that as an option to fulfill the license requirements. The MPL phrases things in a way that basically say, "You've got to make your patches available somehow. It's your responsibility to make sure that they stay available." In the case of the mailing list, for things that are widely archived, that's pretty simple.

> This would also make your license non-free and incompatible with
> the GPL. Not to mention making license proliferation worse and
> having a snowball's chance in hell of being accepted by the Open
> Source Initiative (OSI).

It wouldn't make it non-free; it would make it GPL incompatible. But I honestly don't care. As I clearly said, it would be dual-licensed so GPL compatibility would be covered by the LGPL side of things.

> I think giving the source to the people who receive the binary is
> a tried-and-tested method, and it invariably leads to the modified
> source being in the hands of FOSS developers (I can't think of any
> example where it hasn't worked this way).

I just said I've seen it fail.

> Of course SAP doesn't want to distribute GPL software -- they're
> Micro$oft's lapdog, and the worst peddler of Software Idea Patents
> in Europe!

That's silly. SAP is a competitor (and partner, it's a tricky relationship) to Microsoft and they both distribute and have contributed to a number of GPL'ed projects. (Note SAP DB, which is GPL'ed.) What they don't do is redistribute GPL'ed projects. i.e. they've contributed to the Linux kernel, but won't distribute the Linux kernel. IBM does the same thing.

Again, you seem to not understand my premise here -- my goal is not to further the ideology of the FSF. I respect the organization, but do not share their philosophy. Your comments are really off-topic here since they've made no attempt to answer (or even seriously debate) the questions that I've raised. Naturally you may choose any licensing scheme that you happen to like for your own software, but this is about my software.


By Scott Wheeler at Tue, 08/22/2006 - 00:41

Such a license would not be a Free Software license. Let me quote verbatim the Free Software definition page:

You should also have the freedom to make modifications and use them privately in your own work or play, without even mentioning that they exist. If you do publish your changes, you should not be required to notify anyone in particular, or in any particular way.

IMO, the LGPL is a good license for libraries (unless you want to prevent propietary software from using it).


By Enrique Matías Sánchez at Fri, 08/25/2006 - 10:34

What about MPL (Mozilla Public License) + LGPL ?

Just my 0.02.

--Stefan

---
"Nobody Expects The Spanish Inquisition"
- Monty Python


By Stefan Teleman at Sun, 08/20/2006 - 19:13

I hadn't read it closely enough before, but indeed it does come quite close to what I'd like. Since it's a fairly widespread license it would be preferable to rolling my own.


By Scott Wheeler at Mon, 08/21/2006 - 09:19

you want something between BSD and LPGL ... how about a modified zlib-like licence?

here the zlib one:
/* zlib.h -- interface of the 'zlib' general purpose compression library
version 1.1.4, March 11th, 2002

Copyright (C) 1995-2002 Jean-loup Gailly and Mark Adler

This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any damages
arising from the use of this software.

Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute it
freely, subject to the following restrictions:

1. The origin of this software must not be misrepresented; you must not
claim that you wrote the original software. If you use this software
in a product, an acknowledgment in the product documentation would be
appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not be
misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution.

Jean-loup Gailly [email protected]
Mark Adler [email protected]

*/
you can easily add a 4th point to ask people to make their "publicly archived" ....


By Mathieu Chouinard at Wed, 08/23/2006 - 13:56