Re: [hpoj-devel] new I/O driver coming soon (second try)

[Robert G. B. <rg...@ph...>]

On Wed, 28 Feb 2001, PASCHAL,DAVID (HP-Roseville,ex1) wrote:

> In the meantime, I'd like to take this opportunity to solicit ideas and
> feedback on a particular license/copyright issue.  I intend to license
> ptal-mlcd under the GPL, as has been done already with the rest of the hpoj
> package, to guarantee its status as free software.  The difference here is
> that some of the code in ptal-mlcd (in particular, the portion that actually
> implements the MLC/1284.4 transport) is also used by HP in non-GPL products.
> That in and of itself isn't a problem, since as the copyright holder HP may
> license the code simultaneously under the GPL as well as under a traditional
> proprietary license.  The problem arises when accepting contributions to
> this code from outside of HP, because I need to be able to incorporate those
> changes into the non-GPL version.  This makes my job much easier, since I'm
> responsible for maintaining both versions, and I want to keep them
> consistent for now to facilitate further updates.  I plan to handle this
> issue by requiring people who contribute changes to the transport portion of
> ptal-mlcd to assign copyright of the changes to HP, probably either by
> signing and sending in a paper form agreeing to this (as Sun does with
> http://openoffice.org), or by including with each submitted patch a canned
> statement to this effect.
>
> Keep in mind that the intent here is not to take unfair advantage of
> anybody's efforts.  In addition to making it easier for me to maintain, it
> also makes it easier for HP to defend against copyright infringement;
> otherwise, we would have to get every copyright holder to become involved.
> On the other hand, since this is GPL code, one would be perfectly free to
> "fork" the code into a separate project and make their own changes without
> contributing them directly to this project and assigning copyright to HP, as
> long as they abide by the GPL.  Hopefully that won't be necessary, but
> there's nothing wrong with it.  In any case, as the gatekeeper of both
> versions of the code I will need to be fairly conservative about what
> changes I accept to the MLC/1284.4 portion of ptal-mlcd, so this issue may
> not come up much or at all anyway.
>
> I would like to know if anybody has comments or concerns regarding this
> copyright-assignment proposal.  At the very least it will apply to the

Why not simply split off all of the core code that you wish to share
into a Lesser GPL module (used when folks wish to permit incorporation
of GPL stuff into proprietary programs.  That's what this is for, after
all.  The shell routines that call things from this module can still be
full GPL.

That way everything in the project remains open source and freely
reusable without worrying about having to split off open/closed versions
or re-engineer or reverse engineer any particular part of the shared
code.  Thus HP can contribute changes they might need to any part of the
LGPL portion (as long as you're willing to work with the GPL portion so
that it still works) as can anyone else, but HP is also free to link the
LGPL object modules into their proprietary stuff without having to
reveal its source.

I at least am perfectly comfortable with this.  To me the real open
source issue is the protection provided by GPL's in general from
companies like HP deciding to grab the LGPL modules, hack them a bit,
and then copyright or patent things therein so that the original
creators are no longer free to use them.  I don't think HP has any
interest in that game anyway, as they are a highly innovative company
and don't really need to steal (for it really is a kind of intellectual
theft) but the LGPL suffices to prevent it in any event.

This does mean (I believe) that HP will be de facto obligated to not in
the future attempt to copyright or patent code that is itself derivative
from what is in the LGPL module or library.  It would also probably be
the best idea all around if the module itself has a fairly clearly
specified API and is indeed a library (that is, doesn't contain any of
the OS-specific "shell" portions or potentially proprietary processing
algorithm portions that HP might want to keep or that GPL contributors
might want and expect to be truly openly shared).

In this case, you shouldn't need any fancy documentation or signed
agreements -- you only need to decide which portions should be full GPL
and which should be lesser and place the appropriate copyright/license
headers in each.  If you split off the LGPL parts into a source
directory for a LGPL-only library, so much the cleaner.  This way the
full source of hpoj stuff will remain rigorously open source, the stuff
you've written or that others have contributed can remain full GPL, and
stuff that hp has contributed and/or wants to be able to share and
incorporate into proprietary stuff can be LGPL.

BTW, looking forward to 0.8, especially since I'm up to RH 7.0 and
looking hard at installing 7.1beta, which uses a 2.4 kernel.

   rgb

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rg...@ph...