Slashdot Log In
Interview: Bruce Perens Answers Open Source License Questions
from the very-abstruse-but-important-stuff dept.
-------------------------
From: Jason Hammerschmidt jasonh@cyberplex.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.
Jason,
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.
----------------------------
from adamc@email.unc.edu
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?
Adam,
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.
---------------------------
from parkerd@tegris.com
Hi Bruce,
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?
Sincerely,
David Parker
David,
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" moses@pobox.com
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?
Mike,
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 grantha@hannover.sgh-net.de
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
John,
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 gemini@indy.net
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?
Thank you,
Corinna Cohn
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 ddg@americasm01.nt.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.
Dale,
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.
------------------------------
from: Larry_Harkrider@radian.com
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!
Bruce Perens
Editor's note: Bruce Perens' latest venture is the Web site TECHNOCRAT.NET
derivative works (Score:4)
I agree I don't agree
Thank you for choosing I agree (I prefer direct deposit)... now continue...
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.
This has always been my qualm with the GPL. The restrictions on derivative works requires more legal power than copyright law alone provides. Enter contract law. Unfortunately contract law doesn't apply here. Reading the GPL doesn't mean you agree to the contract. Using the software doesn't mean you agree to the contract. As an example, clicking "I accept" when the Windows EULA window pops up isn't a legally binding contract.
Even if that fails and somehow the contract becomes legal, all you would need to do, at least in the United States, would be to get an under 18 year old person to modify the text of the GPL to whatever you wanted. It is illegal for a minor to enter into a legal contract.
Be wary folks. The GPL is on shaky ground in the 'derivative works' area.
This page [microtimes.com] explains the problem more clearly.
Look to Copyright statute (Score:3)
In a software license agreement, if a term like "derived work" is not defined, I would assume that most courts would assume that it meant the same as the copyright term-of-art "Derivative Work". That term is defined in 17 USC Section 101 as:
A "derivative work" is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a "derivative work".
Okay, clear as mud.
The problem is that with software it is difficult to draw the idea/expression dichotomy that is at the heart of copyright law. Copyright law protects the expression of an idea. If you take that expression and change it, you probably have a derivative work (i.e. translate it to another language, make a movie of it, etc.). If you take the ideas from a work, and incorporate them in another work, the result is not a derivative work (think Romeo and Juliet -> West Side Story [and yes, I realize that Romeo and Juliet is not copyrighted]). In cases where there are few ways of expressing an idea (how many ways can you write a while loop?), the idea and expression are said to be "merged", and that particular expression is not protected by copyright. In software, much of the source code (to my way of thinking) is likely covered by this merger doctrine.
I tend to think that translating C code to pseudo-code is a lot like extracting the idea from a particular expression. Creating new C code from the pseudo-code (if the pseudo-code is really just the "idea") should constitute a new, non-derivative work. It is a difficult call, though, because (simply) copyright law was not designed for software, and it's doctrines do not fit well.
Anyway, I am aware that I rambled, and I can see that I have strayed from the point at least a few times. But it is Friday afternoon, and I am too tired to go back and edit my work.
-Steve
(Too tired to think up a snappy sig-line)
Benefactor, symbiote and parasite (Score:3)
Calling Red Hat Software anything but a benefactor is wrong. They pay people to write GPL'd code, and they sell a very high-quality software distribution for cheaper than Microsoft Windows 98 (that is, if you even feel like paying for Red Hat Linux at all, since you don't have to). What more do you want?
They are as dedicated to free software as Debian, even if they don't actually have a social contract. They pour all kinds of resources back into the community. Bottom line: Red Hat is a benefactor.
Bruce, if you get this, please make clear why you rated RHS as merely a symbiote. Thanks.
Re:Benefactor, symbiote and parasite (Score:4)
I think he's talking about the type of relationship between a company and Linux, not the amount that a company (or organization) has benefitted Linux. NASA would still be NASA without linux. Therefore it is a benefactor. NASA probably benifits from it's involvement with Linux, but Linux does not define what NASA is.
Redhat puts more into Linux, but Redhat would not be Redhat as we know it without Linux. You could also probably say that Linux would not be Linux as we know it without Redhat. That's what 'symbiotic' means. I think Mr. Perens would be the last person to bash Redhat...unless he's jealous because more poeple have heard of 'Redhat software' than 'Bruce Perens'.
Copyleft, Copyright, and IP (Score:3)
That last question depressed me a bit, considering all the millions (billions even?) of lines of code that will be lost, as time marches on. This reminds me of the library book CmdrTaco had that was out of print yet still locked up in a copyright. The book was of great importance to his work, but photocopying it would have been illegal, and hogging it it would have been to the detriment of others in his community who might have needed it.
The loss of IP is a great travesty of modern humanity. Imagine the great works of this century's intellectual and technical minds. Once these materials are gone, forget it. However well-written legislation that can protect both profitable business and the consumer might be a solution. But it needs to be executed concurrently in N. America and the E.U., and thats almost a meta-physical impossibility
But I have hope, and I'm pulling out my stationary pad right now.
/usr/games/fortune -m lawyer|less
GPL 'virus' question. (Score:3)
GPL has been called 'virus-like' due to the fact that all 'derivitive works' must also be covered under the GPL. This fact has been pointed at as being one of the major 'evils' of the GPL. I have been told that, for instance, a device driver covered under the GPL, which is written for Linux, cannot be used in another kernel because it would 'infect' whatever kernel it is used in with the GPL. What do you guys think? Is this the way the GPL actually works? And if so, is it an unreasonable demand?
This is the answer I come up with:
A kernel that uses a GPLed device driver is not a derivitive work, because said kernel stands on it's own without that device driver. For instance, a kernel without support for a soundblaster awe-32 sound card is still a fully functional kernel...it just lacks that specific piece of functionality. Of course, the driver itself is still under the GPL, so the source code for the driver must be released, etc. But the rest of the kernal is independant of the driver. If I'm right, however, what about things like the code for Linux's SMP functionality? A kernel is still a kernel without SMP...So can the SMP code be imported without infecting the kernel? You could keep breaking pieces off of the linux kernel until the 'new' kernel you are creating is almost entirely Linux GPLed kernel...at some point it would become a derivitive work, yes? Or am I just confusing myself here?
Re:Benefactor, symbiote and parasite (Score:3)
When I write free software, I am doing it to expand the available pool of free software, not to subsidize someone's proprietary software. If I did not have the protection of the GPL, I'd simply not write free software. I have no wish to be someone's unpaid employee. The GPL protects me from that.
Thanks
Bruce
Re:Benefactor, symbiote and parasite (Score:3)
Re:Copyleft, Copyright, and IP (Score:3)