Re: software licensing
Before I reply to everyone, I want to make a couple points about my
philosophy on this issue.
As I see it, I have two choices, each with pros and cons:
1. Use a lawyer-approved license (either GPL, or something I have done
with help from a lawyer). Pros: it will almost certainly stand up in
court. Cons: Hackers and users won't be able to understand it.
2. Use something I write myself (the RSL). Pros: it will be fairly
unambiguous and easy-to-understand; also I take a certain amount of
pride in writing a nice clean license, just like I do in writing an
elegant piece of code. Cons: it might fall down in court.
Given these tradeoffs, I've decided to go with option 1. It's very
unlikely that xpdf will end up in court. I don't have any real
interest (or any time) to pursue a court case if something came up.
More importantly, I have a pretty reasonable policy toward commercial
licensing. (I've sold a handful of licenses.) I'm pretty sure that
most companies would much rather pay my (relatively small) licensing
fee than risk any sort of legal proceedings.
If I was hell-bent on converting the world to open source software, my
decision would probably be different. As it is, there's really no
incentive to purposefully break the conditions of my license.
I'm not making any claims that this RSL would be the best license for
all software. (Or for any software other than my own, for that
matter.)
One final thing: I'm assuming reasonable behavior on the part of
hackers and users (my audience). Yes, there are probably legal
loopholes in the license, but the main idea is to explain what I want
people to be able to do with my sofware. Having the license stand up
in court is not a primary goal.
Now I'm going to reply to everyone in one big email, so this will
be fairly long...
Daniel Martin at cush <dtm12@jhunix.hcf.jhu.edu> wrote:
> I think this has one of the same problems that early draft versions of
> the NPL did. Namely, I can't give a modified version (say the
> modification is somehow useful only to JHU students) to my friend
> without making it publicly available.
My understanding of the GPL is that it's ok to give modified versions
to a friend, as long as you include the source code. This means that I
could pass copies around to a whole group, without ever making the
modified source code public. I don't particularly want to allow this
"private distribution" behaviour anyway. (Please correct me if I
misunderstood the GPL.)
> Also, what if I live in some
> country in which internet access is difficult and/or expensive, and I
> wish to make a modified xpdf which I wish to install on all my
> neighbors' machines?
I'd be perfectly happy to work out some sort of agreement with anyone
in this sort of circumstance. For example, if they were to send me the
modifications (on a floppy if they don't have email), I'd be happy.
Fortunately, this kind of situation is becoming rare.
> Also, what if I want only a few people to test a particular
> modification before releasing it to the world? Your current license
> wouldn't necessarily allow me to simply email patch files to friends
> of mine without putting the patch file on a web page/ftp site for all
> the world to look at.
Again, if this person sent me a quick email promising to make the
changes public once they were tested, I'd have no problem with it.
> I'd propose the following change:
> 3. Modifications to the package and modified versions of the package
> may be distributed only if:
> ...
> d. the source code modifications (patch files) or modified source
> code are made publicly available in freely accessible electronic
> form, e.g., on a web or ftp site,
Your first addition:
> OR the modified source code or
> source modifications are distributed with the package
I mentioned this one above. I don't want to allow entire groups to
distribute modified source code without making it public.
Your second addition:
> OR any
> binary (i.e. compiled) version is accompanied with a written
> offer to provide the source code modifications (patch files) or
> modified source on demand for no more than the cost of the
> physical duplication of the source code modifications or
> modified source. (Note that binaries must also be accompanied
> by the files listed in 2(a)).
Is this meant to solve the "no access to the web" problem? As I said
above, I see this as a rare situation, and I'd prefer to handle it on a
case-by-case basis.
> This will cause most people to exhibit the behavior you expected when
> you wrote the RSL, but will allow people in bizarre circumstances to
> enjoy the freedoms one expects from free software. Whether or not
> something is DFSG free often comes down to these bizarre cases.
Is this really an issue? I don't see anything in the DFSG that
requires allowing, e.g., the "private distribution" thing.
> Hrmm. That clause become much longer and more convoluted than I
> intended when I started writing it. I hope someone can shorten it -
> part of the problem is that we don't want to accidentally introduce
> loopholes that allow people to sell modified versions of the software
> without allowing the buyers to turn around and send those
> modifications upstream.
Yeah, I ran into this problem -- it's tough coming up with something
clean and elegant that still covers everything I want to cover. But I
like tough problems :-)
> And of course RSL code can't be linked to GPL code, but that's the
> case with much free software. It's the nature of the GPL.
Yup, I don't know what to do about that. Actually, I've already allowed
someone to incorporate parts of xpdf into pdftex, under the GPL.
Again, I think special cases can be handled individually.
john@dhh.gt.org wrote:
>> 1. Anyone may distribute lists of modifications to the package, e.g.,
>> patch files,...
>
> Are you saying then that modifications must be distributed in a specific
> form?
No, "e.g." means "for example". The intent is to cover two different
things. One is any sort of "lists of changes" -- patch files are one
example, but there are others. This is handled by Section 1. The
other thing is complete, modified source code. This is handled by
Section 2.
>> 2. Anyone may distribute the package, including source code and/or
>> binaries, under the following conditions:
>
> Can I use code from your program in an otherwise unrelated program? The
> RSL is not clear on this point.
If the other program is also licensed under the RPL. As I mentioned
above, I'll be happy to consider other requests individually.
>> d. the source code modifications (patch files) or modified source
>> code are made publicly available in freely accessible electronic
>> form, e.g., on a web or ftp site.
>
> So I must make source available via ftp or http forever, even if I have
> distributed only source?
You're right - this is still a little unclear. The idea is that you
can distribute a binary which was compiled from modified code, as long
as all of the modifications were publicly available *somewhere* when
you distributed the binary. For example, if someone wants to put xpdf
(compiled with some publicly available patches) on a CD-ROM, I don't
want to require them to distribute the xpdf source. On the other hand,
if someone wants to create their own custom patches, they'll have to
distribute the patches in source code form before they're allowed to
distribute the binaries.
If anyone can suggest a way to clarify this, I'll be happy to listen.
Dan Jacobowitz <drow@false.org> wrote:
>> a. The copies must include all associated documentation:
>> i. the README file; and
>> ii. the man pages and/or help files applicable to program(s)
>> included in the distribution; and
>> iii. this license.
>>
>> b. If the package includes modified source code or binaries
>> compiled from modified source code, all modifications must be
>> identified in the package documentation, and the modifications
>> must be publicly available as described in Section 3.
>
> I'm not sure that this is an issue but - along with some parts of
> section 3, this is unclear as to how it treats the documentation. If
> the debianized package were to move a file and want to change the
> pathname in the documentation, a common enough case, how must this
> change be indicated? Is the documentation considered source code or a
> binary compiled from modified source code? I think you must explicitly
> give permission to make certain modifications to the documentation.
> See the unending Open Documentation thread.
Good point. How about something like this:
b. If the package includes modified source code or documentation, or
binaries compiled from modified source code, all modifications must
be identified in the package documentation, ...
And similar modifications to Section 3. This way, documentation is
treated as source code.
gsstark@mit.edu (Gregory S. Stark) wrote:
>> (2) gives me the exclusive right to do commercial licensing, and
>
> I assume by this you mean "proprietary" or "binary only release" licensing?
> Free software does not preclude commercialization, and licenses which prohibit
> commercial use immediately fail the DFSG.
Right. I want to allow anyone to distribute patches or modified source
code under RSL. I want to allow anyone to use xpdf (potentially
modified with RSL patches) for any purpose (commercial or whatever).
But I want to prohibit anyone else from selling any sort of proprietary
license to a package which includes my source code or binaries
compiled from my source code.
>> (3) is clear, concise, and unambiguous. I think the GPL is pretty close to
>> what I want (on #1 and #2), but it's simply way too confusing and ambiguous.
>
> How many times have you heard someone try to explain something in your field
> in "layman's" terms only to say something vaguely right but in fact far more
> ambiguous and unclear than the technical terms? The reason scientists,
> programmers, lawyers, and people in every other specialized field invent
> technical jargon is because that jargon typically _is_ the clearest most
> unambiguous way to express ideas in their field.
You're right, but I'm aiming my license at people in *my* field. I
have no intention of this license ever seeing the inside of a court.
What I want is for users and hackers to understand what I'm allowing
them to do with my source code.
> It sounds to me that what you want to do is write a foreward explaining what
> some acceptable and unacceptable uses under the license are, and explaining
> that you are amenable to selling separate non-copyleft licenses as well. That
> makes it clear to users who don't understand the GPL, while preserving
> language "written for lawyers", since after all the license is a contract.
But the GPL is ambiguous, *even to me*. For example, see my question
above about "private distribution" within a group. Does the GPL allow
this? I'm not sure. But I don't want to allow it with xpdf.
> I'm afraid if you write your own license with the expectation that it preserve
> your rights to the extent the GPL does that you'll write something that sounds
> good to a layman, but leaves ambiguities and loopholes. This is especially
> relevant if you want to require license fees for proprietary uses, since those
> users have the most incentive to try to find a loophole in the license.
As I said above, my strategy here is to make purchasing the proprietary
license more attractive than hunting for loopholes in the free license.
> That said, I don't actually see any real problems with your license that
> others haven't mentioned (the "must publish" problem). But I'm not a lawyer
> and I'm worried there are aspects I've missed. Rereading the GPL I notice lots
> of little details lost in your version, such as the ability to ship without
> source if you include a written offer to ship it later for example.
I don't see any particularly good reason to allow this.
> Incidentally, it can trivially be made GPL compatible by adding a clause
> allowing the user to optionally redistribute it or a derived work under the
> GPL. This however creates a possibility that someone could fork a GPL'd branch
> which would become more popular than the main branch. Whether this is
> acceptable is up to you.
The idea is that I can take useful modifications from other people and
include them in the main distribution. (But not the proprietary
distribution, of course.)
- Derek
Reply to: