Embedded systems & OS/FS

kmself at ix.netcom.com kmself at ix.netcom.com
Tue Aug 22 17:58:22 UTC 2000


On Tue, Aug 22, 2000 at 08:50:30AM -0700, Lawrence E. Rosen wrote:

> > -----Original Message-----
> > From: kmself at ix.netcom.com [mailto:kmself at ix.netcom.com]
> > Sent: Tuesday, August 22, 2000 2:29 AM
> > To: License-Discuss list
> > Subject: Embedded systems & OS/FS

<...>

> > Question I've got:  how does software licensing, free/OS or otherwise,
> > effect the hardware market.  My read is that some licenses, notably the
> > GNU L/GPL, may have their source availability requirements triggered by
> > the physical distribution of media (HW) on which the software is
> > embedded, etched, or otherwise fixed.

<...>

> > An instance in which this would matter:
> >
> >    ACME Mfg. creates printers.  They incorporate GPLd code 'gnuprint'
> >    into their product 'acmeprint', creating a derived work
> >    'gnuacmeprint' of the two programs.  In distributing the printers to
> >    wholesalers and eventually customers, does ACME trigger the GNU GPL's
> >    source distribution and relicensing requirements?  To whom does the
> >    source obligation apply -- wholesalers, final customers, or both?
> >
> > My read is that yes, ACME does.  The code to 'gnuacmeprint' must be
> > licensed under the GPL, and the terms of 3(a) or 3(b) of the GNU GPL
> > must be met.  I'm not sure that the wholesalers would have a solid claim
> > to code, the end customer certainly would.

> Copyright protection subsists in original works of authoriship "fixed in any
> tangible medium of expression."  It makes no difference that the tangible
> medium is an embedded device in hardware.  The licensee of GPL code must
> honor the license terms regardless of whether he embeds the licensed code in
> a derivative work on a floppy diskette or on a chip.  Once the final
> manufactured product (e.g., a printer) is distributed from the factory, the
> distributor or owner (e.g., the wholesaler or end customer) of that printer
> can sell it without triggering any further obligations to the original
> licensor.  /Larry Rosen

Thanks, Larry.

The distinction I'm trying to draw is this:

  - At the point at which the HW manufacturer has modified the work
	within the lab/factory, whatever, they are essentially doing the
	same thing that any programmer does in messing around with code --
	they are modifying and copying the work, but not distributing it.
	This is legit under the GPL.

  - Distributing the final product, however, triggers the source
	disclosure clause.  So you can *create* a printer, say, based on a
	combination of GPLd and proprietary code, but you can't actually
	sell it (or even give it away, legally), unless you intend to comply
	with the terms of the GPL.

The situation has some similarity to the issues surrounding the KDE
desktop and Qt license WRT GPLd works compiled with the Qt libraries.
My understanding in this case is that distributing compiled works isn't
permissable under the GPL, but distributing components, and allowing the
end-user to do the compiliation (not merely linking), might be.  Though
there are probably arguments here on both sides, with variances for
delivery mechanisms.

In the hardware picture, you then end up with the possibility of
shipping, say, uncompiled sources, and the first step of using the
printer is to have it "build itself" -- compile binaries from sources.
Not sure this is an optimal HW design, but it's a possibility, and
potential hole in the GPL.  Whether it's one to worry about is another
question.  The general question becomes one of contributtory
infringement, I believe.

Note also that the requirements could be obviated by creating a clear
seperation of programs.  A device which includes both proprietary and
GPLd code is TiVo.  The programs are generally understood to be
seperated, and the GPLd code no more "captures" the proprietary works
than it would on a Linux box.  While 3(a) or 3(b) need to be satisfied
for the GPLd works, there is *no* GPL requirement attached to the
proprietary code.

Some HW and OS designs don't allow for clear seperation of programs, as
I understand.  In this case, there isn't a way for multiple programs to
exist as seperate works.  Not sure either quite of the specifics, or of
how the issue might be dealt with.

-- 
Karsten M. Self <kmself at ix.netcom.com>     http://www.netcom.com/~kmself
 Evangelist, Opensales, Inc.                    http://www.opensales.org
  What part of "Gestalt" don't you understand?   Debian GNU/Linux rocks!
   http://gestalt-system.sourceforge.net/    K5: http://www.kuro5hin.org
GPG fingerprint: F932 8B25 5FDD 2528 D595 DC61 3847 889F 55F2 B9B0
-------------- 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/20000822/d6ecf1ca/attachment.sig>


More information about the License-discuss mailing list