Qt/Embedded

[kmself at ix.netcom.com]

on Mon, Nov 13, 2000 at 11:45:11PM -0800, David Johnson (david at usermode.org) wrote:
> On Monday 13 November 2000 10:58 pm, kmself at ix.netcom.com wrote:
> 
> > Besides, the point of the BSD/MIT licenses is to allow this
> > licensing transitivity.  You'd similarly not be able to redistribute
> > code derived from BSD/MIT terms after combining it with a typical
> > proprietary license.
> 
> Including the source code is one thing, but dynamically linking to a
> library is a different beast. The typical proprietary license
> (actually all of them that I can think of) place no restrictions on
> how I can license my own application if I dynamically linking to them.
> That sort of restriction seems to be limited to the Open Source world.
> To be fair however, most proprietary libraries have other restrictions
> that more than make up for their liberalism in this area.

The difference is this:

  - A proprietary software development library has to both allow you to
    distribute product *and* provide a revenue stream for the library
    vendor.

  - A free software library may want to promote use of the library
    and/or the idea of free software itself.

In the case of the GNU GPL, you've got an ideological document -- it's
aim is to propogate its own core idea of free software.  This may
include restrictions on how a library can be linked to a program not
covered under the same terms as the library.  The GNU LGPL was developed
to loosen these requirements somewhat.

There are a couple of instances of proprietary libraries and/or
development environments which essentially place stringent limitations
on how code written for them can be used, particularly if runtime
environments are required.

It's really a matter of ideology though.

> > Sorry.  And I can't spell it either, or I might've noticed.
> >
> > As I understand, the "Independent and separate" language refers to
> > programs which don't cross the link-layer boundary.  Though this is
> > a bit fuzzy in definition.  Whether you can get away with shipping,
> > say, binaries and object files, I'm not sure.  As seperate entities,
> > shipped separately, possibly.  Together, probably not.
> 
> Is this "link-layer" boundary defined in copyright law? It certainly
> isn't in the GPL. RMS seems to draw his line there, but does he have
> any concrete reasons for drawing it there? (I'm sure he does, I just
> don't know what they are).

The idea is that, if a program is a work, and if (as the courts have
held, in Mai v. Peak) a program in memory meets the fixed and tangible
requirements of copyright law, and is therefore a copy under copyright
law, then a program linked to a library at runtime is a derivative work.
There's some conflating of this under copyright law -- I believe the US
statute doesn't restrict running a program by the "rightful owner"
(language which raises interesting questions in the context of, say,
contractors or casual visitors to a workplace).  But essentially, the
idea is that the GNU GPL is still working with accepted notions under
law as to what a work is, and what constitutes derivative works of it,
under copyright law.

> But this is getting off topic. All I need to know is my legal standing
> if I distribute two nearly identical BSD licensed packages, one linked
> to QT/X11 and the other to Qt/Embedded. As near as I can tell, the
> only real difference between them would be a different library name
> sent to the linker.

I don't know the answer to that.

> -- 
> David Johnson
> ___________________
> http://www.usermode.org

-- 
Karsten M. Self <kmself at ix.netcom.com>     http://www.netcom.com/~kmself
 Evangelist, Zelerate, Inc.                      http://www.zelerate.org
  What part of "Gestalt" don't you understand?      There is no K5 cabal
   http://gestalt-system.sourceforge.net/        http://www.kuro5hin.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20001117/1b8776c7/attachment.sig>