The Ins and Outs of the GPL (General Public License)

Since the software for the DPU-550 has been released under the General Public License (GPL) I thought a discussion regarding the ins and outs of the GPL would be a appropriate.

First, the GPL is not a copyright.  The author of a project may retain the copyright to his works.  Likewise any person who modifies the GPL program may hold a copyright on his modifications, although he must release them under the GPL.  The GPL is a contract between the copyright holder and the general public.  And like any other contract, it is binding upon all parties (in this case the copyright holder and the general public) and cannot be unilaterally modified by either party.  The implications of this are particularly significant to the copyright holder (author of the program).  Once he released a project under the GPL, he cannot withdraw that project from the terms of the GPL.  In addition, since all the terms of the GPL are binding upon the copyright holder as well as the general public, subsequent derivatives by the copyright holder from the original GPL work must also be released under the GPL.

If subsequent versions were not released under the GPL then copyright holder himself would be in violation of the GPL license, UNLESS there has been a total re-write.  Even then it would be hard to show that the re-write had none of it's origin in the original code, especially when done by the person who was the primary author of the original code, or "manager" of the project if the code was a collaborative effort.

One particularly damaging aspect to a violation of the GPL license is when a project is developed in a public forum (such as a Yahoo group) as a GPL project and the originator or coordinator of the project subsequently attempts to "close" the code.  This could not only be viewed as a violation of the GPL license, but also as a criminal violation called "Fraud by Inducement".   In other words, the originator has invited the public to contribute to the project under the "inducement" that the project is an GPL project.  Then when the venture is taken commercial, the originator withholds the source of the commercial version of the project.

Basically the GPL license says this:

1. The code is free to anyone for any purpose, even commercial.

2. Each file that is necessary to produce the finished product (in most cases the compiled binary or hex code) must be included and must be released under GPL.  This includes linker files and other "support" files.  The only files that can be excluded are files that are publicly available, such as header files from the MicroChip or Atmel library.

3. If any person distributes ANY derivative of the original project, that contains ANY of the GPL code, the entire derivative must also be issued under the GPL license and meet all the conditions of distribution found in that license.  No portion of a derivative of a GPL project may be "withheld" as proprietary code.

The exception to the entire "perpetuation" concept of the GPL license is when you develop a derivative and use it only for yourself. But if you share a copy with your buddy down the street, you've come under the provisions of the GPL license.

While the GPL requires that any GPL project be freely available to anyone who wants it, it does not require that the author (original or subsequent) provide the mechanism for distribution.  You don't need to maintain your own server, or have a web site.  You can use any public distribution forum (that does not charge for access) such as SourceForge, as the distribution mechanism.

If the GPL project must be free, how can it become a part of a commercial venture?  MySQL is a perfect example of a GPL program becoming a public venture.  MySQL can be downloaded for free from the MySQL web site (as well as other sources), but if for some reason you want it delivered on a CD, the MySQL group charges for this service.  Likewise they provide a wide range of for pay support services, from the installation of MySQL on your machine to annual contracts to manage your MySQL installation.

The DPU-550 is another good example.  The software for the DPU-550 is of little value with the DPU-550 itself.  The sale of the DPU-550 provides a source of revenue for Scott Shumate, the designer of the DPU-550 and author of the DPU-550 software.

Another source of revenue is providing coding services for someone who wants a particular feature added, but doesn't want to wait for it to come about through the public process.  A programmer may charge for the service of modifying the code.  This does not negate the GPL status of the resulting code.  The derivative project must also be GPL.

So can you modify a GPL program and withhold your modifications if all you distribute is the binary (executable) version of the program?  The answer is a resounding NO!  The binary is impossible to produce without the source code, therefore the entire project remains a GPL project.

Another question that might be ask is if running a GPL program in conjunction with your proprietary project will require your proprietary project be consider a GPL project.  The answer is generally no.  Linux is a GPL project.  Running your proprietary program on Linux does not require that your proprietary program be made GPL.

Likewise interfacing with a GPL project does not always require that the interfacing project be GPL.  If the GPL project has been designed with APIs (Application Program Interface) which do not require any portion of the code from the GPL program be included in applications using the API, the resulting program, using the APIs, is typically exempt from the GPL requirement.

A word of caution is warranted here.  Suppose you have an idea for an enhancement to a GPL project but you wish to retain the right to not disclose the source code of your work.  You decide that the way to do this is to create an API within the GPL program and have your project communicate through this API.  You would probably still be in violation of the GPL.  Much would depend upon the timing (does the history of your project precede the development of the GPL project?).  Also does your program have application to other programs, whether or not GPL?  How extensive were the modifications that were made to the GPL project?

Before embarking upon such a venture I would carefully weigh the potential rewards of keeping my program to myself against the potential cost of defending a lawsuit, not to mention that you might loose.  Remember the GPL is essentially a contract with the world.  Any person wanting access to your source code may have standing to bring suit against you.

The GPL license is a contract enforceable under the law and a violation of that contract is subject to various commercial contract laws. It's hard to conceive of a situation in which products developed and/or distributed using the Internet would not be considered Interstate and thus fall under Federal Statutes as well as State Statutes.

An interesting thing about this is since the 'P' in GPL stands for "Public", the entire population of the world could conceivably be considered members of a class action suit.  Actual damages would most likely be narrowly defined but punitive damages could be huge if a jury viewed the violation of the GPL license as a violation of the public trust.  I would hate to be a developer (standing in front of a jury) who has originally produced code under the GPL license, especially if he received input from the public, such as through a Yahoo group, and subsequently attempted to "close" the code when the product becomes a commercial venture.

