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

[PASCHAL,DAVID (HP-Roseville,ex1) <dav...@hp...>]

Hi,

First of all, I'd like to thank everybody for their interest and feedback
regarding the copyright and license on ptal-mlcd and hpoj in general.  A lot
of good points were raised, and I'll try to address them here.

But before I do that, I'd like to address the concerns that were raised
regarding the quality of print drivers, with which I can certainly
sympathize.  Actually, another division within HP is actively preparing
better inkjet drivers.  I'm not involved with that effort, but I took the
liberty of forwarding a couple of the relevant messages to several managers
and engineers who are involved.  It's a work in progress and no code has
been released yet, but you can get a sneak preview at
http://hpinkjet.sourceforge.net.  This driver was also demonstrated at
LinuxWorld Expo last month in the "e-mail garden".  I don't know exactly
when it will be released, but once I find out that it has been released I'll
be sure to make it known on the hpoj mailing lists.

Regarding the LGPL:

Although at first it might seem that the LGPL is the answer to this problem,
there are several reasons why it isn't appropriate in this situation,
particularly from an embedded systems perspective, which is where the new
MLC/1284.4 code comes from.  First and foremost is the fact that it would
potentially benefit competitors' proprietary products, which is highly
undesirable in the business I'm part of.  By releasing this code, the
intention for now is only to benefit free software, which is why the GPL
seems most appropriate.

The other problem with the LGPL is more of a practical nature.  When linking
with non-free software, there's a requirement to provide unlinked object
files to permit re-linking with newer versions of the LGPL code.  For an
embedded system, it may be difficult or impossible to get the new code onto
the device, especially if the firmware is burned into a ROM (which can't be
upgraded).

On the other hand, I have considered changing the license for PTAL (which
serves as the "official" API in this package) from GPL to LGPL.  At the
moment there doesn't appear to be a need for this, but I'll revisit this
question later if things change.

Joe Piolunek wrote:
> The IP 'transfer' plan reads like it was influenced by HP lawers
attempting 
> to adhere to some general policy. If that's the case, maybe Bruce Perens 
> could have a chat with them.
Actually, that was Bruce's suggestion, which was based on the example of Sun
and OpenOffice.  He also alluded to another possible strategy, where "the
contributor grant[s] HP separate and individual copyright, while they keep
their own copyright to the modification as well.  That means that either
party can do what they want with the code."  I can look into this if people
think it's better, but it may take more time to set up and consult with the
lawyers.

So to summarize what I currently have in mind:

The new changes will be released under the GPL (as is the case with the
existing hpoj code), but with an HP copyright.  The leveraged MLC/1284.4
portion of ptal-mlcd has to have the HP copyright because I developed it on
company time for actual products.  The remainder of my changes for the hpoj
project need to have the HP copyright because I'm now operating on behalf of
HP, rather than myself, as I was when I first joined this project.  I
haven't yet decided whether to retroactively change my existing copyrights
to HP or just apply it to new changes.

For everything in the hpoj codebase other than the leveraged MLC/1284.4
portion of ptal-mlcd, there will not be any requirement to re-assign
copyrights or otherwise give up any IP rights.  (I apologize if I offended
anybody by suggesting this as an option.)

As long as I'm responsible for maintaining both the free and HP-proprietary
versions of the MLC/1284.4 code, I'd like to keep them consistent (for the
sake of my own sanity:-).  To this end, if I accept contributions to this
portion of the codebase, I need to have some mechanism in place (such as the
various options already proposed) to permit me to incorporate contributions
onto both sides.  As the gatekeeper I would still have to scrutinize
submissions pretty carefully to ensure they were OK for both sides.  On the
other hand, I could just side-step the whole issue by maintaining this
portion of the code myself without any help.  And if I ever changed my mind
and decided to fork the code myself (i.e. if I changed jobs and no longer
was responsible for both versions), then the issue of maintaining
consistency would become irrelevant anyway.

One other question I should probably research is whether small changes, such
as a one-line bug fix, are different from large changes, and if so, what the
threshold is.  For Sun OpenOffice, I think the threshold is 10 lines.

Keep in mind that the license is GPL throughout the hpoj package, in
particular "version 2 or at your option any later version".  This means that
regardless of any difficulties imposed on submitting changes to the
"official" version I maintain, one would be free to fork their own version
from the GPLed "official" version (with or without any existing
contributions) and maintain it separately, with no requirement to push the
changes back to HP, as long as they abide by the GPL.  Also, I should point
out that in general, the copyright holders, whether HP or anybody else, have
the right to unanimously choose to release the same piece of code under
multiple licenses, as is the case here with the new MLC/1284.4 code.
However, the GPL does not permit revocation of code that has been released
under the GPL even if newer versions of the code have a different license,
so there are no worries there.

At this point, all I have left to do before checking in the new code is to
finalize the details about the dual-licensing and consistency of the
MLC/1284.4 code, and to finish rearranging the codebase and build process to
integrate the new functionality.  I look forward to any comments about what
I had to say here.  :-)

David