Posted on

dalescott.net is back down from the cloud!

Hosting dalescott.net on a low-cost  cloud server didn’t go so well and I had to move my site back to a bare metal server in the basement.

Step 1

It all started when I created a $5/month FreeBSD 10.1 vps using a DigitalOcean droplet (1 CPU, 512MB RAM) to host a demo for my Maestro PLM/ERP project. The site also included OpenLDAP/phpLDAPadmin and Postfix/dovecot/procmail/mutt/SquirrelMail for Swift Construction Company demo user authentication and email. The vps was rock solid, and I was very pleased with performance and cost (although getting negligible traffic).

Step 2

A year later, I tried to simplify my life by migrating my WordPress blog from a bare metal server in the basement also to the DigitalOcean vps droplet. The blog went live on the vps once I updated the IP address for my dalescott.net domain using No-IP’s DDNS service, and a day later the system was non-responsive with kernel out-of-swap errors in /var/log/messages. My immediate response was to dedicate 2G of the available 20GB SSD file space to swap (3GB total swap), but this only delayed the system becoming non-responsive to ~3 days.

I next learned how to tune the apache prefork mpm to not use more than ~300MB memory. At first, everything seemed OK and I breathed a sigh of relief, not too responsive but at least not running out of RAM and thrashing.  Then I upgraded some ports and upgraded from FreeBSD 10.1 to 10.3 (or maybe from 10.2 to 10.3, I regret not keeping better notes), but the result was that the server couldn’t maintain an ssh connection for more than 30 seconds with Apache running.

Rebooting and watching the system console, I noticed a ZFS notice I hadn’t noticed before – warning of expected unstable behaviour!

ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; to enable......
ZFS WARNING: Recommended minimal kmem_size is 512MB; expect unstable behavior....

I also noticed errors in /var/log/messages that I didn’t recall seeing before.

dale@whizzer:~ % tail /var/log/messages
Aug 25 16:05:33 whizzer dale: /usr/sbin/service: WARNING: $growfs_enable is not set properly - see rc.conf(5).
Aug 25 16:05:33 whizzer dale: /usr/sbin/service: WARNING: $ is not set properly - see rc.conf(5).
Aug 25 16:05:33 whizzer dale: /usr/sbin/service: WARNING: $rsyncd_enable is not set properly - see rc.conf(5).
Aug 25 16:05:33 whizzer dale: /usr/sbin/service: WARNING: $php_fpm_enable is not set properly - see rc.conf(5).
Aug 25 16:05:33 whizzer dale: /usr/sbin/service: WARNING: $htcacheclean_enable is not set properly - see rc.conf(5).
Aug 25 16:05:33 whizzer dale: /usr/sbin/service: WARNING: $git_daemon_enable is not set properly - see rc.conf(5).
Aug 25 16:05:33 whizzer dale: /usr/sbin/service: WARNING: $dbus_enable is not set properly - see rc.conf(5).
Aug 25 16:05:33 whizzer dale: /usr/sbin/service: WARNING: $avahi_daemon_enable is not set properly - see rc.conf(5).
Aug 25 16:05:33 whizzer dale: /usr/sbin/service: WARNING: $avahi_dnsconfd_enable is not set properly - see rc.conf(5).
dale@whizzer:~ %

DigitalOcean now has both FreeBSD “10.3” and “10.3 zfs” droplet templates, and I had recently upgraded the system to 10.3 using “pkg upgrade”. Could there be some unexpected interaction between my manually updated system and DigitalOcean’s droplet management scaffolding?

DigitalOcean tech support was supportive and tried to help, but in the end recommended starting over.

…it’s always going to result in some issues if you upgrade a Unix system’s distribution release in-place. We see it a lot in the Linux images where a release upgrade causes some random issues down the road, and upgrades tend to not work as well as anticipated. We would recommend setting up a newly built Droplet running the release you require and then to plan your migration of applications or data onto that new system.

I was disappointed with the recommendation to start over, especially as FreeBSD is well known for being able to update in-place. Not being able to update the OS might be OK for short-lived dev servers, and maybe for production servers with a team of people to do the work when upgrading is necessary, but it was not what I was expecting.

Resolution

In the end, the decision to re-host back to my own server came down to performance, anticipated future maintenance effort, and cost. Page loading was never really as good as I wanted, especially after restricting Apache to available RAM (although at least it stayed somewhat responsive). I also didn’t look forward to having to repeat the server migration when I was ready to upgrade to FreeBSD 11.0.

Already having a suitable server on hand (a de-branded HP media tower with an Intel 2×2.3 GHz CPU, 3 GB RAM, two 400GB drives), I installed FreeBSD 10.3 and started the migration. I’ll keep the droplet for experimenting, but for now it’s back to the basement for dalescott.net.

Dale

Transparency with Trust

Posted on

Is open-source right for you?

I was asked recently to quote installing a 5-user open-source ERP system. Unfortunately, as with anything technical and complicated, “it depends”. Open-source software provides an incredible opportunity, but both client and vendor business models are still not familiar to most people outside the open-source community, who largely perceive open-source software as simply a less expensive alternative to traditional proprietary software.