In other words, it's best to abide by the GPL license and avoid the possibility of someone with deep pockets bringing suit.

I've pointed out the negative aspects of the GPL, although they are negative only if you violate the GPL.  But the real purpose of this column is to encourage anyone who wishes to use a GPL program to do so.  Modify it in any way you want.  Use it in any way you want.  You don't have to ask permission from anybody.  Many GPL programs have moderators or managers.  The purpose of this is to organize a group of people who want to contribute to a project into a cohesive unit.  But you don't have to participate in the group.  Managed or not, it's still a GPL project.  If you want the project to go a different way, strike out on your own.  Form your own group of like minded people.  You can even continue to use new code from the original group as you take the project in your chosen direction.  The only requirement is that if you distribute (or make public) your modifications, it must be released under the provisions of the GPL.

It is worth noting that not every project that is publicly released is a GPL project.  A developer may release the source to a project and still retain all copyright privileges.  In other words, he can withdraw the project from the public venue at any time he sees fit.  The rub here would be if he has incorporated contributions from the public into the code and then withheld it, especially if he goes on to earn commercial gain.  This again could be considered Fraud by Inducement.  If you plan on releasing something to the public but retain the right to withdraw it at a later time, it is advisable to disclose the terms of this up front.

In addition there is a big difference between a GPL project and something that is in the public domain.  Items in the public domain do not carry with them the requirement to acknowledge their "heritage" in derivatives.  There is no copyright associated with a public domain project.  The author of the program has "gifted" the copyright to the project to the entire world.

So why does GPL exist if a program can be "gifted" as a public domain program?  Because the GPL carries with it the requirement that you "pass it on".  No such requirement accompanies a public domain project.

So make the world a better place.  Go find a GPL program and improve it.  Better yet, invent a better mouse trap and give it to the world under the provisions of the GPL.

GFB

SO IS THE DRO-350 AND THE 16F876 PIC REALLY A DEAD-END STREET?

Several reasons for the DRO-350 being at a dead-end are given. I discuss some of them below.

A compiler for the PIC series of processors is too expensive.

While the “Official” compiler from MicroChip, the compiler with which the original code for the DRO-350 was developed (Scott had access to it at one of his employers/clients/friends), is very expensive, there are several high quality C compilers available for as little as several hundred dollars. These compilers utilize the same libraries as the MicroChip compiler (the libraries are free from MicroChip).

Several hundred dollars is not pocket change to most of us, but not particularly out of line when you are talking about keeping the DRO-350 alive in it’s present state (i.e. price).

In addition, MicroChip offers a very sophisticated Assembler as a part of it’s free Integrated Development Environment.

I have one of the third party C compilers as well as the free PIC IDE. I don’t think there is anything that can be done with the MicroChip version that can’t be done with the third party versions. Mine (the C compiler) even has support for the various In Circuit Debuggers that are available from MicroChip and other vendors.

Moving from one compiler to another is not an trivial task, but again, when we are talking about extending the life of the DRO-350 for what is probably 1000’s of existing users, a bit of effort is worth while. Portability, not just for moving from one platform (computer type, MPU type, etc) to another, but also moving from one compiler to another, is one of the reasons we use high level languages like C.

The 16F876 is “maxed” out.

Yes, the 16F876 is stretched to the limit when it comes to memory. But there is a bit of room available, and certainly enough room to correct bugs. And if the software were made Open Source (it’s supposedly been made obsolete by the DPU-550 which offers Open Source software), there would be many hands that would gladly apply their effort and imagination to getting the last few drops of functionality out of the current MPU. This has already been done by members of the group who have disassembled the DRO-350 code to make changes.

THE DPU-550, A MUST HAVE OR CAN YOU LIVE WITHOUT IT?

There has been much discussion about the “dead-end” status of the 16F876 MPU (the MPU currently found on the DRO-350). It has been stated that it is at EOL (End Of Life) for several reasons.

The DPU-550 extends the functionality, and thus the life of the DRO-350. It sports a 50mhz ARM7 processor (MPU) by Atmel and has a boxcar’s worth of memory when compared to the DRO-350’s PIC16F876A. It’s a 32 bit MPU (as compared to the PIC16F876A, which is 8 bit) which makes for much faster processing, especially when math operations are involved.

The DPU-550’s two variants give the user the option of a basic processor upgrade, with a bit of additional functionality, for a current price of around $50.00, which will include not only the DPU-550 board, but all the internal cables, etc., necessary to use the additional functionality.

The big increases in functionality come in the form of the ability to support four different scale protocols, two additional Auxiliary inputs (Edge and Tach) and the ability to communicate with a computer through a USB port.

The DPU-550 Lite can be field upgraded to a DPU-550 Full which will add two additional scale inputs, two more Aux inputs, true RS-232 and a souped up 5vdc power supply to power up to five glass scales.

Field upgrading is not for the faint of heart in that most of the components are surface mount (SMD). If you attempt it, you need very good soldering skills, the proper tools (an SMD repair station would be nice) and a bit of patience. Attempting it when the DPU-550 is “new”, that is none of the through hole components have been mounted, is “doable”. But if you’re attempting it after the DPU-550 Lite has been populated with the through hole components, you’re going to be working in some pretty tight quarters.