]ANN[ Vellum 0.16: Lots Of Documentation and Watching

[Ville Vainio]

GPL can mix with other free software licenses, so people who write
BSD code and do not wish to remain BSD clean are free to use GPL'd
code. That's the important point.

No, it can't. It can only mix through aggregation, i.e. you can ship a
GPL'd "plugin" with BSD code as long as you don't import the plugin
directly.

Here's a real life example from ipython:

- Core IPython is BSD clean, and we intend to leave it that way
- If we imported a gpl'd module in some core ipython component, the
core component would be gpl (or something equally restrictive) as
well, through viral nature of the license
- Now, if you want a BSD-clean version of ipython (say, to embed it in
a commercial program - with which I have absolutely *no* problem, and
can only see good things coming from it), you would have to gleam out
all the uses of that module from the source code. Not very fun, esp.
if it's something important
- There is a GPL'd module in "extensions" folder of IPython, ipy_bzr
(that is because of bzrlib). It's never imported anywhere in ipython
source code, but the user can import it in ipy_user_conf.py. This
"contaminates" the config file and subsequently ipython (because it's
imported into python interpreter ipython is running on), but luckily
the user can opt out from importing it if he wishes to remain BSD
clean. Or he can delete the file altogether if he wishes.

Without GPL, none of this hair-splitting is necessary.

I guess I could have gone the Carl Banks route and just say "It scares
away some people". Consider my replies here an elaborate way of saying
the very same thing.

 

[Paul Rubin]

Nonsense. They could be more than willing to contribute their
patches, but aren't willing to accept the GPL's limitation to being
used only in open source packages.

Oh, I see what you mean--I'm considering any derived work to be a
patch, which is maybe an overbroad use of that term. If they are
willing to contribute their patches in that sense, the GPL shouldn't
be a problem. If they want to just send back small scraps of
improvement while incorporating the GPL'd program into a closed
program, the GPL is doing its job if it prevents that.

 

[Paul Boddie]

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

 

[D'Arcy J.M. Cain]

It means GPL'd contributions can't be included in the main Python distro.

That's exactly what makes the GPL annoying to some of us. It just
depends on your point of view.

 

[Carl Banks]

Oh, I see what you mean--I'm considering any derived work to be a
patch, which is maybe an overbroad use of that term. If they are
willing to contribute their patches in that sense, the GPL shouldn't
be a problem. If they want to just send back small scraps of
improvement while incorporating the GPL'd program into a closed
program, the GPL is doing its job if it prevents that.

I think what I said is applicable to derived works, if the idea is to
derive another non-open-source work in turn.

I.e., someone might be motived to create a derived work of some code
with the expectation of using it in their non-open-source project, but
if it's GPLed they can't do that, so they probably wouldn't bother.


Carl Banks

 

[Ville M. Vainio]

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

I doubt anyone is really afraid of LGPL. The only problem with LGPL is
that of static vs. dynamic linking, and that is only a problem in
platforms without dynamic linker (rarity these days).

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

Yeah, but you don't have to "worry" about license - just have the
license text in source code, or a text file in binary distribution.

 

[Carl Banks]

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.

That IBM and other companies are involved with Linux is an example of
companies that are willing to get involved with GPL; it says nothing
about whether those companies would be more, less, or un- willing to
also get involved with more permissive licenses.

IBM is also involved with Apache, which does have a permissive
license.


Carl Banks

 

[Paul Boddie]

I doubt anyone is really afraid of LGPL. The only problem with LGPL is
that of static vs. dynamic linking, and that is only a problem in
platforms without dynamic linker (rarity these days).

The wxWindows, erm, wxWidgets people seemed to be worried enough to
neuter the licence, making the result a somewhat bizarre creation.

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

Yeah, but you don't have to "worry" about license - just have the
license text in source code, or a text file in binary distribution.

Yes, but you are still having to think about the licence: if it were
public domain code (and provably so, opening up another discussion
entirely) then you wouldn't need to think twice about doing whatever
you wanted with the code. I accept that with the GPL, you're obliged
to think about what you're going to need to do with the source, but in
licences like the modified BSD licence, the FreeBSD licence or the X11
licence, that text file in the binary distribution is quite possibly
something that some people might overlook.

There are other things that could trip people up, of course: non-
endorsement clauses, required notices of modifications, patent
retaliation clauses, and so on. All these do feature in permissive
licences.

Paul

 

[Paul Boddie]

That IBM and other companies are involved with Linux is an example of
companies that are willing to get involved with GPL; it says nothing
about whether those companies would be more, less, or un- willing to
also get involved with more permissive licenses.

Sure, but you have to wonder why IBM invested so heavily in Linux when
there were at least three different free and mature variants of BSD
"Unix" that certain parties regarded more favourably for commercial
usage at that time. It's possible to claim now that Linux is more
attractive than a number of permissively licensed solutions for
reasons of familiarity and community size, not licensing, but that may
not have been a compelling case back when IBM decided to invest in
Linux.

IBM is also involved with Apache, which does have a permissive
license.

I've seen other companies using Apache, too, but I've been far from
impressed by their enhancements (which have been proprietary, if I
recall correctly). One could argue that such companies see little
point in contributing their work to the community, perhaps fearing the
supposed advantage that their enhancements bring, yet simultaneously
fail to take advantage of the improvements the community can provide.

Paul