Cacti Makes Device Monitoring Simple

Every organization must monitor its infrastructure’s uptime and performance. While the popular Nagios application is a good general-purpose monitoring program that you can extend with plugins to handle just about any task, you may do even better by employing Cacti as a graphical front end to RRDTool‘s data logging and graphing functionality. Cacti was developed specifically to monitor and collect performance information, while Nagios is more oriented toward state changes, such as noting whether a daemon is up or down.

View the full article here

 

Build Cross-Platform GUI Applications With wxWidgets

If you develop GUI applications, you probably know what you want from a toolkit or framework. Chances are that the ability to build apps that run on multiple platforms is high on the list, along with ease of use and deployment. Those are among the strong points of wxWidgets, an open source library designed to make it easy to create cross-platform GUI applications.

View the full article here

 

ViewVC Helps CVS and SVN Go GUI

Almost everyone who works with version control systems (VCS) feels the need, sooner or later, for a graphical interface, because sometimes a GUI makes your life easier. ViewVC is a full-featured browser interface that’s portable as can be, given the design choice (web-based) and the programming language (Python). It was originally created for CVS users and later extended to support Subversion as well.

View the full article here

Using Nagios to Monitor Your Clusters' Health

The Nagios network monitoring and alerting framework lets you easily keep track of a wide variety of hosts and services, and generate reports and alerts targeted to specific teams or individuals. By using plugins, you can further enhance Nagios’s functionality, giving it capabilities not available in the core product. One such plugin lets you monitor the health of your cluster instead of that of individual hosts.

View the full article here

Must Know WordPress SEO Tricks

Many new WordPress users are under the impression that WordPress already takes care of search engine optimization (SEO) upon installation. However, the out-of-the-box WordPress installation that most people rely on doesn’t offer the best SEO results possible. If you want your WordPress sites to rank as highly as possible on search engine results pages, adopt the following techniques to enhance your sites’ placement in results from Google and other search engines.

View the full article here



Follow @openlogic
Follow @cloudswing

Subscribe to The Enterprise Open Source Blog by Email

This work is licensed under a Creative Commons Attribution 3.0 Unported License
.

The SPDX License List is just one part of a larger effort to make reporting open source software licensing information more efficient and thus ease license compliance.  As an active member of the SPDX legal work group, it began as a simple matter of raising my hand that I took on the task of 'keeper of the list.'  Or so it seemed.

When I began working at OpenLogic, my first task was to read all the most commonly used open source licenses, analyze the license requirements, and help create the framework which would become the OLEX Open Source License Compliance module to our scanner.  This necessarily brought up some tangential questions.  Do we have this license already in our database and, if so, is it truly the same license?  At what point does it become a different license?  What is considered part of the license text and what isn't?  What should the license be called?  How should the formatting look when the license is displayed on the page? Later, my role would evolve to include using our product to perform open source audit services for our customers.  There is nothing like drinking your own Kool-Aid to encourage improvements at the macro and microscopic level.

Now, let's just be clear; I am not a developer.  I managed to teach myself basic html and css to round out my interest in graphic design and support a side business building static websites for the small businesses of friends and relatives in a previous life.  This means I have just enough knowledge of website coding to make me dangerous. Combined with a strong opinion about the way things should look and a meticulous eye for detail (some people refer to this as perfectionism, but one look at my garage would disqualify me from that classification) means I have spent more time than I wish to admit thinking about things like whether to use bullets or numbering as the list-style for the clauses of the BSD license and making up "rules" to ensure that all the red-headed step-children that are open source licenses are treated equally and consistently in order to make our tool reliable, predictable, and practical.  So, it is really quite appropriate that I fell into the role of the keeper of the SPDX License List.

What is the SPDX License List?

First you may be wondering, what is SPDX?  The Software Package Data Exchange® (SPDX™) specification is a standard format for communicating the components, licenses, and copyrights associated with a software package.  The idea began as a way to reduce redundant work across the software supply chain.  By creating a common format to report data about software licenses and copyrights, license compliance is then also facilitated.  Software, systems, and tool vendors; foundations; open source services companies; and systems integrators work side by side to develop the specification as a collaborative effort under the SPDX work group, which is hosted by the Linux Foundation.  The first version of the specification was released in August of last year, with version 2.0 in the works as you read this.

In the early days of the specification development process, it became apparent that a way to refer to common open source licenses by a short reference would be very helpful and reduce the amount of information contained in an SPDX file.  Thus, the SPDX License List was born.  The license list contains the full name of the license; a standard identifier; a url to the official version of the license and to the Open Source Initiative (OSI) website if the license is OSI approved; the license text itself; and any official license header as suggested in the license.  Then there is the need for some kind of matching guidelines to make sure that when one SPDX user identifies a license as "Foo,” it is indeed the same license as what someone else identifies as “Foo” and the same license as what is listed on the SPDX License List.

Of course this is not the first list of its kind or endeavour to reach such goals.  Increasing feedback and participation in the SPDX legal work group indicates that many others either have their own such similar effort or would appreciate being able to adopt a list already created.  Because the thing is, creating such a list and its attendant guidelines is not nearly as easy as it sounds.  Yet, wouldn't it be nice if we got to a point that when someone says "BSD 3-clause," we all - the collective and sometimes cacophonous world of open source software - would know exactly what that meant?

What's in a name?

That which we call a license by any other name may smell as sweet, but how does one decide what to call it to begin with?  Let's take the BSD License for example.  If a file states, "This file is licensed under the BSD License," do you really know which one?  There are three different BSD licenses: the original 4-clause license that included the advertising clause; the "revised" 3-clause license, which is probably most used today; and the simplified 2-clause version.  Then there is the fact that the University of California rescinded the problematic advertising clause, thus effectively turning the 4-clause license into the 3-clause version for any UC Berkeley copyrighted code.  FreeBSD and NetBSD both use a 2-clause version, but with additional text included at the end or beginning, respectively.  And while there may be some who say, "who cares?" the difference can be material, and moreover, where accuracy is the goal, such differences cannot be ignored.  These are some of the questions that need to be confronted and decisions that need be made.

What better group to work on such a task than a collaborative collection of players from across the open source software space?  In the same way that Linus Torvalds' harnessed the collective intelligence of many developers to create Linux, so too can we for creating a way of referring to licenses that addresses all the detailed considerations.  The SPDX License List, due to its inherent nature of filling the needs of many, could just prove to be the gateway drug to overall adoption of the full SPDX specification.

If you have yet to, get involved!  Join one of the SPDX work groups and mailing lists (general, technical, business, or legal) here:  http://spdx.org/wiki/spdx

Let me take this opportunity to give a huge thanks to the tireless participants of the SPDX legal work group (you know who you are!) - while there is much more work to do, we have come a long way in a short time.  Cheers!


Subscribe to The Enterprise Open Source Blog via email

Follow @openlogic
Follow @cloudswing
Follow @jilaynelovejoy
View Jilayne Lovejoy's profile

This work is licensed under a Creative Commons Attribution 3.0 Unported License
.