Slashdot Mirror
How Many Open Source Licenses Do You Need?
jammag writes "Bruce Perens, who wrote the original licensing rules for Open Source software in 1997, notes that there are a sprawling 73 open source licenses currently in existence. But he identifies an essential four — well, actually just two — that developers, companies, and individuals need. In essence, he cuts through the morass and shows developers, in particular, how to protect their work. (And yes, he favors GPL3 over GPL2.) For his own coding work, he's fond of the 'sharing with rules' license, which stays true to the Open Source ethos of shared code yet also enables him to get paid by companies who use it in their commercial products."
Hi Folks,
I happen to be at my desk again today, and can discuss this article, if any of you have questions or, more likely, comments :-)
If I write 30 responses, there will be a break. Slashdot locks me out for four hours after 30 postings from one IP.
Bruce
Bruce Perens.
Obviously you need a license that matches your values. If you think the same way as Stallman, who has communicated his principles in such places as the biography Free as in Freedom and the Free Software Song, you'll chose his license. If, on the other hand, matters of "hoarding" don't worry you at all, you'll chose another license. The quest for the one true open source license is an unreasonable expectation that human beings all think the same.
You are free to use your own license, containing whatever text you wish. The main limitations on you are 1) whether you can get anyone else to participate and 2) whether your license is effective in court. If your license requires me to sell my first born son into indenture, the court is not likely to uphold your license.
As you observe, standardization is desirable. One of the biggest goals of Open Source is to make more Open Source. You should be able to combine different Open Source programs into another new one, in a way the creators of the original pieces did not envision. To do this, the licenses must be compatible with each other. So, having everybody write their own is, in the long run, detrimental because all of those licenses will be incompatible with each other, or nobody will be able to understand if they are compatible or not.
So, I laid out one scenario in which lots of people and companies can use a minimal set of different Open Source licenses that fulfill the different purposes that people have for Open Source, and are compatible with each other. You are free to use that list, or ignore me.
Thanks
Bruce
Bruce Perens.
I would add, in addition to the the possibility of it being held up in court, would be the probability of success in court. If we can generate a substantial case history full of precedents dealing with the main licenses, it would ensure that newer cases that handled similar issues would be handled quicker and with more predictable results. That would ensure that companies take the licenses more seriously, and /or make any actual legal action quicker and less painful to everyone involved.
Well.. maybe. Or Maybe not. But Definitely not sort of.
This is why I wrote the DFSG / Open Source Definition. It provides a single name for a set of licenses that grant a particular set of privileges.
I did consider licenses that prohibit military use, and decided they were a bad idea, and the DFSG / Open Source Definition does not allow them. The license that was a bad example the time was the Berkeley SPICE license. This license was written during the period of South African Apartheid, and prohibited use of the SPICE circuit simulation software by the police of South Africa. 10 years after Apartheid was over, the license restriction was still in effect. Even though the police by that time were probably Black.
The other big prohibition to consider was Commercial Use. There were a number of "personal-use only" licenses at the time. I figured that licenses that prohibited commercial use made the software pretty useless and that it would not have effective collaboration to advance its development.
Licenses are important because they use rules to structure partnerships. We need to understand them, and how to use them. Yes, there are people who are very partisan. But just calling them zealots doesn't get at the reasons for their license, and whether those reasons make sense for you.
Bruce
Bruce Perens.
Has anybody ever proven this?
ie. has it ever been proven that attaching a 'must share' clause to a license (ie. GPL vs BSD) actually results in more people sharing code.
I am inclined to think and believe, based on experience, that it does not. Those who share are likely to share regardless of license, ditto to those who take your code and improve it with no intention of sharing.
Just how much does 'sharing' contribute to open source anyway, considering that all the top projects are tightly controlled by a small number of lead developers who hold the keys to commitments and in accepting patches. Code being shared will likely just go unnoticed anyway.
So, after 10 years, has anyone proven that the GPL works?
This is a problem. It seems that every attorney has their own fear, which they insist on writing into their own license that you must use.
But IMO the largest part of the problem is that few companies are effective at managing their own attorneys. Many technical managers feel that law is a black art and that they can only manage what they understand. Top managers with this problem tend to structure the company so that middle managers can't push back on Legal, and must do whatever Legal says. And thus, company attorneys generally get their way even on small points. A general counsel who sits on the board is even able to do this to the CEO, if the other board members aren't good at managing attorneys.
If it is imposed on the attorney that using an OSI-accepted license is important, the attorney can probably do a reality-check on their own fear. The fact that this doesn't happen is more an issue of management effectiveness than anything else.
Thanks
Bruce
Bruce Perens.
You only need one license.. The WTFPL
The Apache-style license is a gift because a company can use the work without any quid pro quo. Obviously, much Open Source is written as part of someone's employment, whether it is BSD or GPL licensed.
Dual licensing does give some special rights to one party. In general, this one party is the main contributor, and their business purpose doesn't work without dual licensing - because they won't have a revenue stream that supports their creation of the software. A license that does not fulfill that purpose is hardly more "business friendly" than one that does.
This is not a matter of philosophy, just business sense.
Bruce
Bruce Perens.
I agree that GFDL is a botch. I used the Open Content License (otherwise mostly unknown today) for my own books. My problem with Creative Content is that it's one name over a broad spectrum of incompatible licenses that have few rights in common other than the right to read the text at all. Can/can't distribute, can/can't do it commercially, can/can't modify, and so on.
Bruce Perens.
They're the rules for the Open Source Initiative and the Debian Project to approve licensing.
Richard wrote a statement of the Four Freedoms in an early edition of the GNUs Bulletin, which was mostly distributed in paper form on the MIT campus and environs. He did not further promote them until a long time later. So, when I had to write license guidelines for Debian, the Four Freedoms document was unknown. I sent my document to Richard, and he wrote back that he felt it was a good definition of Free Software. Surprisingly, he did not mention his Four Freedoms document in that correspondence.
Much later, FSF published its statement of the Four Freedoms on its web site as an alternative to the Open Source Definition.
Bruce
Bruce Perens.
Because "can share" / "must share" embodies the fundamental difference in Open Source licenses, and each makes business sense for a different set of purposes. In addition. GPL is applied to a very large number of Open Source projects, more than any other license, so the main compatibility issue is that a license be compatible with GPL.
Bruce Perens.
Both are copyrighted. One grants the right to modify, one does not.
Consider why it is not smart to modify your TCP/IP stack to be incompatible with the standard. You have the right to do so, but doing so will make it very difficult to communicate with others. And unfortunately engineers and tech companies are more likely to understand the consequences of modifying TCP than those of modifying a license. FSF doesn't prohibit you from using your own license text, they can't. They just decline to help you stick your foot in your mouth by modifying their text.
Bruce
Bruce Perens.
That's silly, lots of companies have failed that might still be here with a viable Open Source strategy.
Attorneys are concerned with avoiding liability for their company and having enforcible licenses. If you had an employee who went around all day with his hands on his buttocks due to some irrational fear, your choice would be to terminate him or send him for psychological help. Attorneys can be more paranoid than systems programmers, and sometimes a manager must temper this.
Bruce
Bruce Perens.
Bruce's article discusses license proliferation from the perspective of how-do-I; I'd like to confront those who use it to say why-should-I.
I used to work for a company whose lawyers argued that we must avoid Free Software because there were too many licenses to understand. Really.
Okay, so hundreds or thousands of Free Software products tend to use one of a few dozen licenses. We get that.
When you use proprietary software, every software product is governed by its own unique license. This is an improvement?
License proliferation is a totally bogus reason not to use Free Software.
Epilogue: My former employer has since seen the light. The legal team (whole executive team, actually) was sacked, and the company now uses and writes software under the GPL.