Author: dale

I started as a technician, first setting up sound reinforcement and projection equipment at a convention facility, co-founded a DJ business and constructed our PA system from scrach, then got into electronics maintenance and repair at a community college. After obtaining a university degree in engineering, I designed integrated circuits for the first generation of 900 MHZ analog cellphones, the first generation of CA-code-phase tracking GPS receivers and digital pro-audio. I then progressed through a variety of leadership roles in product management, marketing, engineering product development and manufacturing, in fields such as industrial GPS-based positioning and navigation, pipeline integrity inspection and industrial process control.
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

ATK rocks on!

I received a blast-from-the-past email yesterday wanting to know how to format  ATK code for submitting a patch. I was going to simply refer them to the ATK GitHub project I helped create, but then thought I’d better check and see what’s been happening in the project lately (regular readers will be know I’ve been developing with Yii for the past couple year).

I was pleasantly surprised to find the project has been forked, and there’s been a lot of new development supported by the Italian company Sintattica. ATK was originally developed in Belgium, which proves open-source knows no national boundaries!

The new project still has some community relations work to do as the links and developer information in README.md haven’t been updated since forking, and there doesn’t seem to be a public issue tracker, but it seems ATK could be off to a great new beginning. There’s even a new development branch featuring PSR-4 compatibility and a modern class system!

It’s great to see ATK continue as a presence in the rapid web app development space, and it’s rewarding to think my efforts migrating the source from iBuilding’s Subversion repo to GitHub may have helped in some small way. With the buzz that new fad frameworks attract from their fanboyz before fading away, it’s refreshing to see a truly innovative idea continue. Thanks iBuildings and Ivo for starting the project, and thanks Sintattica for your support.

 

Posted on

TI CCS 6.1.1 and MSPWare MSP-EXP432P401R Example Projects

CCS 6.1.1 included updates to the default MSP432 linker and startup files (copied to a new project created in CCS), but unfortunately it seems the example projects in MSPWare didn’t get the same update.

The fix is simple. After importing an example project into CCS from MSPWare, edit msp432_startup_ccs.c and add “#pragma RETAIN(interruptVectors)” before building and debugging.

Now for the fun bit. If you tried building and debugging BEFORE editing the startup file, you likely loaded crap onto your MSP-EXP432P401R and now it’s bricked (except for “Error -1063” when you try connecting to it from CCS). If that’s the case, perform a factory reset of the MSP-EXP432P401R first to wipe it clean, then load a good build.

Summary of the problem, cause and workaround:  https://e2e.ti.com/support/microcontrollers/msp430/f/166/p/460430/1663082#1663082

How to perform a factory reset: https://e2e.ti.com/support/microcontrollers/msp430/f/166/p/465581/1671110#1671110

 

Posted on

Open Source Software – Copyright, Trademark and License

I am an engineer, not a lawyer, and this post is not professional advice. Legal documents can be complicated and interpretation may depend on jurisdiction, context and domain. You should consult with a lawyer if the risks and consequences are important to you.

Open source software is a concept that enables software development and support to be shared by a typically non-competitive community. An open source project is more than just code, it is also a community motivated by common goals and bound together by the relationships formed by working collaboratively.

Open source projects use one or more forms of intellectual property (IP) rights protection to protect itself against being taken advantage of. These are copyright, trademark and license. Copyright protects ownership of the software source code, trademark protects the project name and image, and a license protects the project community from liability.

Copyright

Copyright is a legal concept that 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).

Open source projects generally follow one of two options:

  1. Contributors retain individual copyright to their contribution. Author of have an inherent copyright to the code they write, but to limit liability, some projects require contributors to submit a Contributor License Agreement (CLA), which states they have the legal right to provide their work to the project and any conditions they impose (e.g. the license).
  2. Contributors assign their copyright to a legal entity used by the project for that purpose, using either a Contributor License Agreement (CLA) or a Copyright Assignment Agreement (CAA).

Open source projects most commonly follow Option 1, in particular ad hoc projects. As a side-effect, it makes re-licensing almost impossible as it would require explicit consent from all copyright owners. Option 2 is most common when the project uses multiple licenses for different users (e.g. an open source license for some and a proprietary license and revenue opportunity for others), or if the project doesn’t want to preclude potential re-licensing in the future.

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 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 the better but some projects use different licenses for different things, such as the GPL for code and a Creative Commons license for documentation.

Use a permissive license (e.g. the BSD, Apache or MIT license) if you want the software to be usable by as many people as possible. Use a copy-left license (e.g. GPL or AGPL) if you want to enforce users giving back. Commercial users may be wary of copy-left code in general, as it requires more thorough consideration to ensure the copy-left license won’t be applied to more code than intended once it is integrated.

Recommendations

1. Include a License and Copyright statement in the project source code (e.g. in a README file), and also state prominently on the project website. State the license for the code, and who owns the copyright. Describe any legal requirements for submissions, such as whether a CLA or CAA must be submitted first, and 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 is generally understood to apply to Plug-ins, but being explicit will avoid potential misunderstanding or disagreement, clarify the intent of the project and even encourage development (and save you from having to repeatedly answer the question).

2. Include a Trademark and Logo Policy statement in the project souce code (e.g. in a README file), and also state prominently on the project website. State who owns the trademark and/or logo, whether it is registered, and describe what is, and isn’t, considered fair use.

3. Publish a list of open source dependencies (the open source projects that your project depends on), including the license each uses. Make it easy for potential users to evaluate the implications. Ensure each included project identifies its own license in your repository. If needed, work with subordinate projects to help improve their legal clarity as it will benefit both of you.

Related Information

Bob Jacobsen had to regain control over the open source model railroad controller software he had written 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 when he was as an employee of the Porto Rico government, and also had to deal with an early fork that threatened the project’s future. See FLOSS Weekly Episode 253.