[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using the invoice system - government rules



On 10/30/07, John R. Hogerhuis <..hidden..> wrote:

>
> Good point.
>
> >From this:
> 'http://forums.knowledgetree.com/viewtopic.php?p=2196&sid=280a6fbc8ddaac5d2ea0a28d7c5a3734
>
> it looks like it's on their roadmap so they would likely accept a
> patch :-) I doubt their schema would be that unwieldy. But I don't
> really know.
>
> > I wonder if there are any good open source equivalents on PostgreSQL.
> > If not, I think we are best off to modularly add source document
> > management (a very specific subset of DMS) to LedgerSMB.  If it is
> > modular, then we can allow for people to create connectors to other
> > DMS solutions.
>
> You could be right. I don't know of a PostgreSQL based DMS. I recall a
> few Java based DMSes in my searches, they might be PostgreSQL based.
>
> My instinct is that a port of KT to PostgreSQL would be more of a
> straight solve and lower long term maintenance for LedgerSMB project
> than engineering a DMS from scratch.

Under no circumstances do we want to put a full-fledged DMS on the
roadmap at the moment.  My thoughs are that we can modularly add some
sort of source document management (very simple needs-- these are
generally attach only with no provisions for updating/deleting).

Basically in this case we attach pdf/ps printed invoices, scanned checks, etc.

If we add a modular API to do this, one could essentially write
connectors to optionally store the data anywhere (kt, or wherever).

>
> I'll take a look at their code and I'll consider putting a patch where
> my mouth is. Did you notice anything else problematic with KT?
>
Adding a dependency to a GPL v3 project would complicate license
issues.  In particular I am not clear how GPL v3 section 7, paragraph
2 could be applied to BSD-licensed code* in some of our other
dependencies, so I don't know if it is a good idea for the project to
become tied to KT.

* This paragraph covers "relicensing" of portions of the covered work,
basically requiring the ability to change the license on any of our
depencies to the base GPL v3 + 7(3) additional terms without asserting
any copyrights of ones own.  This would be applicable to PostgreSQL if
and only if we could distribute PostgreSQL making no changes other
than adding new license headers to the top of every file essentially
overriding the current copyright licensing of that file.  This is a
strong departure from the historic practice of requiring that the
individual who wants to assert a license change have some copyrights
of his/her own to license.  The SFLC does not suggest that there is a
problem but advises *against* exercising 7(2) relicensing on BSD files
included verbatim (which makes me nervous regarding license
compatibility).  I would therefore want to see a real legal analysis
concluding that this is not a problem before proceeding.

Finally, I think it is a bad idea for a community-developed project to
be dependent on a single-vendor product for certain sorts of
functionality.

This is not to say we shouldn't be willing to allow for people to
store their documents in KnowledgeTree.  I just don't think we should
make it a fixed dependency.  Obviously people are going to want to
store documents in many different DMS's and it doesn't make sense for
us to force the storage of such documents in an isolated island.

Hope this helps,
Chris Travers