Meld's Bazaar support

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:
> I am saying that .pyc files /may/ be derived works (depends on exactly
> what the compiler does - whether it incorporates fragments of other .py
> or .pyc files or not), but that .py files are clearly not derived works.

According to the FSF:
- ---
The GNU Project has two principal licenses to use for libraries. One is
the GNU Library GPL; the other is the ordinary GNU GPL. The choice of
license makes a big difference: using the Library GPL permits use of the
library in proprietary programs; using the ordinary GPL for a library
makes it available only for free programs.

http://www.gnu.org/licenses/why-not-lgpl.html

If the modules are included in the same executable file, they are
definitely combined in one program. If modules are designed to run
linked together in a shared address space, that almost surely means
combining them into one program.

By contrast, pipes, sockets and command-line arguments are communication
mechanisms normally used between two separate programs. So when they are
used for communication, the modules normally are separate programs. But
if the semantics of the communication are intimate enough, exchanging
complex internal data structures, that too could be a basis to consider
the two parts as combined into a larger program.

http://www.fsf.org/licensing/licenses/gpl-faq.html#MereAggregation
- ---

The question of whether library clients are derived works in copyright
law is not one I'm qualified to address.

But there are many people who accept the FSF's interpretation.  And so I
assume that any library released under the GPL is intended to be used
only by clients under the GPL.  And while there may be legal
technicalities that would allow me to skirt the GPL, I consider it
immoral to take advantage of any such loopholes.

So it boils down to this:
If we intend for bzrlib to be used by non-GPL clients, we should use a
license that telegraphs that intent, such as the LGPL or BSD license.

If we don't intend for bzrlib to be used by non-GPL clients, then I
won't provide an implmentation of vc.bzr that uses bzrlib to Meld,
unless they relax their requirement for BSD.

> The closest .py files come to being tainted is via interface copyright,
> and interface copyright is both hugely arguable, and something that
> would be very bad for FOSS and the GPL if it is established to exist.

It seems to me that the FSF's claim the GPL extends to clients of GPLed
libraries depends upon interface copyright.  If it was established *not*
to exist, I believe the GPL would be greatly weakened.

> if [an interface] can be [copyrighted], then libraries such as
> gettext become wide open to cloned implementations that offer the
> interface, but suck, allowing people to /effectively/ link against the
> GPL library without tainting - because they can claim that they built
> against the BSD/whatever version.

I find this sentence confusing.  It seems to say that interface
copyright poses a danger that would not otherwise be present.  On
rereading it, I see an alternative interpretation: "Even if interfaces
can be copyrighted, very little additional protection is provided,
because any popular library can be cloned..."

Is that what you meant?

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE7N0Y0F+nu1YWqI0RAluqAJ48ZAgBHK3/d8b7pUnzbqjc0wsELwCdE8NQ
iLBvt+P8/X6hTQX4h6I0GTs=
=fDsi
-----END PGP SIGNATURE-----