Qt/Embedded

kmself at ix.netcom.com kmself at ix.netcom.com
Mon Nov 13 08:25:26 UTC 2000


on Sun, Nov 12, 2000 at 11:53:23PM -0800, David Johnson (david at usermode.org) wrote:
> On Sunday 12 November 2000 11:07 pm, kmself at ix.netcom.com wrote:
> 
> > > Will a BSD or MIT application even be able to use these #ifdefs so
> > > that the end user can recompile in private?
> >
> > Oblig: IANAL
> >
> > It's generally accepted that the MIT license is convertible to GPL, as
> > is BSD without advertising clause.  Programs licensed under such terms
> > might be considered GPLd if linked to the Qt libraries.
> 
> I understood it to be in the opposite direction. The GPL apparently
> considers dynamic linkage to be derivation of the copyrighted work,
> but derivation has a definite direction.
> 
> A GPL application could link to or incorporate BSD/MIT code, but that
> BSD/MIT code could not link to or incorporate GPL code. 

ObligLarryRosenMemorialDisclaimer: IANAL.

The governing principles are, as I understand, these:

  - The GPL requires that derived works of the original work not add or
    remove licensing and/or redistribution terms.

  - The BSD (non-advertising clause) and MIT licenses allow modification
    of distribution terms, so long as a copyright notice is retained.

  - The copyright notice requirement of the BSD/MIT licenses is
    consistant with a similar copyright notice requirement of the GNU
    GPL.  Therefore the BSD/MIT licenses are convertible to the GPL.

In the instance you describe above, BSD/MIT code could link to or
incorporate GPL code, but only if the derived work were distributed
under the terms of the GNU GPL.

> Under section 2 of the GPL it seems to be okay as it is the
> distribution of the whole that must be under the GPL, not the
> individual "independent and separate works". However, section 3 says
> that all source code must be distribute under the terms of section 1,
> which says "publish on each copy an appropriate copyright notice" and
> "give any other recipients of the Program a copy of this License".
>
> This is kind of confusing, as section 1 pertains only to the original
> work (verbatim copies), while section 2 pertains to derivative or
> collective works. So does section 3 mean to apply section 1 OR section
> 2 as appropriate, or is it saying that section 1 AND section 2 be
> applied to all parts regardless of whether they are original,
> derivative or collective?

I'm not sure what specifically you're referring to here.  "Independent
and seperate works" doesn't appear in the GPL, what are you quoting?

I read Section 3 to refer to distribution under either section 1 or
section 2:

      3. You may copy and distribute the Program (or a work based on it,
      under Section 2) in object code or executable form under the terms
      of Sections 1 and 2 above provided that you also do one of the
      following:

...the use of "Sections 1 _and_ 2" is confusing.  One of the real
lawyers care to step forward?

> > Mozilla is going to be released under a dual or multi-license
> > scheme, including the GNU GPL, and possibly the GNU LGPL, as well as
> > the MozPL and some legacy NPL code (last I'd heard, NPL was being
> > strongly deprecated in favor of MozPL).  There's an announcement of
> > same at http://www.mozilla.org/.
> 
> Can a dual-licensed work be linked to GPL code if one of the licenses
> is not compatible with the GPL? This would be a pretty big loophole. 

The theory as I understand is that if code 'A' licensed under multiple
licenses, and allowing distribution or modification under any given
single one of these licenses, is joined with code 'B' licensed under
terms compabible with only a subset of the multiple licenses, then the
combined work 'AB' accesses 'A' under only the compatible subset of
licenses.   In tangible terms, if Mozilla project code were incorporated
with other code under terms compatible with the MozPL but not the GPL,
the governing Mozilla license would be the MozPL.

-- 
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/20001113/5b767d79/attachment.sig>


More information about the License-discuss mailing list