[sane-devel] 回信: Re: A Cooperation Message from Plustek Inc.

Olaf Meeuwissen paddy-hack at member.fsf.org
Mon Nov 7 12:19:43 UTC 2016

Hi Jenson,

Sorry for the late reaction, I'm just catching up with the list.

Great to hear of a vendor that's interested in cooperating with the SANE

JensonChen at adview.com.tw wrote:

> Dear Team,
> We will provide all source code to meet your point 1.

Good.  Any of the licenses already used by the SANE backends code are
fine.  See the LICENSE file in the source code.  In addition to that,
I think that the LGPL 2.1 or later is also fine for new code.

@Allan> Any comments about the suitability of using LGPL for new code?

> About 2,3,5, we need to review our source code first. I hope this
> suggestion can be work.

Here's an idea.  Clone the sane-backends git repository, create a
vendor/plustek/integration branch and add your code.  There is some
information in doc/backend-writing.txt that will help.  Push your git
repository somewhere we can see it (e.g. GitLab or GitHub) and let us
know on the list.  I'm sure some of us will be happy to go over your
work and point out any (glaring) issues.

I'll be happy to help with build system issues and squash compiler

> About 4, I think we can put a member to watch the bug, but not full
> time.

This shouldn't take too much time.  You basically scan the list for
mails that affect your backend and any tracker items assigned to you
will mail you if there is new information.  So the monitoring takes
little effort.

> m. allan noah <kitno455 at gmail.com> wrote:
>> Jenson- The SANE project certainly could accept your code for
>> inclusion into our repository, if a few conditions are met. Namely:
>> 1. The code must be completely open and suitable for use with our
>> license. No binary or precompiled code, other than possible firmware
>> uploads.

# Some places frown on firmware files as well.

>> 2. The code must use our sanei_* libraries for things like usb or
>> threading. It should not directly use libusb or any kernel modules,
>> etc.
>> 3. The code should be free from obvious security holes and bad
>> programming practices like using gets() or mktemp().
>> 4. One or more members of your team need to join the SANE project so
>> you can see user support requests on this mailing list and our bug
>> tracker.
>> 5. The code must build on other platforms that SANE supports, like the
>> various BSD Unixes. Generally, this just requires not calling anything
>> Linux specific.

I'd like to add:

6. The code should be free of compiler warnings for a full build (on
   Debian GNU/Linux stable).

>> Additionally, we prefer that all backends use our debugging library,
>> so that an environment variable like SANE_DEBUG_PLUSTEK=10 could be
>> used to enable user visible information from the backend.
>> If you and your management can accept those terms, the SANE project
>> would be glad to have your help. Additionally, your users would
>> benefit from having your drivers installed out of the box with their
>> distro of choice.
>> On Mon, Oct 31, 2016 at 11:22 PM,  <JensonChen at adview.com.tw> wrote:
>>> Dear Team,
>>> I am the software PM from Plustek Inc. We are a major scanner
>>> manufacturer in Taiwan.  We meet many linux driver support requests
>>> from our customers.  Linux has many distributions and versions and
>>> also sane too, we need put many RD resources to porting our driver
>>> to many version now.

In my experience (over a decade of maintaining two third-party SANE
backends) the most time consuming part was keeping the binary packages
up-to-date with new distribution versions.  By integrating your sources
with sane-backends, you would no longer have to do this.  On the other
hand, you loose control of the timing of your releases, though.

Another time consuming factor, which may or may not apply to you, was
catering to undocumented changes in libraries (especially ImageMagick).
The sanei_* code may cover part of this (as well as some more general
portability issues) depending on what your code needs.

>>> It's not a good idea to support linux driver.

# On the contrary ;-)  It's a very good idea.  It makes lots of people
# very happy, as you may have found out from some of the replies to your
# mail.  Just don't try to do everything by yourself.

>>> So we think, may be we can release the driver source code to your
>>> sane project, let you build in the driver at sane project.  What do
>>> you think about it? Thanks.
>>> Best Regards,
>>> Jenson

Hope this helps,
Olaf Meeuwissen, LPIC-2            FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Software                        https://my.fsf.org/donate
 Join the Free Software Foundation              https://my.fsf.org/join

More information about the sane-devel mailing list