Try asking yourself these questions:

  • Are you familiar with open-source software, its goals and philosophies, and licenses, business models, and support channels?
  • Is there a strategic benefit for using open-source software in your enterprise? Does using open-source software enhance your competitive position? Will you be “doing things” that are impossible otherwise, and will it be core to your business model?
  • Have you yourself installed the demo version, figured out the basics of how to use it, and have demonstrated it to anyone else?
  • Do you understand the technology involved? E.g. ERP, PLM, the internet, IoT, cloud hosting, change management, etc.
  • Do you understand the software development process? Change management? Agile? DevOps? Bug tracking? Workflow and data pipelines?
  • Is your finance person tech-savvy?
  • Do you have internal IT group, or do you already have a relationship with an IT services provider, or hosting provider?
  • Will you be configuring the software yourself?

You should have many more “yes” answers than “no” answers if open-source is right for you. More “no” than “yes” either means you have more boot-strapping to do, or you should buy a commercial product or service (which may possibly use open-source software behind the curtain).

To simply install open-source software on a server at a hosting provider generally costs practically nothing, typically at worst a couple hours for someone qualified. Add to that operating hosting costs, internal or external. The real costs are learning how to configure and use the software for your unique business, how to live with, work-around or develop the missing features (that you and least one other person insist are essential <wink>), customizing reports, etc.

As with any software, it’s important to uncover areas of friction as soon as possible. Finding out late that meeting a hard requirement will be extremely disruptive does no one any good. Prototype your basic business workflows and get quick validation by pretending you are various users performing their typical work tasks. However, it’s the confusing tasks, the ones “that depend”, or the ones that “we don’t need to deal with that now” that will likely determine in the end whether there’s a good fit or not, and also the implementation effort that will be needed. You may not need solutions for what you find, but you do need to know where you stand.

Fundamentally no one else can do this for you, because no one else understands your business like you do. The alternative is to have a proxy, which can turn the project into a 6-month to 18-month effort, with multiple people, requirements gathering, competitive product research, shortlist, deep-dive prototyping critical workflows with each shortlisted product, etc., which often is then beyond the ability of an SME to support.

 

Posted on

Enterprise and Open Source – Copyright, Trademark and License

I am an engineer, not a lawyer, and this is personal opinion, not professional advice. Licenses and other legal documents can be complicated, and words like “meaningful”, “non-trivial” and the like may be interpreted differently based on jurisdiction, context and domain. Consult with a lawyer if it’s important, but it seems to boil down to the basics – copyright, trademark, and a license.

I won’t get into the reasons why an enterprise might care about being legally compliant and to what degree, but if it does, it will be considering liabilities imposed by its use of Open Source software. Liabilities carry strategic risk, which ultimately is financial risk.

The great advantage of Open Source software is that development and support costs can be shared among a community of interested parties, with individual modifications to meet unique individual needs. An Open Source project is essentially a partnership, with a large and diverse set of partners. This gives rise to issues of ownership and restrictions or liabilities.

If the liabilities associated with some software cannot be accepted, the software cannot be used. Unfortunately, it is also likely that the software cannot be used if there is a lack of clarity regarding liabilities. A project team that provides clarity regarding legal issues makes it easy for an enterprise to use their software, join their community and give back to their project.

Since an Open Source project is a partnership, with a large and diverse set of partners, it will require some degree of structure in order to function effectively. It will also want to protect itself against any ill will, internal or external.

In this article, I propose an approach for Open Source projects to protect themselves, and to provide the legal clarity that enterprises may require.

Ownership and Identity

An Open Source project is made up of more than just its code. An Open Source project is also a community of individuals, driven to achieve common goals and held together by a project name and on-line meeting places (typically the code repository, project website, mail list, issue tracker, forum, and wiki).

To ensure survival, the project team must protect itself against those who would do it harm – most commonly by using the project code or name for commercial gain against the intent and desires of the project team.

Copyright, Trademark and License

There are three tenants to protecting an Open Source project: Copyright, Trademark and a License. Copyright law will protect source code ownership, especially when the code is maintained in a secure public revision management system (e.g. GitHub). Trademark law will protect the project name and image against misuse, and a license will protect contributors and the community in general from liability, and protect access to changes if desired.

Copyright

Copyright is a legal concept that generally gives the author of an original work exclusive rights to their work. The copyright for a line of code is generally held by its author (developer), unless it is assigned to someone else. Assignment may be implicit, such as when an employee creates code for an employer (“works for hire”), or explicitly through a formal agreement, such as a Contributor License Agreement (CLA) or Copyright Assignment Agreement (CAA). Issue in licensing will arise if copyright ownership is ambiguous or unclear, because only the owner of a work can license it.

Open source projects generally follow one of two options:

  • Developers retain individual copyright to their code. Developers may declare through a Contributor License Agreement (CLA) that have the legal right to submit their code, and the CLA may include additional terms under which the code is provided.
  • Developers assign the copyright to their submitted code, using either a Contributor License Agreement (CLA) or a Copyright Assignment Agreement (CAA), to a legal entity used by the project team for that purpose.

