March 25, 2005
Details about Microsoft, Open and Shared Source
In my video I mention that many companies are participating in open source of various sorts, including Sun, Microsoft, and others. Here's some additional material on that.
David Berlind of ZDNet has posted a 1 hour MP3 podcast of an interview with Microsoft's chief strategist on open source, Jason Matusow. David also has a write up on his blog of it, complete with some comments about how it relates to his interview with SpikeSource's Kim Polese. I found the Matusow interview fascinating. David is pretty well steeped in Open Source thinking and does ask some good questions. Jason is also clearly well versed in the details of Open Source and gives answers that are hard to condense into a short blog post (he also has a new blog of his own where he tries).
Jason makes it clear that Microsoft is releasing the source code to various pieces of software under a range of licenses. Some of it is under OSI-approved Open Source licenses such as the CPL. Some of it (e.g., Windows) is under more restricted "read only, don't modify" licenses. He also reminds us on his blog that Microsoft Research participates in some OSS projects directly. Microsoft is clearly feeling its way in the sharing world and this is evolving in ways that people may not have anticipated a couple of years ago. It's worth it for other "direct sale of software" companies (a term he uses at time 2:30 on the MP3 and contrasted with those that make their revenue "indirectly" from software through services, hardware, etc.) to watch them carefully and learn.
Having listened to several of David Berlind's podcasts recently, you can see that he frequently brings up questions of interest to the Open Source community. He is currently trying to get as much of his "source" material as a journalist as possible into sharable form and providing a lot of it in downloadable, MP3 podcast format which you can listen to on most personal computers and portable MP3 players. See his "How to tune it" page for more details.
Posted by danb at 11:18 AM
March 24, 2005
A theory about extreme fear of the GPL
One thing that has always puzzled me was why companies have such a strong fear that the GPL could cause them to inadvertently "taint" all of their code and be "forced" to "give it all away". My reading of the GPL and commentary about it and discussions with many others doesn't make it sound so extreme or automatic. That's one of the things I cover in my video. You have problems if you inadvertently release your proprietary code along with a piece of GPL code, but often not insurmountable, draconian ones.
I think I have an idea where some of the false "deadly, contagious jungle virus with no cure" image may have come from.
It is clear from my research and experience that people who aren't steeped in copyright law and Open Source licensing and terminology frequently get confused between "Open Source" and "Open Standards". This was one of the things I learned when working with the Massachusetts State IT people and their initiatives. Explicitly breaking apart "Source" and "Standards" helped clarify things to outsiders, and calmed people down. This word "Open" seems to throw them off. Remember, most regular people don't know what "software" is, let alone the line between a standard like XML and code like an XML parser.
I attended a seminar a couple of weeks ago at MIT on "Best Practices in Standards Setting" put on by the law firm of Preston Gates & Ellis and Kavi Corporation. There was a lot of the nitty-gritty of running a standards organization. There was a lot of discussion about patents. I learned an awful lot about the politics and business competition aspects of standard settings. Very eye opening, but not the subject of this post.
The thing that struck me was the discussion of the RAMBUS case, and also Dell's experience with the VESA VL-bus. In those cases, as I understand it, participating in a setting of a standard could automatically cause the patent holder to lose the ability to enforce their patent (and did in Dell's case as the FTC press release linked above explains). A third party could bring suit (unlike the GPL where the copyright holder has to assert their rights against you). It was explained to me that there is a trumping of patent rights (a "legally granted monopoly" as set forth in the U.S. Constitution) by anti-trust law (for misusing a monopoly or something).
Ah, ha! Here was a case where being involved with something "Open" caused you to lose your rights and you are forced to "give it away". Maybe some people were mixing the two up in their head? At a senior level in a big company, the distinctions between different types of IP like patents and copyright and the different types of "Open" get lost. There's just "Open" along with "lose rights". Then you add the reciprocally of the GPL and, voila!: Fear. Don't laugh, saying people can't think this simply (well, do laugh): Yesterday's Dilbert comic confused copyright, patent, and trademark into something wrong, but I bet most readers don't know it.
I wonder, is there anything to this observation about Dell/RAMBUS and the GPL fear?
Posted by danb at 04:00 PM
March 14, 2005
A detailed synopsis of the draft video
Here is a rather detailed description of what I cover in the alpha video. I'm very interested in what others think. Am I covering the right material for corporate developers? Is it detailed enough? Is there material that I should remove or material that I should add? Is it legally and factually correct?
Note that I am not trying to sell people on whether or not open source software is the main way to go. I am not talking philosophy. I am not trying to make legal determinations, such as where to draw the line when combining GPL and non-GPL code. I am not trying to help you choose a license for your software. These are areas the corporation has to address itself. I am told that it is best to keep training videos short, preferably well under half an hour. This is already 50 minutes long (though I hope to trim it some) so adding a lot of new material could be a problem.
Please email me any comments or questions at the address below.
COPYRIGHT, OPEN SOURCE, AND WHY A LAWYER IS A DEVELOPER'S FRIEND
Version 0.2
Introduction and overview
An introduction to some basics about copyright and software licensing from a developer's viewpoint with special emphasis on open source software issues so that you have a better understanding of what is required of a software developer in that area and why. This does not cover patents, trademarks, and other Intellectual Property issues, nor philosophical issues.
Who is this for? Software developers, corporate management and corporate counsel (internal and external) as a catalyst for discussing these issues with developers.
Disclaimer: Dan is not a lawyer. Talk to your own lawyer for legal advice.
Outline of the video.
Access to source code
Having access to source code of an existing program is important in software. You learn by looking at previous work, both general learning about an area or language as well as how to achieve specific functionality.
In addition to learning, you reuse existing code. Sometimes the reuse is as a component and sometimes it is the basis for building upon.
Examples of using the code of others range from books and magazines to entire open source applications.
Copyright law
Copying is regulated by Copyright Law. It defines special rights held by the author that are not automatically given to others. They include the exclusive rights to: make copies, create derivative works, and distribute copies (including of the derivative works).
Copyright applies to “expression” but not ideas. There is a fuzzy line between them sometimes, which is where lawyers come in. There are concepts you may have heard of such as Fair Use and the Public Domain. For software copying of any substance in a corporation Fair Use probably doesn’t apply. Unless you have specific proof otherwise you should also assume that any given piece of software is not in the Public Domain -- lack of a copyright notice does not automatically place something in the Public Domain.
Combinations of works and additions of new code result in more than one author with rights. The new person’s rights do not overrule the first person’s.
Author’s can assign their rights to others.
Variety of licenses
Without the author’s permission you can’t do much with a work. They can stop you from making copies, getting monetary damages, and there could even be criminal penalties. Don’t assume that you can get away with it and that nobody will find out in today’s world.
The author gives you permission through what’s known as a license. The license is a bargain with the author. The author will allow you to do certain specific things that you wouldn’t otherwise have permission to do under copyright law. In return you have to take specified actions and abide by specified conditions.
The things they allow you to do may include running the program on a particular computer or perhaps distributing copies of a runtime module. The conditions may include paying money or displaying a particular notification on copies.
There are a wide variety of licenses with a wide variety of terms in them. Examples of traditional licenses are some on prepackaged software that have different criteria for which computers you can install your copy on. They also sometimes have seemingly unrelated terms that meet the author’s business needs.
One class of licenses consists of what are called open source licenses. In some respects these may have terms similar to other licenses, such as disclaimer of warranties. In other respects they are different. They are often called “free” as in “unconstrained”. The freedom is usually meant in respect to the source code. There is software without access to source code that has no fee and some open source software is often purchased for a fee along with support or other additional benefits.
Common attributes of open source licenses include access to the source code, free redistribution (both without fee and without restrictions), and permission to create derivative works. Additional elements of the bargain may include keeping the author's name with any modifications, indicating changes, and restrictions on the terms of licenses put on derived or collected works that include the original code.
Terminology
Be careful with terminology with regards to open source. Many people distinguish between "Open Source" and "open source". The former often refers to licenses that meet all the terms of the Open Source Initiative, a non-profit organization. Other licenses might still meet your needs.
There is "Open Source" vs. "Open Standards" and "Open Formats". One refers to the program source code, the others to data formats and the method of communication between programs.
While much open source uses open standards and open formats, there are a lot of proprietary software products that support them, too.
Many licenses
There are many licenses to keep track of, and there are new licenses coming about all the time, each a bit different, to meet the needs of certain authors. Examples are Sun with some of their software and Microsoft with various file formats and how you can examine their source code. There are also cooperatives with corporate or government membership that have agreements on how they share code.
Dual licenses
Owners of the copyrights can release their software under multiple licenses with different terms to give you a choice if one doesn't meet your needs. Licensors have always made special deals with certain purchasers, such as large corporations or governments, but the restrictions of some open source licenses, and the desire of some companies to easily avoid those terms (and being willing to pay for it), is bringing this to the fore.
License compatibility
When you have collections of works or new and old code combined in a project you have to be careful that you don't have any conflicting requirements between the different licenses of the components. For example, the GPL license does not allow code licensed under it to be redistributed with any further restrictions in a license. Those disallowed restrictions could be adding a special notice or having additional restrictions on copying.
New emphasis on licenses
People with experience in programming may comment that there didn't used to be such attention to licenses and copyright as there is now. Why?
In the old days, the copyright licenses were quite short. There are lots of examples to show that. Now they are much longer with many more terms and details of exactly what you can and can't do.
I think that many things have made people more sensitive, such as the SPA/BSA software anti-piracy campaigns, Napster and the RIAA, and the SCO lawsuit against IBM involving Linux. In that last case, first people worried about Linux, and then with the good defense so far by IBM and the Linux community corporations wondered "If somebody sued me, can I trace the pedigree of all the pieces of my software that well?" Corporate ethics issues and Sarbanes/Oxley have made corporations more sensitive to doing the "right thing".
Finally, the success of Linux and open source has made people sensitive to the fact that licenses do matter and can have great effects.
The GPL
Many open source licenses come as templates that authors just copy and use with their software. Some like the Apache and MIT licenses have very few restrictions on what you can do with the software. They are compatible with many other licenses.
There are a set of licenses, especially version 2 of the GPL, that are different. The GPL is probably the most popular license for many reasons. In addition to letting you use the code and make copies, it requires that modified versions be licensed as a whole at no charge to third parties under the GPL. This is a "reciprocal" or "viral" license.
The word "viral" conjures up an image of a jungle disease where you just breathe on someone and they catch it and then pass it on to others -- that you just "touch" a GPL program to another and it becomes covered by the GPL and you can't undo it. That's not exactly the case. The GPL says that code you write yourself does not become GPL automatically when distributed by itself. What is says is that without following the terms of the GPL and releasing your derivative works, etc., under the GPL you have no right to distribute code covered by the GPL, so you'd have a copyright infringement. It doesn't force your code into the GPL, but if you were sued by the author for copyright infringement, then turning around and releasing it under GPL would be a defense. You could also make a deal with the author (as the GPL suggests may be possible in some circumstances, depending upon the author) or perhaps retrieve all the copies and remove the GPL code.
Different authors have different interpretations of the terms in the GPL, such as what a work "based" on another means. Some are narrow and some are very broad.
It matters who the author is, since the author needs to be involved in asserting rights against you. By my reading, a third party who isn't the author can't assert that you mixed your code with GPL and therefore all of your program is now automatically under the GPL.
Many companies have figured out how to use open source software in their work, even GPL code, and still coexist with proprietary and other licenses. You can't always do it, but it's worth looking into. Don't panic and have a blanket prohibition against GPL, but also don't ignore its terms.
What have we learned so far?
Need to know fine points of each license. Need to know the licensor and license for each piece of software you use. You may need to make separate deals with authors. Code architecture needs to take into account legal and business issues, not just technical and usability issues.
The law, lawyers, and corporate executives
While we'd like "bright lines" separating things like whether or not your new program is "based upon" another piece of code or not, or whether something is an idea or expression, in reality things are often fuzzy and you need the advice of experts. You look to case law -- what judges have decided in the past. That is a lawyer's job, as well as to understand all the legal terms in the licenses. They can help you work things out, and lay out the risks where things aren't certain. They can also help draft deals and modified licenses. They can be your friend in working these things out.
The company executives have to decide the business models under which the company makes money and which risks it takes. They also can help with making the deals with outsiders.
Corporate software license policy
You need to have one. What's in one? Defining the meaning of terms. Listing which risks to take and which not to take. Listing decisions to be made and how to make them, including how much to participate in the community around a product, if at all. Listing the records to keep. Auditing.
Dealing with licenses with software you distribute
You need to decide under which license you release your software. If it includes other software you have to deal with any requirements and restrictions of the licenses for that software. There are cases where you may need to avoid reciprocal licenses like the GPL. The uncertainty may be too great for your company or the ways you need to isolate the GPL code just may not work for your product. If it can't work, it can't work. The authors who decide to put their software under the GPL do it for a reason and you have to respect that part of the bargain for access to their code.
How does this change the job of a developer?
You have to keep track of many things. You have to understand intellectual property issues. You have to understand corporate policy. You have to work with the corporate control (accounting) people. You have to work with the legal people to identify problems and work them out.
In closing
These issues are not just about open source software, but apply to many different licenses. Using the code of others is an important part of software development. Open source software products and reading the code of others is part of the software ecosystem and we get great benefit from it.
Dealing with intellectual property issues are part of being a software developer today, much like other things you have to deal with like usability, internationalization, source code control, or shipping to a schedule.
Posted by danb at 09:19 PM
This new blog
Welcome to the Software Garden Training Video Blog. I am producing a training video to be sold by Software Garden and I need a place to discuss it in detail as it is being developed. I decided that my normal, personal blog, Dan Bricklin's Log, was not the place for this, and the tools I'm currently using for that blog were not well suited to the task. Therefore I've started this new blog on the Software Garden website and am using Movable Type.
I have mixed feelings about discussing a product I have in development this way, but my experience with blogging is that it is more valuable to seek out and get feedback from others than hiding from potential competitors or scaring off purchasers with something premature or giving them "almost complete" stuff for free.
I've written about this project a bit on my personal blog. I've shown a 90-second demo excerpt to the audience at the Demo conference and gotten some feedback. I have a rough cut of the full video and have started receiving comments from a few alpha testers. Now it's time to go a little wider and get more feedback.
I think the topic of the video, an introduction to copyright law, open source, and the role of lawyers in development, is very important and timely. Too many developers are unaware of the details in these areas. My intended audience consists of corporate developers and my intended purchasers are corporate legal, training, and development groups. I am not aiming this material at independent programmers. I feel that I am an appropriate person to be on the video, given my background as an influential developer and having encountered many aspects of intellectual property law personally.
At this point in the development of the video I want to make sure that I cover the right topics and an appropriate range of viewpoints. Feel free to email comments to "blog" at softwaregarden.com.
Posted by danb at 05:54 PM