From: Jason Hammerschmidt email@example.com
Open Source Licensing, and the latest craze to go public (such as RedHat's IPO) sometimes have conflicting values. When public, you have to cater to your stock holders, this can easily conflict with the open source communities goals. Although you can build a business model around secondary and tertiary services such as support and manuals, etc. there will still be a conflict of interest at the center of it all. Most important, the philosophy and integrity of our community can be easily compromised and undermined by stock holders. The fact that our community has the same ability to acquire stock means little unless we own the majority of stock, and this is unlikely to happen. What, Bruce Perens, is your view on this subject? And how can we ensure the safety of our beliefs?
yes I know this is two questions :) and I also know this isn't a strictly licensing question, but it is very closely related.
You'll notice that a some of the companies that are already participating in free software development have been public-stock companies for a long time: IBM, and Apple, for example. Yet, these companies found a way to participate in Open Source. In IBM's case, it's making something of research-derived products it might not have been able to continue in development or market otherwise. In Apple's case, they're attempting to keep up with Linux - truly a daunting task - by being open too. Also, they are trying to return benefit they've already gotten from the community, and they might be able to open some secondary markets in the future from ports of their free software. You'll notice that when we had a problem with Apple's and IBM's original licenses, we used publicity to influence them. Public-stock companies are very sensitive to publicity because their stock price can go up or down depending on what people are saying about them. If their strategy is one that will prevent them from getting effective participation from the community, that won't help their bottom line and the market will notice.
There is no conflict of interest here - it's a quid-pro-quo. If the participation of the community is not important enough, the company will exit the free software arena.
Every for-profit company that participates in free software development will have to find a balance between its own needs and those of the community if it is to participate at all. I have a scale that I use to describe free software participants that runs from benefactor to symbiote to parisite. I'd put Red Hat in the symbiote position right now, NASA is a benefactor, and the parisites know who they are :-). Parisites eventually lose because the community is too eager to help out their competition.
To what extent have the various "free" and not-so-free licenses been evaluated by people with serious legal expertise? I hear charges against, e.g. the GPL that it won't stand up in court, that it's too vague, and other things of that ilk. Has the FSF ever had a crackerack patent (or whatever area of the law is involved) go over their license with a fine-toothed comb?
The GPL has actually had a good deal of evaluation. Richard Stallman has an MIT law professor who helps him, and there has been a law school thesis and some private analysis.There are definitely holes, but there's also evidence that it could be enforced. Ironicaly, the UCITA, a proposed U.S. "uniform state law" that poses us problems because places a ban on reverse-engineering, also has provisions that make the GPL and other free software licenses much eaiser to enforce.
One of the biggest problems with the GPL and all other free software licenses concerns the definition of a derived work. The definition of a derived work in copyright law is mostly concerned with print, film, and sound works, and was formulated before software came along. Thus, it doesn't say anything about how reference should be treated. For example, if you copy my function into your own program, it's a derived work. If you simply call my function without copying it, it's not a derived work according to U.S. copyright law, although you are having the exact same effect that you would if you'd copied the function. It's trivial to make any program a shared library or a callable object through object brokers like CORBA or COM, so you can easily circumvent license restrictions about derived works if you are considering copyright law alone. However, licenses are a combination of copyright law and contract law, and under contract law you can be restricted from performing certain activities that the software author might consider the creation of a derived work, activities that you would otherwise be permitted to do under copyright law. And of course, if you don't except the license, you have no right to use or copy the software at all. The problem is that the GPL doesn't really define what those activities are. That should change.
However, we don't generally have to go to court to enforce licenses, so they aren't getting tested for enforcibility in court, which is the only real test. Publicity is our primary enforcement tool, and it's surprising just how effective that has been so far.
I am soliciting attorneys to do pro bono work (donated work for the public good) to help address problems with licenses. There's a BOF about this at the LinuxWorld conference in August.
I recently started programming open source software for Windows (due to my unfamiliarity with Linux programming), and organized various OSS projects under the title of "Neon Goat Productions". However, I don't feel that I have a good grasp on the ideas behind some more advanced licensing techniques. First of all, if I release software under the GNU GPL, or other licenses, do I (as the sole owner of the copyright) have the option to change the license later on, either to another OSS license, or a closed source license? I don't intend on doing anything like this, but I definitely want to have the ability to control the future of my work. Also, if I release a project under the GPL, am I allowed to use portions of my GPL'd code in an independent, commercial program? I don't want to end up rewriting the same code for another job, just because the licenses aren't exactly the same. Finally, I am a bit unclear on releasing software under two licenses (for example, having the choice between either the GPL or the Artistic licenses). Since the Artistic license is less restrictive than the GPL, what would be the difference if the software was only released under the Artistic license instead of having an either/or clause?
If you are the copyright holder of a program, you may issue that program under any number of licenses simultaneously. While you can't take the GPL back once you release a GPL-ed version, there is nothing that compels you to release later versions under the GPL. But this is all ignoring the issue of other people's contributions to your program.
The situation is much more complicated when other people contribute. They own the copyright to their modifications.
You can deal with this in several ways if you want to keep the option to distribute your work under a different license:
1. Simply don't use their contributions in your commercial product.
2. Insist that they sign the copyright of the modifications over to you before you before you will put any of their modifications in your main source thread. This is what FSF does, so that they have the option to revise the GPL later on without having to go to everybody who made a modification and ask their permission.
3. Use a license like the Netscape Public License that gives you the right to distribute contributed modifications under other licenses. Note, however, that the NPL only requires that for modifications to your files, and that if somone creates a separate file and links it in, they are not required to give you the right to distribute that file under other licenses. Of course you can write your own license that says something different.
Regarding the Artistic license, I'd suggest that you do dual-license with the GPL if you choose to use the Artistic, becuase that makes it absolutely clear that your work can be united with other work that is already under the GPL to make one product. I also don't like the language of the Artistic license. I discuss why near the end of my article on the OSD.
from: Mike Moses" firstname.lastname@example.org
Would it be rude, inconsiderate, or copyleft infringing for a group of midnight coders to gather together collectively and form a company with a name like 'Open Source Consultants' or some other derivative with 'Open Source' in the name?
If you use the name Open Source in the title of an organization, that organization should use only software licenses that comply with the Open Source Definition, and not any "Open Source Definition", I mean the one that the Debian folks and I wrote and that we all know and love :-). I'd object to an "Open Source Magazine" that advertised non-Open-Source products, for example, simply because it would act to confuse people about what is Open Source and what isn't. That would be inconsiderate. It wouldn't be copyright-infringing because we're talking about a trademark, not a copyright. Also, the status of that trademark is rather iffy right now: it's still a trademark, but currently has no federal registration pending.
from: John L Grantham email@example.com
I note that the companies that you say deserve praise for their efforts, Apple and IBM, are both hardware companies that in effect happen to produce software. In both cases, they make far more money from their hardware than they do software, so in effect they have less to lose by giving an open source license a shot, but have much to gain in the form of increased sales of hardware.
But what about companies that are primarily in software? How do you see them making money off of open source, when that is after all their main motive--earning cash? In other words, why buy an open source package when you can download or copy it for free? Finally, are there any large "traditional" software companies (ones from before open source became a buzzword) that you see making commendable moves like IBM and Apple? Best regards, John a.k.a. Ethelred
Obviously, it's easy for companies that vend free software as an accessory to hardware to make money, because it's a lot easier to copy a disk than it is to copy a PC! Companies like VA Linux Systems come to mind.
If your business must primarily be software, not support, not anything else, you can't make everything free. This, for example, is the strategy of Sendmail Inc., which makes proprietary add-ons for the free sendmail mail delivery agent. Digital Creations, makers of the Zope web content management software, aren't quite a software pure-play: They give away their core software, and they sell services to customize that core to vertical markets for specific customers, newspapers for example. Some of that customization work may not make its way back into the free product. They have also announced some proprietary add-ons for Zope.
Yes, there is a large traditional software company making a commendable move. Unfortunately, I can't tell you who they are yet. It's not nice for me to pre-empt other people's announcements - I did that to Troll Tech once and they got (justifiably) very annoyed with me.
from: Bill Gladen
With all of the companies that are coming up with Open Source Definition compliant licenses, it is getting difficult to keep track of what the various licenses actually contain. Is there any work being done on a template license that companies could just post a delta of?; For instance, if you had an Open Source Base License O, which contained clauses A-N, then companies could just draft their license which stated "This license modifies O in the following ways: remove clause B, replace clause C with clause C', and add clause T."
I am certainly encouraging new entries to use one of the existing licenses rather than complicate the situation with another incompatible license. However, when the choice is having them make their own license or not release the software under an Open-Source-Definition-compliant license at all, I'd obviously rather see them release the software.
We are still in the learning period where companies are figuring out how to meet their own needs while participate in free software while meeting their own needs at the same time. This is sort of winding down now, and in a year or so we'll be able to get together and draft some standard licenses. I'd prefer not to have companies release deltas to a license, becuase that isn't much better than having them make their own licenses if the delta gets big. I'd just want some check-boxes for license options that would all be qualified under the Open Source Definition.
from: Corinna Cohn firstname.lastname@example.org
Amiga, Inc. has recently anounced that they will use Linux as the kernel for their new operating system. They have said that they will make heavy modifications to the kernel. As far as I know, this is the first highly adultered distribution of Linux. Can you explain, of the changes they will make, what parts of the source code must be released back into the community?
Unfortunately, I have not yet been contacted by Amiga, Inc., so I can't say for sure what they are doing. If they make modifications to the kernel in the form of modularized device drivers, they can probably keep those proprietary. I'd hate to see it, though. I'd prefer to see them contribute all of their modifications back to the community, and there is little reason for them not to, since they are selling hardware and their device drivers would probably not run on anything else. If they modify Linux in general, not just the device drivers, they are compelled to distribute the source for those modifications.
It would be silly for them to embrace Linux without the benefits of free software. That would be missing the point. I don't think they'd do anything that dumb.
from D. Dale Gulledge email@example.com
One of the hot issues in open source development in general right now is the issue of licensing an open source project in such a way as to maintain a profitable niche for the company that created the product. The issue is a hot one for me because a former boss of mine approached me for suggestions on how to handle a project as open source within a corporate environment.
As an example, Troll Tech attempted to deal with the controversy over the non-free status of Qt with their QPL. My own interpretation of their solution and that of other companies is that they make their work free for use in other open source projects but not for commercial use. Much of the controversy has arisen from where the boundary is drawn, since there are several companies selling distributions of and support for open source software. Neither those companies nor a significant portion of the open source community wants to see a license that would prohibit them from offering distribution and support services.
My question is, what is the best model for an open source license to be used for software produced within a corporate environment? The problem is twofold. First, the license must be acceptable to the open source community or it is a failure both as an open source project and as a component of a business case. Second, there must be a business case for it.
Dale Gulledge, Sr. Developer, Nortel Networks
Also, the author of the Emacs Calendar/Diary Desk Calendar formatting code, team leader for the Esperanto translation team for the Free Translation Project, and host of the Linux Users' Group of Rochester.
I know both sides of the issue, but I don't yet have the answer.
If I were doing it, I'd release my software under the GPL, and I'd also offer it under a commercial license. This part's a bit complicated: I'd insist that people who wanted their modifications to go into my main source thread must sign a separate and independent copyright for those modifications over to me, while they'd also maintain their own copyright. In other words, each party would own the modification and would have the right to do anything they wanted with that modification without consulting the other party. That way, I'd have the right to issue modifications under my commercial license, but I'd also commit to release all modifications that were submitted to me under the GPL. Becuase I'm using a split copyright rather than license terms to get the rights to the modifications, I'm not putting any odious terms on code that other people write. I'd continue to be an active maintainer and architect of the product so that people would want to submit their modifications to me.
In my opinion, this is the best of all worlds. The software is always available under the GPL. It's also available under a commercial license from which I can generate revenue. My original contribution continues to be a big enough part that it doesn't make sense for someone else to come out with a clone, but if I ever go out of business or lose interest in the program, someone else can make a commercial clone, writing out my contribution, and can get the modifications from their contributors under the same terms that I did. Until I do go out of business, there's not much reason for contributors to deal with anyone else.
Circumvention is an important principle in free software. I feel OK about Red Hat selling my software becuase I can always circumvent them and sell it myself. The circumvention provision here might make developers more willing to contribute to a commercial product.
Sorry if this is a bit deep. I'd be happy to discuss it in more detail.
What licensing issues apply to older software written by now-defunct companies? Is there a point at which such software enters the public domain?
Software eventually enters the public domain, but it takes so long that no computer that can execute it The situation with software from defunct companies is a sad one. Someone always owns it, because in the case of bankruptcy, there's always a creditor (generally more than one) who assumes the property of the bankrupt company. So, the situation is that your old license still applies but you probably can't get any service or upgrades or enforce your warranty, and you might not even be able to establish who owns the software without an expensive legal search. But you still can't give away copies of that software without infringing on someone's property rights, and that someone might come after you to enforce them.
Big customers have tried insisting that their vendors place the source code in escrow, so that the customer will have rights to that source code if the company goes out of business or declines to fulfill certain responsibilities like upgrades and warranty service. That works great if you wield enough power that your software vendor will negociate with you, for example if you are the only customer for a particular product or if you are paying a very large sum. It doesn't work for anyone else. It would be nice if there were laws about source-code escrow that protected the little guy. It would also be nice if the terms of copyrights didn't run so long and thus work did enter the public domain within one person's lifetime. Every 20 years, the international copyright convention meets and makes the copyright term 20 years longer. This is an abuse of the intent of the original copyright law, which was meant to exchange legal protection for your work for your releasing that work into the public domain eventually.
Hey, these were great questions! I enjoyed this, thanks!
Editor's note: Bruce Perens' latest venture is the Web site TECHNOCRAT.NET