webERP Tutorials

For your convenience, here is a list of my webERP tutorials. 

#1. Installing webERP

Install webERP on Apache 2.4 and MariaDb 10.0.

#2. Product Lifecycle Management (PLM) using webERP

Create parts, identify vendor, configure unit-of-measure, create bill-of-materials.

#3. Purchasing using webERP

Issue purchase order, receive stock, make payment.

#4. Manufacturing using webERP

Create work order, receive output goods, close work order.

#5. Managing projects using WebERP (not completed)

Comparison of manufacturing and contract-based project management and configuration for following the manufacturing strategy, but a complete project workflow is not presented.


Recent Outage

You may have noticed suffered a minor maintenance glitch recently. Thank you for your patience and understanding if you were affected, and we sincerely regret any inconvenience as a result.

Update – all demos are now available!

The server had to be taken off-line to add additional RAM for the best possible demo performance, but also the operating system needed upgrading to make use of the memory. Content on had been temporarily re-hosted on a cloud vps for continuity, but unfortunately there were issues and the expeditious solution was to put up a static maintenance page and get on with the upgrade. However, all content is now available and the demo applications will be available again shortly.


Legal Cred for an Open-Source Project

I am not a lawyer. The information here is not, not is it intended to be, legal advice. 

Many open source projects unfortunately don’t concern themselves with presenting a clear legal perspective, which could be costing them community!

An open source project must present legal credibility to be considered seriously by a commercial enterprise.

I recently attended the iTech 2017 convention in Calgary, where the luncheon keynote was Digital Transformation Leaders Are Few and Far Between from Snehanshu Shah, SAP Global VP Customer Innovation. Shah purported that leading companies in digital transformation will use next-generation technology to continuously improve core infrastructure, while quickly incorporating new technologies for competitive edge, and that technologists who can apply inexpensive technology to solve these business problems will have value. Open-source software is now a proven development model with communities of essentially independent developers, collaborating in a non-competitive environment and sharing the development labor. It is inevitable that the business transformation spoke of by Shah will be aided by open-source software technologies, driving down the cost of infrastructure and providing sources of competitive advantage in a digital age.

It is in the nature of a young open-source project team to organise itself loosely. This should not be surprising, considering project members are typically volunteer developers donating their time to scratch their own personal itch, and more interested in writing code then in documentation or project process. A mantra of the open-source community is Talk is cheap. Show me the code. However, this is not to disparage project teams because it is hard to have value without working code.

Unfortunately though, this behavior is in contrast with a commercial enterprise’s typical need for security and stability to operate in the best interests of its owners. An enterprise must be absolutely confident that their adoption of a particular open-source software application cannot be jeopardized later, for example through misunderstanding or lack of appreciation for legal concepts by the project team, or a falling-out within the team leading to a disagreement over code ownership. A commercial enterprise requires confidence of longevity.

Ownership (Copyright)

The fundamental aspect of credibility is clear ownership of source code and other assets. Major projects often require contributors to sign a Copyright Assignment Agreement (CAA) or a Contributor License Agreement (CLA), which for all intensive purposes transfers ownership of the contribution to the project. However, this requires creation of a legal entity to assign or license contributor rights to, which is often beyond the need or ability of a smaller project team.

Simpler approaches are possible. For example, the Maestro project includes a legal statement in one of the project’s source code files – in the file. The statement specifies the license under which the software can be used, that contributors retain individual copyright to their work as recorded in the repository commit log, and that contributions are accepted with the assumption they were provided under the terms of the same license. The legal statement was committed to the project repository before any contributor contributions were accepted. This approach was deemed sufficient considering the project potential and risks, and ultimately a business decision.


The second-most fundamental aspect of credibility is the license, and the license terms that control use of the software. To have value, the license must be be legally binding and enforceable. Well understood and even legally tested licenses exist, but many open-source developers still write their own license, based on how they would like their software to be used. For example, Anuko Time Tracker, a popular web-based timesheet system, uses its own Liberal Freeware License, which appears to address the same concerns as more established and tested licenses such as the BSD, MIT, and Apache licenses. To an enterprise, not using a well-known and understood license can easily prevent an application from being considered further. Enterprises must be concerned with potential liability, and a well known and tested license will provide greater credibility. 

