Picking a license

[Patrick Maupin]

On May 14, 9:59 pm, Steven D'Aprano <st... at REMOVE-THIS-
cybersource.com.au> wrote:
> I think this talk about freedoms is dangerously incomplete, and is
> confusing the issue rather than shedding more light. Both licences grant
> the same positive freedoms (freedom to do something). MIT-style licences
> grant permission to:
>
> * make copies of the work;
> * make derivative works based on the work; and
> * distribute those derivative works to others.
>
> The GPL grants precisely the same three rights. There is no difference in
> the rights granted.
>
> The MIT licence imposes an obligation on the licencee:
>
> * you must include a copy of the licence and copyright notice with the
> work and/or any derivative works.
>
> The GPL adds a further obligation:
>
> * any derivative works must also be licenced under the GPL.
>
> If we want to talk about "freedoms", rather than rights and obligations,
> we need to distinguish between positive freedoms (freedom to do
> something) and negative freedoms (freedoms from something) and not just
> blithely mix them up.

That is well-put, and of course the whole purpose of the extra
obligation or "negative freedom" is to ensure the rights or "positive
freedoms" of downstream recipients of the software.

In theoretical terms, everybody who redistributes software under the
GPL has the same obligations imposed, but as I have shown in other
posts, this obligation is unevenly enforced, and probably by design.

In practical terms, the additional obligations of the GPL license are
imposed on those who distribute huge quantities of software (Ubuntu,
Red Hat) and those who distribute derivative works (by combining other
software with the GPLed software).

It is questionable whether distributors such as Ubuntu and Red Hat
truly see this as an obligation; certainly they also distribute source
for permissively-licensed programs, and certainly other parties
happily provide source for fully BSD-licensed distributions for free.
Nonetheless, some of the smaller derivative distributors undoubtedly
wind up paying for more bandwidth than they would like.

So, the bulk of the additional obligations fall squarely on people who
distribute derivative works.  This is by design.  It is what keeps the
Microsofts of this world from appropriating GPLed software.  As I have
said many times, for people who worry about this stuff, the GPL is
absolutely the right license, because any license that gets them
writing free software rather than worrying about freeloaders is a
great license.

But for someone (let's call him "Fred") who distributes derivative
works to a customer, the additional obligation you mention for the GPL
actually has 4 separate components:

1) Full source for the original program must be provided
2) Fred's own additional source code must also be provided
3) Fred can't link to any proprietary software at all.
4) Fred must be sure that his customer is OK with the resultant work
product being under the GPL.

Now, if Fred was going to provide source anyway, the only possible
sticking points are really #3 and #4.  But those can be very sticky.
Let's start with #3.

If the proprietary software that is being linked to is, for example,
Oracle, Fred can't legally use GPLed software.  Well, actually he
might be able to, if he writes the software as a work-for-hire (as a
contractor for the customer), because then there might not be a true
distribution of the final package.  So that might actually reduce the
amount of free software in the world -- if Fred writes it as work for
hire, he can't distribute it to anybody else, and the customer is not
about to make a distribution of any of the software, so this is a case
where, if Fred can find and leverage permissively licensed software
instead of GPLed software, the amount of free software available in
the world can actually go up.

Now for #4, where Fred just has to communicate with and educate the
customer.  Even if the customer is just going to use the software in-
house with no plans to ever distribute it, the act of merely *asking*
a customer if it is OK to use GPLed software in the solution can, in
some cases, mean the difference between being able to sign a contract
and get started right away, or needing a review by the lawyers that
won't conclude for a month and then being told "no" or, even worse,
that "business conditions have changed."

Obviously, if there were a GPLed solution already available that was
the best tool for the job, it might be a good tactic for Fred (if he
weren't too worried about the interminable lawyer review) to explain
that it will cost $X for a GPL solution, and $X+Y for a non-GPL
solution.  Or even a good tactic to precede that with a simple
question of if the customer ever uses GPL software, and if they
already do, do they have a policy.  (But that has to be asked in such
a way as to not provide an original research question for the lawyer.)

But if, starting out, there is no compelling GPLed solution, then
there is no good reason to even ask things like that of the customer
-- better to just start coding.  And if the climate is right to ask if
the customer minds if Fred reuses and shares the code, there is a good
chance that Fred will use a permissive license on any generic code, if
he wants to enable others like himself.

So, there are good reasons for both kinds of licenses, which I think
everybody on the pro-permissive side has been saying all along.  Of
course, "force" is a more inflammatory word that "obligation" in some
contexts, and that has been used in what I would admit on my part is a
knee-jerk reaction to my belief that "free" and "freedom" are more
inflammatory words than "rights" in the same contexts.

Regards,
Pat