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

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

(Sorry, I accidentally pressed Ctrl-Enter ("Send" in Outlook) before I was
done writing this message!  Let's try this again, and please disregard the
previous partial message...)

Hi,

I am pleased to report that I have gotten permission from my management to
release the new user-mode I/O driver ("ptal-mlcd") I've been working on
lately.  There are still a few formalities I have to take care of first
before I can do that, but at this point I can say with fairly high
confidence that I will be able to start checking it into CVS within the next
2-4 weeks (or earlier if possible).  I just updated the web page, especially
http://hpoj.sourceforge.net/todo.shtml, to indicate the most recent plans.
The most significant changes include greatly improved stability, USB
support, and parallel-port support for probably any version of Linux (not
just 2.2 and 2.4).  I will send out another announcement when that's done to
give people an opportunity to start playing around with it, but I will still
have some additional development to do before I can put out 0.8.
Nevertheless, printing and scanning already work well over both parallel and
USB.

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
MLC/1284.4 portion of ptal-mlcd, and it may apply to the entirety of
ptal-mlcd.  I haven't yet decided if it will apply to other parts of the
codebase that I (and by extension HP) contributed.  However, I personally am
planning on transferring my copyrights (i.e. on PTAL) to HP, since my
involvement is finally becoming officially sponsored by HP, as opposed to
its being a personal project the way it has been for me so far.  Most of the
other code (ieee12844, ojlib, apps/print, and apps/cmdline) will go away in
0.8 (being replaced by PTAL equivalents), so there won't be any question
about that in the first place.  The only remaining part of the codebase that
I didn't develop would be xojpanel.  I think it will be fine to keep the
copyright on xojpanel the way it is currently (unless Joe and Andreas really
want to transfer it).

Thanks in advance for any comments on these matters, and stay tuned for the
actual code in the near future, assuming there isn't so much dissent here
that I have to go back to the drawing board.  :-)


Allen Barnett wrote:
> Subject: [hpoj-devel] Choice of Devices
> I'm trying to decide between an HP G85 and a G95 (which is 
> evidently the
> same machine as the G85, except you get a JetDirect 170 with it). I
> already have a B&W PostScript laser printer connected to my parallel
> port which I am loath to give up. So, I either need to be able to
> connect the new device to a USB port or get the G95 and connect it to
> the network. I have no real need currently for a networked printer,
> however. Also in the mix: I need to run a 2.4 kernel to support some
> other hardware and there (still?) appear to be some issues with its
> parallel port support.
> 
> I guess my question is: Is USB connectivity for the the G series going
> to happen in the next month or so, or should I go ahead and 
> get the G95.
> (Or better still, is there some way I could contribute to making this
> happen?)


Anthony Segredo wrote:
> Subject: Linux 2.0.36 Officejet R40 support
> I am running the 2.0.36 kernel from the Redhat 5.2 distribution. I see 
> that the Officejet support is only for kernels 2.2.x and 2.4.x, is this 
> because of the parport driver? Is it possible that if I install and 
> build the parport source that the Officejet driver will work on 2.0.36?
> Where should your download code be rooted?
>
> I'm really pleased at the idea that I no longer have to put files in 
> the Windows partition to print them but am a little scared at the idea 
> of downloading and building the whole kernel although I have customized 
> and rebuilt the 2.0.36 kernel. I am a software professional but a Linux 
> newbie.

Hi, Anthony.  I would recommend against trying to back-port the "parport"
code into 2.0.  It also might be kind of tricky to upgrade the kernel on
your system, because you might need to upgrade various other system-level
utilities as well.  If you want this to work right away you could upgrade
your entire system to a more recent version of RedHat or another
distribution.  However, I think you would be better off waiting for the new
driver (see above).  That way you can help test it on kernel 2.0.  Also,
please subscribe to hpoj-announce and hpoj-devel if you haven't already so
that you can fully participate in testing and debugging.

David