Permissive vs Copyleft

The anticipated use of the software must of course be compatible with the terms of the license, but also potential future use should be considered. There are two basic types of open-source licenses, permissive and copyleft. The two have very different goals and different implications for a commercial enterprise.

The goal of a permissive license is to encourage use through as few restrictions as possible, while the goal of a copyleft license is to ensure source code remains available even if modified by a third party. Commercial enterprises generally prefer a permissive license to a copyleft  license because it reduces risk of the license constrain the business at some point in the future. 

The original copyleft license was the GNU GPL, which required that source code be provided to everyone the application was distributed to. When remotely served web applications became popular, it was realized that GPL-licensed web applications hosted remotely did not have to make source code available, because the application wasn’t being distributed according to the GPL. This was against the philosophy of the copyleft community and became known as The ASP Loophole. As a result, the GNU Affero General Public License (AGPL) has become the popular copyleft license for web applications, requiring that source code be available to anyone who accesses the application. However, having to make source available should not be the greatest concern to a commercial enterprise for a copyleft license. The greatest concern should be whether the copyleft license could constrain future business direction or opportunities because of how the license extends itself to integrated – or integrating – applications to also apply to the end result. 

To explore this using an example, first assume an engineering department within a commercial enterprise is trying to improve project management, and starts using Anuko Time Tracker as an electronic timesheet system to record time spent by employees on projects and tasks. If use of  Time Tracker proves successful, the enterprise may expand use to other departments as well. Eventually the enterprise may make minor customizations as well as provide access to contract staff for entering their time, and to clients for reviewing their project’s dashboard. Assuming Time Tracker continues to be successful, the enterprise may want to integrate it with other internal systems, such as a vacation database or ERP system.

Because Time Tracker  uses the permissive Liberal Freeware License, there will be no practical constraint on how the enterprise can use, modify and integrate Time Tracker –  ever. However, if Time Tracker had been licensed using the AGPL, not only would customizations have to be shared with clients, subcontractors, and possibly competitors, but integrations with other applications may be impossible due to incompatible licensing. While it may be possible to perform an integration without the copyleft license becoming “viral” (a popular metaphor, implying that a copyleft license “infects” everything it touches), careful review of both the specific licenses and of the software architectures involved will be necessary to establish business viability.

In Conclusion

If you want to attract enterprise users to your open-source software project, then remove obstacles from their path. It doesn’t matter what you think, it’s what they think. Perception may not be reality, but it’s perception that matters. Make it easy for outsiders to understand the legal position of your project, and what the implications and options are.  

There is a plethora of legal advice on the internet, some useful, some less useful, and some absolutely wrong. Laws are specific to a jurisdiction, and much will simply not even apply to you. There are also subtleties and implications that only an expert can competently advise on. If it’s important, seek professional guidance!

For more anecdotal information,‘s FLOSS Weekly podcast interviewed several project teams that had to deal with legal issues.

  • Roberto Rosario had to develop Mayan EDMS in a way that would permit GPL licensing although he was working as an employee of the Porto Rico government, and also deal with an early fork that threatened the project’s future. See FLOSS Weekly Episode 253.


Remember, if it’s important, seek professional guidance!

Install ERPNext on FreeBSD

Frankly, the simplest way I have found to install ERPNext on FreeBSD is to use the ERPNext Virtual Image with VirtualBox and phpVirtualBoxVirtualBox is supported on FreeBSD, and phpVirtualBox is a popular web application that duplicates the native VirtualBox manager for headless servers (and saved me from learning the intricacies of the Virtual Box cli). A big shout-out to Ian More for creating phpVirtualBox, and to the phpVirtualBox community – including for updating the FreeBSD phpvirtualbox port and package

Several years ago I attempted to install ERPNext on bare metal FreeBSD using the ERPNext Easy Install script, but eventually had to switch to CentOS. This time I decided to try VirtualBox. I initially considered the BSD hypervisor bhyve, but bhyve does not directly support an Open Virtualization Format (OVF) disk image (although it is reportedly possible to use qemu-img to convert the OVF image to a raw image, which is supported by VirtualBox).

