[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal for LedgerSMB 1.5: Refactor and move some utility functionality to CPAN
- Subject: Re: Proposal for LedgerSMB 1.5: Refactor and move some utility functionality to CPAN
- From: Chris Bennett <..hidden..>
- Date: Fri, 24 May 2013 10:49:26 -0500
On Thu, May 23, 2013 at 11:20:22PM -0700, Chris Travers wrote:
> Hi everyone;
> After 1.4 is released I would like to start moving the following
> functionality to CPAN:
> 1. Stored procedure call interface (call_procedure)
> 2. Stored procedure-> object property mapping interface (exec_method)
> 3. Moose wrappers around these, and
> 4. User permissions discovery
> 5. Helper modules (LedgerSMB::PGDate, LedgerSMB::PGNumber)
> There are a number of reasons why I think that this would be a good idea:
> 1. These are all potentially generally applicable pieces of code. They
> are potentially reusable well outside LedgerSMB, and they provide potential
> integration points for other applications.
> 2. They may be of interest to other developers. To the extent that they
> are, they represent a potential source of outreach for LedgerSMB
I like this idea. Other users outside of LedgerSMB may find flaws or
suggest new features that might be useful. I have occasionally found
some things in other CPAN modules and had a good response from the
> 3. Over the years, a good deal of cruft has built up in the interfaces.
> It would be good to redesign, generalize, and modularize these so that we
> can have better contracts between elements of the program.
> My current plan is to create what is essentially a toolkit for
> incorporating stored procedures into objects in Perl and then have our
> current interfaces be basic wrappers around these. The wrappers will still
> be necessary because many decisions we have made regarding tracking things
> like application state between modules can't be assumed in other
> A few questions I have for folks here:
> 1. Licensing. In general I have been trying to put new language bindings
> under permissive (BSD-style) licenses for the simple reason that it gives
> people more peace of mind if they are integrating proprietary applications
> with LedgerSMB. This also has the advantage of following what the
> PostgreSQL community is generally most comfortable with. Are there any
> concerns about this? Our actual object framework would still be GPL v2 so
> no changes of licensing in our project. It would just mean that there
> would be integration points available under more permissive licenses. The
> other option is "under the same terms of Perl itself" which protects us
> better against proprietary forks, but I am not at all sure that is much of
> a fear.
I always prefer BSD or even more permissive licensing.
If someone can then sell a proprietary version, they might be willing to
submit a module with the same kind of licensing. No guarantee of that,
of course. But why not?
There is something else that does happen. Companies close. People
retire. A contract for their software may end. Sometimes people die.
This actually happened to me during one project.
All of their proprietary software may suddenly become available with a