Comparing the two, retaining copyright ownership without a CLA is the simplest although weakest legally, and any desired re-licensing will be difficult to impossible as it will require the explicit consent of all owners. Assigning ownership to single entity using a CLA or CAA will be the strongest legally, although it will be an obstacle to receiving ad hoc submissions from the community at large.

Trademark

Trademark law will provide practical protection of the project’s name, so long as the project uses the name in a way that can be trademarked, generally some type of logo. An individual (e.g. the project founder) or a legal organization owns the trademark (which preferably should be registered), and allows for its fair use by creating a Trademark and Logo Policy (e.g. the Maestro Trademark and Logo Policy, based on the Drupal Trademark and Logo Policy).

A Trademark and Logo Policy clarifies rights over the use of the project’s identity. Your name and logo are important to your community, and may want to create T-shirts, booth displays at trade shows and conferences, support material for clients, etc., that incorporate the project name and logo. The Trademark and Logo Policy controls their use to the benefit of the project as a whole, and provides a background from which abusers can be legally instructed to stop.

License

Generally, the simpler a license is the better. Some projects use different licenses for different things, such as the GPL for code and a Creative Commons license for documentation, I can only recommend using as few licenses as possible to achieve your purpose.

When it comes to the choice of license, use a permissive license (e.g. BSD, Apache or MIT license) if you want the software used by as many people as possible (in particular by enterprises wary of copy-left licensing). Use a copy-left license (e.g. GPL or AGPL) if you want to enforce that your code continues to remain Open Source.

The GPL generally requires that changes and extensions must also be licensed by the GPL, which is why technical and popular writing describe it as “viral”. Commercial enterprises can understandably react conservatively to issues that obligate, constrain or impose liability, reinforcing the value of a permissive license in the presence of uncertainty.

Should it be desired at some time to change the license, it is easier when a single entity holds copyright to the entire source repository, and harder if a large number of developers individually hold copyright to their own contributions – no matter how small. This can be both a benefit and a curse. Projects often start with a single developer who provides all the code, but ownership quickly becomes complex and intertwined as others first submit bug fixes, and then later provide entirely new features that cross the application. Consider the future you want for the project and plan for it, before it becomes too late practically to do anything other than start over.

Don’t think the source license will protect the project or software name. From the perspective of the license, the name is just a character string that can be changed like any other. Adding additional conditions to the license (essentially creating a new “license plus some stuff” license) only complicates licensing, making enforcement more difficult and impeding acceptance by reducing clarity.

Recommendations

Here are my recommendations for Open Source projects. Use your source code revision management system to your benefit by including legal notices and documents in your repository. That way they become integral to the project, inherently related in time to other contributions, and difficult to refute.

1. Include a License and Copyright section in the README file in the project source code, as well as prominently on the project website. State the license fort the code, and who owns the copyright. Describe any legal requirements for submissions, such as whether a CLA or CAA must be submitted first, or the terms assumed to apply to submissions (such as the same license terms as the project). Explicitly say whether the license covers Plug-ins or other extensions.

The GPL generally applies to Plug-ins, although some prefer to believe otherwise. Being explicit will avoid misunderstandings, clarify the intent of the project and even encourage development (as well as save you from repeatedly having to answer the question).

2. Include a Trademark and Logo Policy section in the README file in your project source code as well as prominently on your project website. State who owns the trademark/logo, whether it is if registered, and describe what will be considered fair use (and what will not).

3. Publish a list of the Open Source projects included in your own project, including the license each uses. This makes it easy for potential users to readily and properly evaluate all their implications. Ensure each included project identifies its own license in your repository. Compliance is a chain, the legal clarity of subordinate projects is just as important as your own. If necessary, work with subordinate projects to improve their legal clarity, it will benefit you both.

Related Information

TWIT.tv‘s FLOSS Weekly podcast (hosted by Randal L. Schwartz of Perl-book fame) has interviewed several project teams that had to deal with licensing issues.

Bob Jacobsen had to regain control over the Open Source model railroad controller software he had written in order to clear his name professionally. See FLOSS Weekly Episode 117 and Java Model Railroad Interface (JMRI) in Wikipedia.

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.

 

Posted on

Full Custom – sometimes the only solution

Maestro is again a ground-up Yii-based application, and has been merged with the previously separately developed SCC dataset in a single Maestro repo.

Recent explorations of OpenERP (now Odoo), Tryton and ERPNext provided useful insights into user interface and implementation alternatives. However all were found missing fundamental relationships critical for Maestro, such as issues to parts, issues to stock items, stock items to projects, and general management of serialized stock items. Further, although these “high-level frameworks” have many advantages, the time and effort required to become useful developing with them was found to be not insignificant. Finally it was deemed more efficient to scale back requirements in return for more immediate progress towards a minimum viable product.

A new demo system has been created on swiftconstructioncompany.net. The code currently running is from early 2014 (before development was halted to investigate OpenERP, Tryton and ERPNext), but will be updated after overhauling the database schema. When the demo is complete, it will include a local email server with webmail client for viewing user mail, and an LDAP server for user authentication.

A virtual machine will also be made available for download if there is enough interest (please indicate interest using the contact form).