The server is de-branded HP Media Centre PC, with an E6600 Core 2 CPU and 3 GB of DDR2 PC2-5300. I was concerned about performance with only 3 GB of RAM but usability has been satisfactory, albeit to date under relatively light load. htop shows an increase in RAM and swap use with VirtualBox, but RAM use is still below 1 GB and swap use is under 100 MB.  

Please comment if you found this information useful. It’s kind of a poll. Thanks.

Install VirtualBox

# pkg install virtualbox-ose

The vboxdrv kernel module needs to be loaded at boot, done by editing /boot/loader.conf

# vi /boot/loader.conf

Reboot the system to have the kernel module loaded.

The user that VirtualBox runs as must be a member of the vboxusers group. For simplicity, I’ll run VirtualBox using my own username, although best practise would be to create a dedicated user.

# pw groupmod vboxusers -m dale

Edit /etc/rc.conf to run vboxwebsrv (the Virtual Box web interface daemon) using the provided startup script installed in /usr/local/etc/rc.d/

% sudo vi /etc/rc.conf


and finally start the vboxwebsrv service.

% sudo service vboxwebsrv start
% sudo service vboxwebsrv status

This however does not actually start a virtual machine. I will be using phpVirtualBox to manage virtual machines interactively. However, a vboxheadless rc.d script is also provided to start a virtual machine automatically during boot. 

Install phpVirtualBox

Install phpVirtualBox.

# pkg install phpvirtualbox

Edit the phpVirtualBox config.php file appropriately.

# vi /usr/local/www/phpvirtualbox/config.php

var $username = 'dale';
var $password = 'dale_login_password';

Finally configure the webserver to serve phpVirtualBox. I use Apache 2.4 and added a virtual host definition to /usr/local/etc/apache24/extra/httpd-vhosts.conf to serve phpvirtualbox as a

  DocumentRoot "/usr/local/www/phpvirtualbox"
  <Directory "/usr/local/www/phpvirtualbox">
    allow from all
    Options None
    Require all granted

“Install” ERPNext

Download an ERPNext Virtual Machine image (*.ova file) to /usr/local/etc/vbox (a suitably arbitrary location).

 % wget

Using phpVirtualBox, create a new vm by importing the downloaded ERPNext-Production.ova Virtual Image file (File/Import). It includes port forwarding rules to forward client port 80 (used by the vm to serve ERPNext) to host port 8080. There is also a rule to forward ssh from client port 22 to host port 3022.

Start the vm and then login to ERPNext from a browser (e.g. using the default credentials. The new site wizard will run and lead you through ERPNext configuration. Use a secure password when defining the initial (admin) user, and the wizard will delete the initial Administrator user (with default password) when complete. 

Once logged into ERPNext, you will likely want to setup email processing so that users will receive notifications outside of ERPNext. This will be valuable to understanding and appreciating ERPNext’s significant social aspect. You will also want to change the password for the configured system user to something secure (or even disable password authentication entirely in favour of key-based authentication).

More about phpVirtualBox

phpVirtualBox may be a project in transition. Although researching the internet showed phpVirtualBox to be the most popular web UI for VirtualBox, it still appears to depend primarily on the project founder for development support.

The phpVirtualBox project was first hosted on Sourceforge. Although the code repository was later moved to GitHub, Sourceforge still hosts the distribution archives and documentation wiki.

The future of phpVirtualBox though is not completely certain, which is unfortunate as phpVirtualBox is the only web interface for VirtualBox. The GitHub repo is the only repo managed by the phpVirtualBox organization, which has has no public members and no written statement of direction. The FreeBSD phpvirtualbox port update from July 2017, billed as an “unofficial 5.1-1 release” was cherry picked from unaccepted community merge requests and included the comment “Sadly upstream is very silent”.

However, given the popularity of phpVirtualBox, and that it’s licensed using the GPL v3, I’m confident it will survive.