License selection for free software

[Paul Boddie]

On 6 Mai, 19:22, vivai... at gmail.com (Ville M. Vainio) wrote:
> Excuse the long post.

Excuse the cherry-picking from your long post. ;-)

[...]

> Also, you can do what Paul Boddie did - fork the project, or maintain
> patches that are under LGPL. With a liberal license, you have that
> privilege.

Sure, my patches were LGPL, if you'd like to consider it that way, but
I have to point out that the derived work maintained by me became LGPL
as a result - I wasn't offering the non-Paul Boddie version under the
original licence as well. Now, I did leave a fair amount of
information about the heritage of the code, so that anyone who is
scared of the LGPL could just go and get the original work, but that
is probably your only viable option if you want to revert to the old
licensing.

[...]

> I don't think BSD/MIT like license really annoys anyone. Think python
> here ;-)

As some have pointed out, it can discourage people from contributing.
I've said many times before that some companies might not contribute
to a permissively licensed project because their competitors could
leverage the benefit in proprietary software, and I consider Linux and
the involvement of companies like IBM to be a reasonable example of
this.

[...]

> Not at all, it's a very practical thing related to all the
> intellectual property lawyerage in corporate setting. With Vellum, it
> doesn't matter a lot because most of the tools are only used in-house,
> but it would still be nice if you could just grab the code from
> somewhere without having to think about license at all, or considering
> whether any of this would ever be needed for something that involves
> selling stuff under proprietary license.

You can almost never just "grab the code from somewhere without having
to think about [the] license" since even permissive licences typically
have a list of conditions that must be observed. Certainly, they
aren't as demanding as those in copyleft licences, but by not
observing them you are infringing someone's copyright.

[...]

> Also, for some reason, GPL is used for evil (dual-licensing schemes -
> make money but still gain the open source mindshare, and possibly rack
> up free contributions to something that is your *commercial product*)
> more often than it's used for good (gcc, Linux kernel - prevent IP
> exploitation and ensure that all improvements are freely accessible).

The whole "evil" aspect of dual-licensing schemes is mostly to do with
copyright assignment (or the contribution agreement), not licensing,
although the licences typically employed obviously prevent the wider
community from making proprietary versions of the software, thus
creating the conditions for a dual-licensing business. That said, it's
easy to refuse to play along with such schemes if you're motivated:
just don't agree to assign your copyright to someone else, or don't
license your contributions under permissive licences (which
interestingly takes us back to the issue of Python contributions and
the associated list of acceptable licences).

These days, some companies are getting a lot of bad publicity about
their project governance: Sun seem to be getting continuous criticism
about the management of OpenOffice.org, and now that they've picked up
MySQL, they'll presumably be the target of criticism by people who had
to sign over their ownership of patches in order to feed the MySQL
corporate machine. But again, this isn't a sign that the licence was
the problem: it's what people were asked to do with the copyright
which effectively negated the benefits of the licence for those
wanting to keep the software free and open.

Paul