Draft (version 0.1)
"The general level of insight now is more
educated,
curiosity is wide awake, and judgments are made more quickly than formerly;
so the feet of them which shall carry thee out are already at the
door"
- Hegel
Well, I'll play a devil's advocate here. Richard Stallman's point has always been that software should be free. But GPL is not only about freedom, it's about envy as well ;-). I think that people deserve freedom, not only in a form of GPLed software :-).
I would like to stress that even though I find myself at odds with some of RMS political views (IMHO he can be considered as an influential left wing philosopher and there are parallels between GPL text and Marx manifest of Communist party ;-), I was and am impressed with his many contributions including GCC, GDB, Emacs and the GPL. But I am especially skeptical about his brand of software anarchism (sometimes called utopian socialism) with the slogans like "Software should not have owners", "Free software for all", "Signing a typical software license agreement means betraying your neighbor", etc.
Recently his views became somewhat more radical -- see Why you shouldn't use the Library GPL for your next library and, as it looks for me, far from being the best strategy for free/open source software movement as a whole. I understand that the left wing in the movement should exists and will always exist but we need to understand and analyze the views of this wing without rose glasses.
Developers working for commercial organizations and producing commercial software need and can support free/open software too, don't they? ;-). I would argue that as the most radical in the spectrum of open software licenses GPL is quite restrictive for the software author and adopting it is a mixed blessing. Dual licensing (GPL + Artistic like in Perl) or simple BSD licensing looks for me a more pro-people choices.
I would agree that pure GPL licensing is tactically useful in some special cases (including some business cases -- private business usually need a different license and theoretically developer can earn some money by releasing software under a different license for business use; in practice most GPLed programs can be easily reengineered to avoid this). But in some cases it discriminates directly against commercial developers. There are several problems with GPL that I see:
By denying copyright GPL does not recognize the author as an artist. Actually it subtly discriminates against the author.
GPL does not actually discourages incompatibility and reinventing the wheel by requiring people to make their source code freely available. Actually FSF contributed to the proliferation of unnecessary clones due to its fight for the ideological purity. The GPL permits compatibility. It does not encourage it.
But one of the most controversial properties of GPL is the
viral property of GPL 2. In essence if you the author of some useful
addition to the GPL program that was widely adopted and developed further you
are denied any subsequent modification, enhancement of you ideas in a case you
commercial developer. There are several consequences of viral property of GPL
v.2 (and IMHO this needs to be changed in v.3 which is not very
likely) ?
Collorary:
GPLed software might stagnate without the
feedback from commercial sector. In cases where GPL
discriminates against commercial sector that may lessen critical
mass of developers necessary for the development and maintaince of
software. Free/open source software still has costs. It takes time
to download, configure and build. For more or less large and complex
product its the quality of the software and the fact that new
features continue to be added that make it valuable, not its
openness per se. I believe this to be directly related to the fact
that someone (or many someone's) cares for it. And more often then
not this people can work for commercial company. Why restrict usage
of other tools for them ? Commercial developers involvement is
valuable also because of the dedication that commercial software
brings to the user interface field. They care about the UI and the
end user, because that's who they make their money from. If the
commercial vendors are unable to produce applications for the free
software platforms, then that is a substantial loss to the movement.
Here is a table that clarifies certain aspects of the current situation with free/open software licenses:
|
Software Type\License Feature |
Price for the user |
Restrictions on re- |
Restrictions on usage |
Restrictions on rights of the developers to combine it with other types of software |
Restrictions on source code of contibutors or co-developers (patches, new features, etc.) |
Restriction on reuse to the source code in other projects |
All derivatives must |
Restrictions |
Protection of interests of the original contributor |
| Commercial software |
5 |
5 |
5 |
5 | 5 | 5 |
n/a |
5 | 5 |
| Limited Trial Software |
4 |
5 |
5 |
5 |
5 |
5 |
n/a |
5 |
5 |
| Non-Commercial Use |
0 |
4 |
5 |
4 | 4 | 5 | n/a | 5 |
5 |
| Shareware |
2 |
3 |
4 |
4 | 4 | 5 | n/a | 5 | 4 |
|
0 |
2 |
3 |
1 | 4 | 5 | n/a | 5 | 3 | |
| Royalty-free libraries |
0 |
2 |
3 |
1 | 4 | 5 | n/a | 4 | 3 |
|
0 |
0 |
0 |
2 |
0 | 0 | 0 |
0 |
0 | |
|
0 |
? |
? |
0 |
0 |
? |
0 |
0 |
0 | |
|
0 |
2 |
2 |
4 |
4 (contamination) |
4 |
5 |
1 |
0 | |
|
0 |
? |
? |
? |
3 |
? |
5 |
2 |
2 |
The broad categories of licensing include:
You agree to provide the Original Contributor, at its request, with a copy of the complete Source Code version, Object Code version and related documentation for Modifications created or contributed to by You if used for any purpose. Original Contributor and/or other Contributors shall have unrestricted, nonexclusive, worldwide, perpetual, royalty-free rights, to use, reproduce, modify, display, perform, sublicense and distribute Your Modifications, and to grant third parties the right to do so, including without limitation as a part of or with the Licensed Software; and Original Contributor and/or other Contributors shall have the right to license or to otherwise transfer to third parties Your Modifications without notice, obligation or recourse to You. You grant to Original Contributor, Contributors and their respective licensees all rights and licenses (including patents) as are necessary to incorporate the Modifications created or contributed by You into the Licensed Software and to use, distribute or otherwise exploit such Licensed Software without payment or accounting to You.
Some people think that KDE's team refusal to change the license from GPL to
something else (like Artistic license) is their own problem, but I think that
this KDE issue is essentially an important test of GPL license itself. I means
it’s clear that in this particular case GPL restricts the right of the
authors. Especially in view of RMS
letter .
I think that this is a different problem than well-known "GPL virus"
problem. I would call it "subtle envy" problem (this is probably not
the best metaphor, although it catches an important side of this problem, but I
would also call it "my way or highway" property, a metaphor that
catches the other side of the problem).
If I understand correctly this "subtle envy/my way or highway" problem
is a fundamental issue of GPL being, well, limiting the freedom of the authors
(in this particular case KDE authors) to distribute their software, if it uses
other software that is licensed in a way different from GPL, but also free in
some important sense like for example "freeware libraries".
One can argue that this protects the users (in the hypothetical case authors of
freeware libraries change their mind), but my point here is that it protects
users at the expense of authors. And it can also harm users more that it
protects them, as harm is evident, but cases of switching the license for the
library are not. AFAIK there is no empirical data in support of this exclusion.
And the implicit promise of GPL to provide feedback from the users and attract
other developers that looks so attractive in theory, on practice is rather
difficult to materialize unless the project became really successful. But,
promise of feedback aside, as KDE example has shown GPL definitely restricts the
authors and this is not a bug, it’s a feature. As Guido van Rossum pointed out
in his paper Python
Licensing Issues:
In any case we don't want to use *just* the GPL for Python, because there are many proprietary software developers in the Python community who don't want to work with the GPL. Python has always had a BSD'ish license which was perfect for them. I see no reason to suddenly confront everyone in the Python world with the GPL.
For example, many authors of Windows programs that use GPL and some (even
freeware) library are in the same position as KDE developers. Formally GPLed
program cannot be compiled using proprietary libraries (other than standard
libraries like libc) and that probably applies to libraries in Microsoft
Visual Studio or Borland tools even if this company granted developers the right
to distribute libraries and runtimes, if any, free of charge.
That also means that when RMS says, "GPL is about freedom" we need to
understand that the meaning of freedom in GPL is qualified by this "my way
or highway" property and GPL is restricting the developers in the use of
development tools. Two other influential licenses (Artistic and BSD) seem to be
free of these problems, but GPL is the most widely used.
The more I think about GPL the more close to Anarchism it looks. I called this
"anarchism-friendliness" of GPL a "subtle envy"
because there is an important implicit message in GPL -- equality for users at
any cost (the author be damned) -- and, as we know from history the demand for
“absolute equality” means also the triumph for mediocre or the “triumph of
envy”, if you wish.
Nikolai Bezroukov
CNET.com - News - Investor - News - Story -- Allchin's controversy. Jim Allchin was probably the first influential software company official that openly linked GPL license with Anarchism and pointed out that like some other equality-based social schemes GPL might negatively influence innovation:
Jim Allchin, says that freely distributed software code such as rival Linux could stifle innovation and that legislators need to understand the threat.
The result will be the demise of both intellectual property rights and the incentive to spend on research and development, he said yesterday, after the company previewed its latest version of Windows. Microsoft has told U.S. lawmakers of its concern while discussing protection of intellectual property rights.
...''Open source is an intellectual-property destroyer,'' Allchin said. ''I can't imagine something that could be worse than this for the software business and the intellectual-property business.''
Microsoft clarifies exec's open-source concerns
Allchin's concerns, eWEEK was told, stem from GPL paragraph (2B), which states, "You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License."
In other words, Microsoft representatives warned, "anyone who adds or innovates under the GPL agrees to make the resulting code, in its entirety, available for all to use ... [which] might constrain innovating stemming from taxpayer-funded software development."
Allchin, according to the company, does not have the same concerns about all open-source approaches in general. "There are other kinds of open-source licenses that encourage third-party development but without the same constraints, including the BSD license," Microsoft representatives said.
See also:
A Response to Jim Allchin's Comments by Tim O'Reilly. Although pretty weak (he essentially avoided the key question "Is Anarchism un-American ?"; also he failed to distinguish between BSD License and GPL where BSD license IMHO more represents an academic part of the movement and GPL -- it's anarchist part) and apologetic (O'Reilly is the major beneficially of the open source movement -- the quality of O'Reilly book about important open source products are vastly superior to the quality of the documentation written by volunteers but he ignored this fact and praise CatB that claims quite an opposite ;-) it contains a couple important observations (in one linking FSF to a cult :-) :
To be sure, Richard Stallman is evangelical in attempting to convince others that free software is a moral issue, and not just a pragmatic choice, but he is hardly alone in asserting a forceful moral position about issues for which there is no wide cultural consensus.
...The greater part of Microsoft's revenue in the late 90's came from the incorporation of internet functionality (mostly developed on an open source model) into its products. The upgrade stream came not just from innovation inside Microsoft, but in large part from innovation by the very community Allchin now seems to portray as the "worst thing that could happen to the software business."
Linux Today - Richard Stallman Response to Dave Winer on Python Licensing
By Richard Stallman
David Winer is passionate in his disgust for me and my work; so much so that he does not limit himself to rebuking me for the things I have done. He feels entitled to imagine other things he would disapprove of, and attack me for them too.
In his column on September 8, he notes that he tells Guido van Rossum, "Don't give in to Stallman." From the context, it is clear Winer imagines that I am asking--or rather, demanding--that Python be released under the GPL and only the GPL.
As Guido can confirm, that is not the case. I have been pushing for the license of Python to be compatible with the GPL, so that it can be linked with GPL-covered programs as well as with other programs.
If the Python license is incompatible with the most popular free software license, that creates a major practical problem for the community. Given the importance of this problem, all my efforts in talking with the Python developers have been aimed at solving it, at trying to propose some solution that they will accept. This isn't easy, and I am not going to make it harder by asking them for something else in addition.
Winer's description of my goals is equally inaccurate. I am not opposed to commercial software. When companies contribute to the Free World by developing free commercial software, I say more power to them. I started a free software business myself in 1985, selling tapes of GNU Emacs; I dropped it when the FSF took over selling these tapes.
What I disapprove of is non-free software--never mind whether it is commercial or noncommercial. But even I sometimes choose a license that permits a library to be used in non-free software (see http://www.gnu.org/philosophy/why-not-lgpl.html).
The idea of the GNU GPL is to establish certain liberties for everyone, and defend them as much as possible from anything that might take them away. We believe in two-way cooperation, and we invite everyone to join, but we do not invite people to exploit us by putting our code into non-free programs.
One thing in Winer's article is accurate: my philosophy is NOT open source. I have been standing firm for the philosophy of the Free Software Movement since 1984. The Open Source Movement, founded in 1998, has a less firm stand. I am not going to join them; I am going to keep standing firm.
But although I do not agree with or speak for the Open Source Movement, I have seen what they say, and I know that Winer misrepresents them when he invokes their name for his opposition to copyleft.
I believe that software users are entitled to certain liberties, to share and change software. I wrote the GNU GPL to defend those liberties. But there are some kinds of liberty I do not agree with. Taking liberty with the truth is not a good thing.
Copyright 2000 Richard Stallman
Verbatim copying and distribution of this entire article are permitted in any medium, provided the copyright notice and this notice are preserved.
Stallman on Qt, the GPL, KDE, and GNOME
Making Qt available under the GPL makes it legal to take an existing GPL-covered program and adapt it to work with Qt. It also provides a way to resolve one of the free software community's long-standing problems, the problem of the ethical and legal status of KDE.
The design of KDE was based on a fundamental mistake: use of the Qt library, which at the time was non-free software. Despite the good intentions of the KDE developers, and despite the fact that the code of KDE itself was free software, KDE could never be part of a completely free operating system as long as it needed a non-free program to function.
But the KDE developers were not concerned about this problem, and recruited helpers who shared their views. As KDE/Qt developed, it posed a growing risk to the progress of free software. The risk was that KDE/Qt would become so established that most of the user community would treat it as indispensable--disregarding the fact that this meant using non-free software. Widespread acceptance of one crucial non-free program would encourage a general willingness to accept non-free software, meaning fewer people who might have the will to help replace KDE/Qt with something entirely free. And that job would require catching up with a large head start, just as we did in replacing Unix with GNU and GNU/Linux. To be back in that situation was a discouraging prospect.
But we were not there yet, and it was clear we should take preventive measures before we got there. In 1997 we launched two parallel projects designed to avoid that situation: the GNU desktop (GNOME), which aimed to provide a completely different alternative graphical interface, and Harmony, a free replacement for Qt. The reason for starting two projects in parallel was redundancy: any project may fail, and the risk was big enough to warrant two simultaneous approaches to preventing it.
GNOME caught on, and by 1999 it was a clear success. Then Qt was rereleased under a new license, the QPL, which made it free software. This solved the principal problem of KDE/Qt, the fact that part of it was non-free. But a secondary problem remained: the problem of license inconsistency.
The QPL is incompatible with the GPL, which means that Qt and GPL-covered modules cannot legally be combined, unless the developers of one module or the other grant an exception to permit it. The KDE developers certainly intend their GPL-covered code to be used with Qt, and one can argue that by telling you to link it with Qt they have implicitly given you permission to do that. But they did not formally state this exception in the KDE source code itself, and it is not comfortable to rely on implicit permission for something like this.
In addition, in some cases code was copied into KDE from existing GPL-covered modules whose copyright holders had not given special permission. (Only the copyright holders can give extra permission to do things that the GPL does not permit.) That is a real violation of the GPL. Because of this, and the overall lack of an explicit exception, the legal status of KDE remained clouded.
Qt 2.2 provides the basis to solve this secondary problem, but a certain amount of cleaning up will be needed to fix it thoroughly. Misusing a GPL-covered program permanently forfeits the right to distribute the code at all. Such situations have occurred in KDE, and now they ought to be cleaned up.
It would be a good idea for all of the authors of code in KDE (more precisely, all of the copyright holders) to make a clear statement that linking their code with Qt in the past was done with their permission, thus assuring existing KDE users that they have not forfeited distribution rights to that KDE code.
Also, where code was copied from other GPL-covered programs, their copyright holders need to be asked for forgiveness. To lead the way, the FSF hereby grants this forgiveness for all code that is copyright FSF. More precisely, those who as of September 4, 2000 have used some FSF code in violation of the GPL solely by linking it with Qt, and thus have forfeited the right to use that code under the GPL, will once again have full GPL permissions to use that code upon switching to a GPL-covered version of Qt. I appeal to all the other copyright holders of affected code to grant similar forgiveness and thus help resolve the situation quickly.
Soon KDE should be properly based on a GPL-covered version of Qt, and the Free Software Movement will be able to think of KDE/Qt as a contribution and not as a problem. Meanwhile, I think there is no reason to work on another package which is equivalent to Qt. If you want something like Qt, use Qt.
But GNOME is here, and is not going to disappear. GNOME and KDE will remain two rival desktops, unless some day they can be merged in some way. Until then, the GNU Project is going to support its own team vigorously. Go get 'em, gnomes!
Guido van Rossum Responds to Python Licensing Issues Open Source,Community,Software Sep 7th, 2000
In any case we don't want to use *just* the GPL for Python, because there are many proprietary software developers in the Python community who don't want to work with the GPL. Python has always had a BSD'ish license which was perfect for them. I see no reason to suddenly confront everyone in the Python world with the GPL.
LinuxPlanet - Judgment Day for the GPL - Determining the Legality of the GPL
This summer could be a lot hotter than usual--not because of global warming, which may or may not be taking place, but because of a lawsuit which may or may not be taking place.
Before summer's end, a long-awaited court test of the GNU General Public License may be filed, says Eben Moglen, professor at the Columbia University Law School and general counsel to the Free Software Foundation.
"If you wait another couple of months I wouldn't be surprised if you see either a lawsuit or a voluntary agreement to comply entered into by a major international software house that has done exactly what you postulate, less in the 'embrace and extend' model than in the 'security through obscurity' model, which is another reason why those who build works on top of free software sometimes try not to disclose source," Moglen told me in an e-mail exchange dealing with the basic nature of the GPL, the licensing instrument of much if not most Linux-related software. (I had asked him whether it would be possible for a commercial software firm to envelop GPLed code, alter it, and sell it, sans source code, and whether it would be possible to obtain judicial relief under such circumstances.)
Moglen would not reveal the details of the potential lawsuit, nor would he name the company involved, noting that if he did he would reduce the likelihood that court could be avoided.
... ... ...
This won't necessarily happen in the first case, right out of the box. This has to do with the nature of the case itself--again, the FSF is smart enough to choose a test case that it is likely to win--and other factors that cannot be predicted at all. Because it will probably result in new law, random factors such as the judge assigned to the case, his or her mood and opinion of the lawyers involved, and competence of his or her law clerk are huge and unpredictable variables.
"It's going to be interesting" one lawyer told me. "It's just a different paradigm entirely."
(Moglen's manifesto, "Anarchism Triumphant: Free Software and the Death of the Copyright," can be found at http://emoglen.law.columbia.edu/my_pubs/anarchism.html. In it, he argues for the elimination of intellectual property rights. It is a very interesting read, just as it is useful for the reader to contemplate whether the elimination of intellectual property rights is necessarily a good thing.)
Q: (from Bruce Perens) - I'm concerned that GPL restrictions on derived works haven't kept up with software technology.
RMS: I am working on GPL version 3, but this is not something that should be rushed. I put it aside for most of a year to work on the GNU Free Documentation License, but now I plan to get back to it.
Bruce: The most pernicious example is CORBA, which lets us create derived works from components that aren't in the same address space at all, yet work seamlessly as if they were. I'd rather not see my GPL work end up in somebody's proprietary program, simply because it's been server-ized to avoid my license restrictions.
RMS: If people can write non-free software that makes use of free CORBA components, that is bad in one way: it means that their non-free software can build on our work. But using our free software through CORBA does not make our programs themselves non-free. So it is not as bad as extending our programs with their non-free code.
I think it will be hard to claim that a program is covered by our licenses because it uses CORBA to communicate with our code. Perhaps in cases of particularly intimate coupling we could convince a court of that view, but in general I think we could not.
Bruce: A more common problem is dynamic libraries that are distributed separately from the executable. You say that a court would hold those to be devices explicitly used to circumvent the license restrictions, but that's rather chancy, and no substitute for explicit language regarding what is, and what isn't, considered a derived work in the GPL.
RMS: We have no say in what is considered a derivative work. That is a matter of copyright law, decided by courts. When copyright law holds that a certain thing is not a derivative of our work, then our license for that work does not apply to it. Whatever our licenses say, they are operative only for works that are derivative of our code.
A license can say that we will treat a certain kind of work as if it were not derivative, even if the courts think it is. The Lesser GPL does this in certain cases, in effect declining to use some of the power that the courts would give us. But we cannot tell the courts to treat a certain kind of work as if it were derivative, if the courts think it is not.
I think we have a pretty good argument that nontrivial dynamic linking creates a combined (i.e. derivative) work. I have an idea for how to change the GPL to make it clearer and more certain, but I need to see if we can work out the details in a way that our lawyer believes will really work.
Bruce: There's also the problem of Application Service Providers, who make a work available for people to use without distributing it, and thus would be under no obligation to make the source code of their modifications available. Do I have to see my GPL work abused that way as well?
RMS: I too feel these servers are not playing fair with our community, but this problem is very hard to solve. It is hard for a copyright-based license to make a requirement for these servers that will really stick. The difficulty is that they servers are not distributing the program, just running it. So it is hard to make any conditions under copyright that affect what they can do.
I had an idea recently for an indirect method that might perhaps work. I'd rather not talk about it until our lawyer figures out better whether it can really do the job.
Bruce: It seems there's a lot of new technology that the GPL isn't keeping up with.
RMS: You make it sound as if solving these problems were only a matter working hard enough to change the GPL. But the GPL can only use copyright law as it exists. The recent changes in US copyright law to "keep up" with technology, in the DMCA, were commanded by the software privateers, and they were designed to help them restrict away the users' freedom, not to help us protect users' freedom. They allow copyright owners to restrict the mere running of a program--but only if some sort of hard-to-bypass license manager or access control enforces the restrictions. The freedom of free software means that even if we did put such artificial restriction into a program, the user could easily bypass them--and that's a good thing! But it means that new legal power is not available for use for copyleft.
The DMCA is a perfect example of the harm done when business dominates government and society. One part of the law explicitly says that only commercially significant activities are considered important (to legitimize a program which is often used to bypass technological means of controlling the users)--showing explicit prejudice against educational uses, recreational uses, communitarian uses, military uses, and religious uses.
Q: What kind of a position do you take on applications such as Napster?
RMS: Napster is bad because it is proprietary software, but I see nothing unethical in the job it does. Why shouldn't you send a copy of some music to a friend? I don't play music from files on my computer, but I've occasionally made tapes of records and given them to my friends.
Q: In particular, I see GTK Napster carries a standard GPL. I'd just like to know what happens when someone like Metallica wins a lawsuit against Napster who has a GPL'd counterpart such as GTK Napster? Can they touch it at all?
RMS: I don't know who will win those lawsuits, but I don't see anything that would give free programs any special protection from this kind of suppression. It seems to me that if they win against Napster, they would probably win against any program doing a similar job.
If they do not win using present-day law, we can expect to see the record companies purchase new laws they can use to suppress these programs in the future--and trot out famous musicians like Metallica (only famous musicians get much of their income from copyright) who will say that copying music is like killing their baby.
We can also expect to see fierce attempts to catch individuals who use Napster and imprison them. The War on Copying will become more vicious.
The War on Drugs has continued for some 20 years, and we see little prospect of peace, despite the fact that it has totally failed and given the US an imprisonment rate almost equal to Russia. I fear that the War on Copying could go on for decades as well. To end it, we will need to rethink the copyright system, based on the Constitution's view that it is meant to benefit the public, not the copyright owners. Today, one of the benefits the public wants is the use of computers to share copies.
Metallica justifies their lawsuit saying they think it is an outrage that their music has become a "commodity". Apparently they think music is a commodity when shared between fans, but not when large companies sell copies through record stores. What hypocritical absurdity!
Such drivel is normally laughable. But Metallica is presenting it as an excuse to attack our freedom, and that is no laughing matter. I encourage people to write letters to periodicals that cover this story, stating disgust for Metallica's lawsuit and rejecting their views.
Q: The battle over CSS has been about whether people have the right to use software (I consider DVDs software because they are programs read by a computer chip) when it is controlled by the content control system CSS, even after they've bought it. I hope they'll lose in the courts, but it is unclear at this point whether they will, however, my question is on another, related topic.
Suppose very strong, nearly unbreakable encryption were used on traditional Software DVD (i.e. stuff like M$ software or other companies software, just in a DVD format) and a DVD CCA for software were set up saying, "You aren't allowed to access the content of any DVDs unless you use our licensed DVD decryption software. Oh, and our DVD decryption software contains a legally enforceable (under UCITA) software license which states that you cannot reverse engineer any content you have decrypted using our decryption software." How would Free Software handle it?
RMS: With laws like that, there would be no lawful way to solve the problem. The Digital Millenium Copyright Act comes close to what you imagine, and it may be enough to prohibit free software for this job. (I don't know for certain, and I think the answer is not known yet.) It may be necessary to develop this software in countries which do not have these laws.
Q: Does there now need to be a Free Hardware philosophy which states that "Hardware which exists tied to a proprietary software system must be replaced by Free Hardware standards" or something similar?
RMS: I agree--but it will be hard to get the movie companies to release movies for that hardware. Fundamentally, the only solution will be when enough of the public believes in freedom to change the laws that are the basis for denying our freedom.
Q: I've been reading your opinions for some time now, and while they make sense in and of themselves, they beg certain other questions. What interest me most are your meta-ethical notions.
You often speak of notions such as right and wrong as if they were objective things; do you hold them to be so?
RMS: I think of right and wrong as based on how what we could do affects other people--the implications of imagining ourselves in the situation of the people our actions affect.
People can come to different conclusions about the implications. I don't believe in relativism; I don't believe that any conclusion is as valid as any other. If I and someone else disagree, at least one of us is wrong. Unfortunately, there's no way to place to get complete certainty about what's right and what's wrong. We can only try our best to figure it out.
The generalizations that we get from our consciences are our values. Our specific conclusions about ethics derive from these values; arguments about ethics depart from them. So my arguments about free software, or anything else, start from the values I believe in. They are addressed to people who at least partly share these values. When people persistently reject these values, there is nothing I can say to them. But sometimes people will start to share my values when I point out to them the situations the values are based on. They may then imagine the same feelings I felt or imagined.
Q: Are there "natural" rights, and what is the nature of their existence?
RMS: I think there are natural rights, natural in the sense that people are entitled to them regardless of what governments say about them. Freedom of speech is a good example; I think people are entitled to freedom of speech, and censorship is wrong. That is one example that I think most people reading this would agree with. I also believe that the freedom to share software and other published information is also a natural right.
There are also artificial rights, rights that are not natural. I agree with the US legal system, for example, in the view that copyright is an artificial right, not a natural one. It can be reasonable to have a limited kind of copyright system for some kinds of works, but this is a concession made to benefit the public, not an entitlement of authors and publishers. This system should be limited so that it doesn't seriously conflict with other people's natural rights.
[Jan. 6, 2000] THE BASTARD PUBLIC LICENSE
[Dec. 30, 1999] Slashdot Articles YABGC Yet Another BSD GPL Comparison
| Is BSD more free than GPL (Score:4, Insightful) by Rupert on Saturday January 01, @10:26AM EST (#13) (User Info) |
| Depends on your perspective. From the point of view of someone who is not the original author (or the copyright holder, if they are not the same) then BSD is more free. You can do what you want with the code. But for the author/copyright holder, GPL has an advantage that noone can take your code and improve it without the changes being available to you. If I were releasing code under a free licence, I would choose the GPL. If I were using someone elses code to incorporate into a commercial product, I'd prefer it be under the BSDL. |
[Dec. 11, 1999] Slashdot Ask Slashdot What about the Artistic License
| GPL and forking (Score:4, Insightful) by Dr. Sp0ng (spong@SPAM.glue.SUCKS.umd.edu) on Thursday December 09, @09:30AM EST (#10) (User Info) http://www.wam.umd.edu/~spong/ |
| The GPL allows forking, but it also implicitly prevents it, because any forks must also be released under the GPL. If the new features in the forked version are better than the original, there's nothing preventing the author of the original version from stealing those changes an integrating them back into his version. Meanwhile, he's been doing development, so now he has his changes PLUS the other guy's changes, and he comes out on top. To answer your other question about being able to create a commercial, closed source version of the authors need to pay the bills: the GPL allows this as well (as does any other license) The original author of the program retains the copyright to the code and can re-release it at any time under any license he wants. What the GPL prevents is OTHER people stealing GPL'ed code and selling it as a commercial, closed source program. (this doesn't, however, prevent other people from selling it as a commercial, Open Source product) |
GPL and BSD explication and comparison
Martin Cracauer's GPL Page -- interesting critique of GPL that contrasts it to LGPL.
| Abstract: | The GNU General Public
License (GPL), used by many popular free software packages, contains
some requirements that makes it hard to use in the real world.
Most importantly, its clause that program modules under the GPL must not be linked with modules under licenses that add any term the GPL does not have, prevent many good software packages from being combined. There is an alternative license - the LGPL - that has all the power to protect people's own work, but without the extended requirements that serve no other purpose than to force your will on someone else and his work. |
|---|---|
| Intended audience: | People who advocate free software, people who need to choose a license for their free software package, people who want to understand some of the political issues that handicap development of free software. |
| Required knowledge: | You must understand why authors of free software differ in their opinions what to allow others to do with the software they released to the public. |
Slashdot: GPL vs BSD discussion
Interesting comment:
...Yes, it can be incorporated into proprietary products. It can also be incorporated into other free software products (including GPL'd stuff). I prefer 2-clause BSDL (as used in FreeBSD and elsewhere) or the X license not because I want to give proprietary software vendors the freedom to use my code (although I don't care if they do; fine by me). Rather, I prefer such licenses because they don't discriminate against other free software licenses. GPL'd code does not coexist with other licenses, period. If you use GPL'd code, your own code must also be GPL'd. If someone wanted to use GPL'd code in some project using some perfectly acceptable DFSG-compliant license (such as Artistic), they couldn't do that. They would have to GPL their own code. The benefit of shutting out potential use of my code in proprietary software is far outweighed by the sheer irritation of shutting out the rest of the free software community. I prefer very lenient, non-GPL licenses because I want my code to be as useful to as many people as possible, and I want a minimum of legalese, and I consider myself to be a programmer rather than some political activist/extremist on an anti-IP crusade.
Another interesting comment:
Re:The flip side by Anonymous Coward Wednesday June 23, @11:17AM EDT Free speech not free beer you dolt! (Score:1) by cynicthe on Wednesday June 23, @11:21AM EDT (#102) (User Info) The FSF sells their CD's for quite a bit of money, take a look. They're not starving! And they're probably pretty comfortable. Granted they would rather spend $1000 on a good amplifier, mixer, and axe than a damn Rolex! Read: http://www.gnu.org/order/order.html I should then demand the freedom to lock someone up. All I'd have to do to get a bunch of idiot emotionalists on my side is tell them some bullshit fairytale of a battle that was won when the opposition was locked up. When people work 40 hrs a week, feed 3 children, pay $100's in bills, they tend to forget history and you'll be able to tell them anything. I understand the BSD license, and I know they're doing the same thing GPL'ers. It's just that they depend purely on vague values, ignore the legal and patent minefield were actually living in, and they never consider the principles and conditions that allow the freedoms they're fighting for to exist in the first place. Beyond that they're ok people. Then there's the BSD pundits (there's a few just like our GPL pundits which are worse than Stallman, Raymond, and Perens all together could ever be on a bad day) you know the wanna-be philosophers who give both their fellow BSDers and GPLers a bad name. They're the only ones accusing GPL'ers of Communism. I've seen some pretty calm posts from real BSDers. Here's a message to the wannabe's: Communism was a theory called Karl Marx's Marxist Socialism. First, that never happened! Second, he was completely wrong! He rejected rationalism (get this) because people around him were not behaving rationally, so he said reason doesn't exist. What did happen was the Communists took the powers of production from the rest of the people.Guess what? Historical Communism as I've just defined it is precisely what "capitalism" is today. Gates is a bastard commie. Capitalism did exist in its intended form back when people worked their asses off to get an invention produced. These days American capitalism is just like the earlier Russian capitalism. They beat us at the capitalist race too. They had a harder time holding on to true healthy capitalism because they tried to sklp the industrial revolution. They ended up with technology that the mass populace was unable conceive practical uses for. When America's industrial revolution took place most people knew about it. What we call capitalism is a load of shit marketting, scamming, spamming, and perpetual litigation. None of that is hard to do if you have the stomach for all the doublethink it involves. Software is not hardware. It may take time. There's code to write. And sure it takes to compile and debug (do proprietary companies still do that?). But realise this you're comparing a state-of-the-art pail to carry water in to the well. Sure it takes time to build a machine to carry water to your customers. The does not mean you can stop someone from taking their own time and going to get the water themselves. Proprietary companies do this with bullshit NDA's. There is little water without the the pipes and machinery getting it from the well. There is no software without the PC. Where would you be had IBM won its suit against Pheonix over blackbox blind-engineering their BIOS. The IBM would come in fruity colors by now. There is no market for water is people have to pay extreme prices to get water and aren't allowed to get information to get it themselves. The market lies dormant limited to pure survival purposes. There is no market for software if the means of production (information, gcc, libraries, source) are taken away. The market lies dormant as purely Visual Basic interface design. No kernel, no document and information management, no personal video editing, no open gaming development. (TRY UNREAL! Four years open development!) But right now the biggest problem is the legal patent minefield. Seriously this is the proof of the GPL: > >>Unlikely. Judging by the window 2000 beta traces they run a BSD stack derivative > >>close to freebsd - and the BSD license permits such use > > > >Which is a good reason to *NOT* release open source code under > >BSD style licenses. You might as well just send your code > >directly to Microsoft. > > And the problem with Microsoft using all sorts of Unix code is...? is that they would never admit it, _and_ they would continue badmouthing Unix/Linux/BSD. They simply can take advantage of BSD code whenever they see fit - without acknowledging it and without giving back anything. It's unethical and abusive, and this is what the GPL prevents. It also drains developers from the BSD space (after all they could now just go and develop networking code for Microsoft), which is bad for the BSD project as a collective effort. These are just a few of the many naivities the BSD license has, and Microsoft Halloween documents pretty accurately point this out. They are afraid of Linux, but they are not afraid of *BSD. --"World gone crazy, cuz it can't say no." - Bruce Dickinson 1000 Points of Light.
Similar argumentaion:
Most of the comments are very abstract. How about some real life examples? For me, I rail against the BSD license every day, for two reasons: 1) My place of work uses a variety of tools which run on various Unices, including BSD, but NOT the free varieties. If I want to run BSD I *have* to use a proprietary version. This is only possible because of the BSD license. GPL would not allow the proprietary fork. Proprietary BSD's have marginalized the free BSD's, which is possible because of a poor choice of license. Linux distributions are not "forks", because *any* Linux product will run on my linux box. At most I might have to install a different libc, or something, to get it to work. I don't have to buy a proprietary Linux. 2) A company I've worked for is basically making widget frosting -- code to run with its hardware. Where did the code base come from? BSD. This company has *no* investment in this code. They want to sell widgets. If it were free code they'd still sell widgets. It won't be free code because the BSD license was sitting there, allowing them to walk off with it. BSD had a valuable code base, which could have been extended. Instead it has been swallowed, because the license allows this waffling. This happens all the time: BSD is undercutting the development of free code.
**** Reverse-engineering the GNU Public Virus -- a paper by Stig Hackvän with some interesting points... He's writing a book on Open Source Licensing
GPL = consumer protection + anti-copyright + anti/Law
I draw a rough distinction between the GPL's mandate to share unobfuscated source code and its anti-copyright properties.Wooing all source code out into the open is an important consumer-protection measure. Tying the source to compiled binaries is good for both the stability of the software and the sanity of developers who rely upon it. It's also good for users tired of being used as sacrificial pawns in the ceaseless battles over platform dominance.
The anti-copyright component of the GPL is perhaps somewhat misguided, but some copyright reform is clearly necessary. Viral infection through contract law between developers is a good way to work out a better consensus on the proper limitations of intellectual property. Copyright terms are way too long for software, and "fair use" provisions have been eroding over time, but dealing a fatal blow to the author's copyright seems unwise. By wholly subscribing to the copyleft worldview, one loses the freedom to hack on copylefted software and later pay off one's bills by charging many users for small fractions of the value of the resulting work.
anti/Law is the contractually
reinforced worldview of one community
locally overriding the statutory worldview
of another one. It's a poetic construct
as much as a legal one.
Although GPL gives me pause, the way in which it undermines the very law from which it draws its power is definitely its most fascinating quality. The GPL is an agreement among peers to collectively disregard state law. I call this property of the license anti/Law.
anti/Law is the contractually reinforced worldview of one community locally overriding the statutory worldview of another one. It's a poetic construct as much as a legal one.
Some intellectual property lawyers question whether the GPL can be enforced, and that issue has never been tested in the courts. But the GPL's expectation is that even the tiniest bit of GPLd source code, combined with your own, can infect your program with the GPL's redistribution terms. And so using the GPL becomes a kind of viral licensing.
The size of the sneeze
A Sufi proverb pretty much sums up the effect of free software's self-dubbed Chief GNUsiance: "Look at the grain of pepper -- and at the size of the sneeze."While mistrust of Microsoft's greed (and dissatisfaction with its software) is largely responsible for the commercial success of Linux, the attraction to copyleft's subversive mystique (and all that cool source code) drives the popular success of Linux. The emotionally charged promise of copyleft is that artificial barriers to creativity can be eliminated and that information might freely flow to wherever it's needed.
If the Linux Slogans Web page is any indication, then GNU's influence has meant a great deal more than dissatisfaction with Microsoft. The first-place pro-GNU slogan ("Linux: The choice of a GNU generation") beat out the second-place and equally catchy anti-Microsoft slogan "Linux: The Ultimate NT Service Pack" by more than a 2-to-1 margin.
Stallman's unrelenting idealism, narrowly focused on the realms of software self-determination and copyright reform, is deeply affecting the ethical development of an entire generation of hackers. Without question, the current crop of software unprofessionals graduating into the "real world" is a GNU generation, and I think that's a pretty good thing.
Publishing the source code of a flagship software product (such as Mozilla or Java) was unthinkable 15 years ago, but today source code is becoming a prerequisite for operating systems, developer tools, and some classes of applications.
But while many of the ideals of the GNU project are increasingly appreciated, they're not always considered practical. Even within the free-software community, FSF's rigid ideology fuels dissent and its controlling tendencies are regarded with distrust. (See a companion piece to this article, "Radical software environmentalism," for a look at some common compromises.)
Daemon News 199905 Restrictively Unrestrictive The GPL License in Software Development
My Opinions
It is my opinion that the General Public License is not so much about ``keeping free software free'' as it is about forcing us to accept the extreme Communistic political philosophy of Richard Stallman and others at the Free Software Foundation. The very spirit of the GPL is to attack the very concept of Capitalism and individualism. There is no concept of intellectual property under the terms of the GPL. Your hard work is no more your property than everyone else's.I found myself compelled to write this article because of the over- abundance of GPL'ed software that is flooding the open-source software community. Most of this flood of GPL-ism is because of the increasing popularity of the Linux operating system, most of which is GPL'ed. Indeed, Richard Stallman himself would prefer that we recognize the Linux operating system as ``GNU/Linux'' instead, because of the fact that almost all of the code is GPL'ed. The Linux kernel itself is not a GNU/FSF product, however.
The BSD license suffers from a rather unfortunate name, which has caused it to be less recognized. Due to the popularity of Linux (and the vast assortment of nuts and fanatics who defend it to the death), the BSD license is assumed to have nothing to do with Linux whatsoever. This is not true at all. The BSD license can be applied to the same material as the GPL. Of course, since most of the body of code in the ``GNU/Linux'' system is GPL'ed, there is no hope of ever changing the licensing - they've gone too far to turn back now.
So given all the arguments I've presented here, I hope you can see where I'm coming from. The GPL is not about freedom. It's also not without its advantages. But the fact that the GPL can infect code derived from other GPL'ed programs, as well as the fact that the output of some GPL'ed programs must also be GPL'ed, is unacceptable. In fact, it should be contested over its shaky sense of legality in these matters. I'm not aware of any court cases involving the GPL so far, so we have yet to see what will happen when such an issue arises. I can only hope that the courts will decide against the GPL's habit of infecting other code.
In summary, despite the disadvantages in certain instances, most open source software licenses contribute to the growth and technological and artistic development of software and computer science in general. Both licenses that have been considered here fall under this category, and as such should be considered a valuable resource and a great achievement for the intellectual development of the scientific and technological communities as a whole. Open source software is all about the sharing of ideas and concepts. Programming is as much an art as a science, and it is not wrong to borrow from the ideas of others and to learn from those who have gone before us.
Andi Gutmans and Zeev Suraski: LG interview :
LM: What were the motives behind changing the license between PHP 3 and PHP 4?
Suraski: There were several reasons. The main concern with the GPL was that commercial companies, such as IBM and others, avoid GPL'd code like the plague. The fact that the GPL is "contagious" discouraged many companies from putting effort into projects that are distributed under it. If we take a look at the few open source projects that IBM endorses, we would find Apache, Jakarta and PHP - none of which is released under the GPL, and we believe it is not a coincidence. These licenses are less restrictive, and we believe they work better in the real world. We also felt PHP was mature enough to let everyone use it, without having to ask for our permission, which is why the permission clause was dropped. Other than that, the license stayed pretty much the same.
Daemon News 1999/06 The GPL vs. Capitalism by Pedro F. Giffuni
Nowadays I personally think that Richard Stallman is a good person but he is confused (I hope he thinks the same of me when he finishes reading this article :), and I am not going to analyze the answers RMS gave because that is not the objective of this article. I arrived, however, to two important conclusions:
The GPL is a long license; sometimes I think it was made so that people would get tired of reading it; something like those big contractas with small letters on it. Until here I had no real problem with the GPL, and since Microsoft was evidently afraid of the rebirth of UNIX (of course Microsoft considers everything a threat), I even considered it a good thing: like most things that are evil, the GPL seems beautiful on the surface. Of course I saw the truth later on...when I saw it and it was clear to me what people that adopted the GPL were doing to the other people. I was aghast. It was not communism or socialism, this was simply and plainly anticapitalism, a game of trying to break the system with it's own logical rules!
- the GNU Public License will not save the world,
- there shouldn't be a universal license; different situations require different licenses.
Of course no one cares that big software companies that exploit their developers and their customers die, but big companies will have better chances to survive against free software: small companies will simply die. Let's say that you are an independent software developer, such as a compiler writer, and you spend hours, or many years, developing your product; you will find it's very difficult, probably impossible, to compete against a free software product, as egcs, that has many more man-hours than your product.
In capitalist countries people live for money. Careers are expensive, technical people have to live off what they know. Who makes money out of free software? At first glance no one, that's why it's free. Some redistributors and support people make money out of it, but they surely make less than the vendors of commercial products. Free software vendors can offer better prices because they don't have to hire developers, not because they are particularly efficient redistributing software. Most importantly, authors won't receive anything or will receive a misery if they beg for it.
If you don't want money from your code, that's OK, but by releasing software under the GPL you are forcing other software writers to use the same poverty license even if they add significant features to your code. They must also take care in using different algorithms; no one wants to be sued for changing variable names and indentation from GPL'd software.
One of the most ridiculous reasons for adopting the GPL is..."oh but if Microsoft takes my code...", well, what makes you think they will? I understand they bought and paid their own TCP/IP stack, even when the free BSD version was available; they simply didn't want to give credit to anyone. If they take your code and do significant improvements everyone wins, if they don't do any significant improvements the resulting product will probably not sell well, and people can still get your sources; no one will "take away" free software from you.
Boy, I dislike Bill Gates and his practices, but admittedly he learned his dirty tricks in the same economical system, and he gives jobs to the people. If he could offer a good OS with full added value I would buy it, and I wouldn't have any problem with him, or any other developer, becoming rich from his work, in the meantime, Hotmail should have a "Powered by FreeBSD" logo.
It's also ridiculous to choose Linux over *BSD because of it's license: how many people would choose Windows NT over Linux if Microsoft adopted the GPL?? Linux users are usually confused, they adopt Linux because it's popular "and cool" and hide their ignorance in completely subjective reasons like the license or some technical merit that they heard about but they don't really understand.
All in all, Ken Thompson is right: people are choosing Linux, and the GPL, because it's an alternative to Microsoft. I hope this popularity goes by, otherwise I'd recommend Jeremy Rifkin's excellent book on what will happen in the next years.
Of course, this is all my personal opinion and some food for the thought, please don't email me to say that you disagree or how unfair I have been :).
CPUReview
Why you SHOULD use the LGPL for your next library by William Henning
Editor, CPUReview Copyright February 1,
1999 ALL RIGHTS RESERVED
Mr. Stallman writes:
"Using the ordinary GPL for a library gives free software developers an advantage over proprietary developers: a library that they can use, while proprietary developers cannot use it."
This makes perfect sense from the "GNU virus" point of view: it would discourage the development of commercial software for Linux, however would not encourage the widespread adoption of Linux. We have to remember the massive amount of positive publicity generated for Linux by the availability of commercial databases such as DB2, Ingress, etc.
The commercial software, along with the increased public awareness from the wide media exposure that Linux has received allowed Linux into a number of commercial settings where otherwise it may not have been considered.
We must value the LGPL for allowing commercial usage of library code. RMS admits this in the following paragraph:
"Using the ordinary GPL is not advantageous for every library. There are reasons that can make it better to use the Library GPL in certain cases. The most common case is when a free library's features are readily available for proprietary software through other alternative libraries. In that case, the library cannot give free software any particular advantage, so it is better to use the Library GPL for that library."
At least it seems that we need not fear the glibc license being changed to the GPL. The 'Readline' library is then touted as having brought about the GPLing of an application, and therefore as being an excellent reason for using the full GPL on libraries.
I would suggest that instead of promoting the use of the GPL for software, all that the GPL license for the readline library means is that readline cannot be used for commercial software - or other 'Open Source' licenses incompatible with the GPL.
In both cases, if similar functionality is desired for the project considering a similar library, development effort better spent on debugging or adding features to the software must instead be used to re-invent the wheel.
Fetch your flamethrowers It's time to argue the finer points of software licenses (InfoWorld)
What I can't understand is why they can't coexist. Enemies of the GPL tend to focus on the claim that its originator, Richard Stallman, invented the GPL to destroy capitalism. Whether or not that's true, I personally couldn't give a flying fig. For one thing, people are getting rich selling GPL software. And if I found out the inventor of the knife was a homicidal maniac, it wouldn't motivate me to start cutting my steak with a fork.
Enemies of the Berkeley license attack its potential to be abused. If you have the source code for a Berkeley licensed program, there's nothing stopping you from changing one line of code and making the resulting program closed source and proprietary. It's true. Did you know Microsoft uses the Berkeley FTP program for Windows? But as for abuse, let's get real. Does anyone really think that nobody has abused GPL software?
GPL and BSD explication and comparison by Rob Bos -- an pretty interesting comparison of BSD license and GPL. He tries to address the problem of incompatibilities between GPL and BSD:
The Berkeley Software Distribution license can be summarised thusly: As minimally restricted as humanly possible. All BSD'd code has one restriction, besides the usual "we will not take responsibility over what you do with this code" -- the copyright notice must be retained, and therefore the copyright of the authors over their code.
That's it. You can distribute it as either binary, source, or either, even under a different license (provided that the terms of the above are met). You can take BSD code, polish it up a bit, and sell it. It is, of course, not in your best interests to ignore the core development community. There are several instances of companies giving large segments of code back to the Free software community -- voluntarily, and not at the request of a legal clause.
This lends itself quite well to the "embrace-and-extend" model of co-opting a market; however, BSD's inbuilt protection is a lot more subtle -- simply the fact that it is extremely expensive to maintain a code fork, especially when the competing code is undergoing the constant revision that free software usually does. Certainly the company could integrate patches from the original, but over time this is not practical. Maintaining a proprietary version of a free project is well-nigh impossible.
The BSD license is attractive to corporations because it allows them to maintain greater control over the code; however, over time it allows an Open Source development community to form, and take over administration of that code. As such, it is superior to GPL in that it greatly eases transition and allows a compromise between proprietary and open development, with decided advantages to both -- corporations can still pretend that the free version doesn't exist, integrate patches, and sell for obscene prices to the end user, but the free version still does exist in the form of the core development community. Code forks can not be maintained, since as you integrate more and more of the patches of the free version, your product ends up approximating the free version anyway, which will do 90% of what yours does -- and for free.
BSD is simple, streamlined, and it works very well in real-life situations. It has been tested in a court of law, it's been around for years, and the bottom line is, it produces good software. The existence of BSD-licensed software such as Apache, XFree, and the larger {Free|Open}BSD software distributions and the community around them is testimony to this.
...
GPL makes far fewer assumptions than any other Free software license does. It assumes that the people will tend to make their software un-free, if left to themselves. This has historically been true -- an individual occasionally crops up in the hacker community that tends to exploit the common code to their advantage. Take Gates, for instance. It's only a matter of time in any community where someone tries to use Free software to their personal advantage. GPL tries its best to prevent this eventual occurance, be it the integration of GPL code into a proprietary product, or the requirement that any derivative products be licensed under the GPL.
The GPL works best only when you have a basic program framework to build from, getting to a slower start but producing more free, user-community-restricted software. The existence of several hundred of these programs is a testimony to the singular effectiveness of GPL towards producing small, efficient, and interoperative software.
...in the opinion of many people, the single most glaring deficiency -- and the greatest strength -- of GPL-licensed products; that is, its habit of excluding proprietary code and applying itself across the superset of code that it is integrated into.
On the other hand, BSD tends to spread its legs to whoever wants to use it; any one can do what they like with it, even if it is at the behest of the development community.
This is why I feel that GPL's proliferation will not hold for large companies as they open source their products.. it's simply not practical for them to do so.
On the other hand, as development shifts away from monothilic software packages packed to the brim with bloat towards small, efficient software packages that do one thing and do it well, involving many more people directly in the development process, GPL will take a firmer grasp in the market. Projects working from the bottom up have no such baggage; no installed base of code to deal with, and most importantly, they can pick and choose techniques and code from other sources.
So, which one? Which will survive, to dominate the computer marketplace?
Neither. Just like all the other holy-war dualities that show up all over the place in the Free software world -- vi and emacs, KDE and GNOME, proprietary and free -- the old BSD vs. GPL holy war will spur the ignorant legions to battle, producing better and better software.
osOpinion Tech Opinion commentary for the people, by the people. By Dave Stanley
I 've thought about the BSD License and GPL, and I've concluded that BSD is the most free intellectual license around. BSD allows anyone the freedom of doing whatever one wishes with BSD code. BSD allows reward through money from proprietary work or the zero cost to great software. I also like the GPL because I can get good stuff for free, but BSD also does the same. The programming language Eiffel is available under both licenses (at tucows). BSD and GPL are good for consumers, particularly students and developing countries. Entrepreneurs who provide great software need payment for that work to make a living. GPL reminds me of the hippie movement and its idealism. At some point, someone has to get rewarded for work, and often that reward comes through cash. Unless the market economy grows obsolete for an economy that favors free production (barter is still a type of market economy), professional software developers will require payment for their work. Humanity seems far off from that Star Trek world where everyone strives for self-improvement and spiritual wealth rather than for material and monetary wealth. Even in Star Trek, a form of capitalism existed on Earth where payment came in the form of "credits"- cashless economy.
The GPL is ahead of its time. Perhaps the interest in GPL software and Wall Streets frenzy over Linux stocks will wane if pure Linux companies can't earn the expected profits that inflated their Initial Public Offerings, or if amateur developers, like the hippies (who became yuppies), get frustrated and jaded over money they could have earned and someone else is earning off their work. I'm certain the GPL is here to stay and will always be the interest of hackers and students developing portfolios of GPL contributions to present to future employers. When the day comes for that Star Trek economy, the GPL may be the one and only license. For now though, the BSD seems like a good transition to that utopian Start Trek world. Business and freedom can co-exist with BSD. Developing nations like Korea (hopefully, the North and South will be one soon) have access to free and superb technology through GPL and BSD and a chance for G7 status. When Korea becomes a "developed" nation, it can sustain a healthy market economy with BSD-like technology.
I favor a temporary copyright for companies that wish to make money, grow and re-invest in R&D, and hold the interest of open-source advocates. For example, if a company creates a virtual machine that transcends any OS, it uses a temporary copyright for 3 years before the code falls under BSD or GPL. This way, everyone wins. Sun probably should have done this with Java. Now Java Personal Edition will splinter into 2 standards, the Sun standard and the EMOC (I think- some acronym anyway) standard. Sun now has incurred the abandonment of IBM who will use its own virtual machine for Java and the distrust of new Java developers. Perhaps another license should be created that allows a temporary copyright. Call it, TCL for Temporary Copyright License and after 2 or 3 years the product falls under BSD or GPL. What do you think?
Free software licenses -- by Paul Fisher. Discusses copyleft, open source definition, licensing compatibility, and binary bundling.
Looking at the General Public License and Open-Source Licenses by By Tony Stanco
Free software licenses -- by Paul Fisher. Discusses copyleft, open source definition, licensing compatibility, and binary bundling. Compare with The Open Source Definition
See Google Web Directory - Computers Open Source Licenses for more complete list.
Vita Nuova Inferno Subscription Licence Fee based, mostly open source, for Inferno (Lucent Network OS).
Sun's Community Source License
Sun Microsystems attempt to embrace the benefits of the open source movement without losing control or giving up its intellectual property. The new licensing deal applies to Java and Jini right now and will apply to EmbeddedJava and PersonalJava in the future.
"This hybrid that takes the best of the open source model, creating a community of developers working together to evolve a technology base, and combines it with the best of the Java licensing model, which has been all about preserving compatibility," Sun spokeswoman Elizabeth McNichols said. "We believe that as a result of this we are going to see implementations of the Java platform that are well-suited to a far broader range of devices and appropriate for a far broader range of industry environments than has been the case to date."
Lucent Technologies, Inc.- Plan 9 Open Source License Agreement
Linux Weekly News BitKeeper Feature -- a very interesting license[June 17, 1999]
X Consortium -- BSD style license without advertising clause
Artistic -- the Artistic license written by Larry Wall (Perl author)
Aladdin Enterprises Ghostscript- Aladdin Free Public License (AFPL)
Liberal Source Software (LSS) -- Hybrid licensing model, between free and commercial software licenses.
Excerpt from http://www.OpenBSD.ORG/policy.html
The GNU Public License and licenses modeled on it impose the restriction that source code must be distributed or made available for all works that are derivatives of the GNU copyrighted code.
While this may be a noble strategy in terms of software sharing, it is a condition that is typically unacceptable for commercial use of software. As a consequence, software bound by the GPL terms can not be included in the kernel or "runtime" of OpenBSD, though software subject to GPL terms may be included as development tools or as part of the system that are "optional" as long as such use does not result in OpenBSD as a whole becoming subject to the GPL terms.
As an example, some ports include GNU Floating Point Emulation - this is optional and the system can be built without it or with an alternative emulation package. Another example is the use of GCC and other GNU tools in the OpenBSD tool chain - it is quite possible to distribute a system for many applications without a tool chain, or the distributor can choose to include a tool chain as an optional bundle which conforms to the GPL terms.
The BSD License Problem (also http---www.gnu.org.-philosophy-bsd.html) -- on BSD-license advertising clause'
Apache Server License -- BSD style that enforce commented block at the beginning of each source file.
GPL is the most popular of open/free source licenses, but it has several weak areas. While the FSF promotes open source code as a means of cooperating and producing software, his "free software" philosophy might be considered as somewhat fundamentalist flavor of "software socialism". And jangling with the words "free" and "freedom" is one of the most prominent Stallman's hobbies ;-). See for example his critique of The Problems of the Plan 9 License where he failed to realize the license tries to address (among other things) the "renaming game" problem present in GPL v.2. Actually there are two flavors of GNU license (GPL and LGPL):
One problem with both licenses is that they does not protect the author's contributions from "one-to-one" highjacking. In this sense this is "the law of jungles", anti-copyright license. Any as I see on the WEB the author of the derivatives that have a couple of small patches to the original (see for example TARA). Thus one of the GPL's loophole is "renaming game." All that GNU formally require is that "You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change". You do not need any reason for the change. Here is the relevant quote:
2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
- a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.
- b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
- c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)
For example if I want to create a "derivative" work by renaming some files in the original and the name of the product it's perfectly OK with GNU.
Linux
Today - Why you shouldn't use the Library GPL for your next library
by Richard StallmanWhen the General Public License should be preferred to the Library General Public License.
The GNU Project has two principal licenses to use for libraries. One is the GNU Library GPL; the other is the ordinary GNU GPL. The choice of license makes a big difference: using the Library GPL permits use of the library in proprietary programs; using the ordinary GPL for a library makes it available only for free programs.
Which license is best for a given library is a matter of strategy, and it depends on the details of the situation. At present, most GNU libraries are covered by the Library GPL, and that means we are using only one of these two strategies, neglecting the other. So we are now seeking more libraries to release *under the ordinary GPL*.
Proprietary software developers have the advantage of money; free software developers need to make advantages for each other. Using the ordinary GPL for a library gives free software developers an advantage over proprietary developers: a library that they can use, while proprietary developers cannot use it.
Using the ordinary GPL is not advantageous for every library. There are reasons that can make it better to use the Library GPL in certain cases. The most common case is when a free library's features are readily available for proprietary software through other alternative libraries. In that case, the library cannot give free software any particular advantage, so it is better to use the Library GPL for that library.
This is why we used the Library GPL for the GNU C library. After all, there are plenty of other C libraries; using the GPL for ours would have driven proprietary software developers to use another--no problem for them, only for us.
However, when a library provides a significant unique capability, like GNU Readline, that's a horse of a different color. The Readline library implements input editing and history for interactive programs, and that's a facility not generally available elsewhere. Releasing it under the GPL and limiting its use to free programs gives our community a real boost. At least one application program is free software today specifically because that was necessary for using Readline.
If we amass a collection of powerful GPL-covered libraries that have no parallel available to proprietary software, they will provide a range of useful modules to serve as building blocks in new free programs. This will be a significant advantage for further free software development, and some projects will decide to make software free in order to use these libraries. University projects can easily be influenced; nowadays, as companies begin to consider making software free, even some commercial projects can be influenced in this way.
Proprietary software developers, seeking to deny the free competition an important advantage, will try to convince authors not to contribute libraries to the GPL-covered collection. For example, they may appeal to the ego, promising "more users for this library" if we let them use the code in proprietary software products. Popularity is tempting, and it is easy for a library developer to rationalize the idea that boosting the popularity of that one library is what the community needs above all.
But we should not listen to these temptations, because we can achieve much more if we stand together. We free software developers should support one another. By releasing libraries that are limited to free software only, we can help each other's free software packages outdo the proprietary alternatives. The whole free software movement will have more popularity, because free software as a whole will stack up better against the competition.
Since the name "Library GPL" conveys the wrong idea about this question, we are planning to change the name to "Lesser GPL." Actually implementing the name change may take some time, but you don't have to wait--you can release GPL-covered libraries now.
Comments:
Martin Cracauer's GPL Page -- interesting critique of GPL that contrasts it to LGPL.
| Abstract: | The GNU General Public
License (GPL), used by many popular free software packages,
contains some requirements that makes it hard to use in the real
world.
Most importantly, its clause that program modules under the GPL must not be linked with modules under licenses that add any term the GPL does not have, prevent many good software packages from being combined. There is an alternative license - the LGPL - that has all the power to protect people's own work, but without the extended requirements that serve no other purpose than to force your will on someone else and his work. |
|---|---|
| Intended audience: | People who advocate free software, people who need to choose a license for their free software package, people who want to understand some of the political issues that handicap development of free software. |
| Required knowledge: | You must understand why authors of free software differ in their opinions what to allow others to do with the software they released to the public. |
The essence of the section is very well explained by the following Slashdot posting:
Re:Is BSD more free than GPL (Score:0)
by Anonymous Coward on Saturday January 01, @11:52AM EST (#51)
Another variant of the same phobia is the Microsoft will steal their precious code:
Re:Foo! (Score:3, Insightful)
by Arandir (arandir-at-meer-dot-net) on Saturday January 01, @04:25PM EST (#151)
(User Info) http://www.meer.net/~arandir/
"...but keep in mind that by choosing BSD, you could be working for Microsoft for free."
So what? Are you so arrogant to believe that Microsoft even wants your code? The number of incidents where Microsoft used BSD code can be counted on one hand. Compare that to the myriad BSD packages out there and it's insignificant. And the number of BSD packages which withered away because some "proprietary" Microsoft version existed is exactly ZERO.
Besides which, all you Anonymous Cowards keep telling me that Free Software is not about "free beer". If it's not, then who cares if Microsoft sells your "beer" for money?
Here is one the replies that underline another side of the problem -- the side that also is present in the existence of a special version of Linux for Transmeta -- an ultrasecretive company that does not revel the actual architecture and command set of their chips.
Re:Is BSD more free than GPL (Score:0)
by Anonymous Coward on Saturday January 01, @11:24AM EST (#31)
Yes, but what about those of us who would like to contribute to a GPL product that eventually has many authors?
If the original author wants to take it commercial, and I can't, I'd be pissed -- especially if I did a proportionally similar amount of work.
I seriously question the validity of this position taken in the GPL. If he can, using some of my code, I say fuck him and let him use untested and shaky license in a court case. I'd like to see something like this happen.
| Re:Is BSD more free than GPL
(Score:0) by Anonymous Coward on Saturday January 01, @12:07PM EST (#60) |
I seriously question the validity of this position taken in the GPL. If he can, using some of my code, I say fuck him and let him use untested and shaky license in a court case. I'd like to see something like this happen.Agreed. It's about time that a judge applied his line-item veto to cross out invalid portions of the licence. And no, that doesn't break the whole thing. That's not how contracts work. Get a lawyer. The GPL is not supportable. |
| Re:Is BSD more free than GPL
(Score:3, Interesting) by Arandir (arandir-at-meer-dot-net) on Saturday January 01, @04:06PM EST (#145) (User Info) http://www.meer.net/~arandir/ |
| "Perhaps you should look proprietary up in
the dictionary before you apply it to gcc." ----- Proprietary: (1) of, relating to, or characteristic of a proprietor (2) used, made, or marketed by one having the exclusive legal right. Proprietor : one who has the legal right or exclusive title to something : OWNER ----- Proprietary software is owned software. The FSF owns gcc. By retaining a copyright, they have retained exclusive legal rights to gcc. The FSF is the owner and proprietor of gcc, and thus gcc is proprietary. Perhaps you should use a real dictionary, instead of the redefinitions the FSF uses. |
Contrary to Open source Initiative claims it's proven historically that GPL does not prevents from business opportunities per se. It just gives enormous advantage those who first enter the market (Sygnus and Red Hat are nice examples here). And GPL proved to be a very hype-friendly and IPO friendly license (i.e. the market capitalization surrounding these companies is almost completely based on hype ;-) The real question is if this is a sustainable business model. Here is one opinion from Slashdot:
| Re:GPV destroys
business opportunities (Score:2) by dennisp (spam-me-and-die@darkpower.net) on Sunday January 02, @05:59AM EST (#254) (User Info) |
| Yes, but the real question is if this
is a sustainable business model. If forced to provide all changes to
your product, competition will flourish and this sector of the market
as a whole will reach a point of diminishing returns -- from which some
will leave market and others will join -- producing a cycle that is not
very good in the eyes of the shareholder. However, the hype surrounding linux has also brought proprietary software built around that free software. This model is possibly sustainable if handled properly due to at least temporary product differentiation. If you offer product differentiation that fulfills a market need that free software does not, then you can likely become profitable. Unfortunately, this model is not similar to the proprietary model that Microsoft runs. Therefore, the market capitalization surrounding these companies is almost completely based on hype. Why? Because this new model relies on support, service, and partially proprietary extensions -- and these industries do not have large profit margins. Companies such as VA Linux offer very little product or service differentiation in their own specialization. If they can move more towards producing real solutions, they can become a solid player. This sector of the industry is growing at an exponential pace, and there seems to be room for many. They will, however, have to compete with the likes of IBM who have used their past reputation and power of brand name to partially reinvent themselves in this changing market. SGI, at a glance, seems to be the victim of a few very large long term strategic planning mistakes. In my opinion, if they can provide sufficient product differentiation and added value to forego the recently commodified pc market, or cater specifically to the high end and niche markets, they have a very good future. Again, those last three giants aren't even specifically in the free software market. They are only leveraging its hype due to the me-too effect. It's kind of like price wars in other industries that come out of nowhere. Getting away from the market giants, there are a number of viable models that can and will work. Ones that I can currently think of are: a) companies that are essentially in another industry that is not directly tied to software can collaborate with other companies in the same or other industries to produce open software that will benefit everyone. example: I prototype a particular java library that is part of a bigger picture in my company. The resources involved in creating this library would be a large drain on project budget. I come up with the idea to make this a community project and talk with friends in other companies (or a less organized community at large). We decide that we can split costs by collaborating on producing all the parts of this library (as well as qa). We GPL this product because it is not part of our bigger software or solution model. I would also note that I get flak because our traditional model is to monopolize anything and everything our employees produce. I eventually convince management that this is a positive symbiotic relationship. b) one company comes up with an idea for a standardized format or protocol, but needs industry support for it to be successful example: Livepicture Inc conceives the flashpix format. It works with Microsoft corp, HP, and Eastman/Kodak to produce this image format. It then donates this format to the DIG. c) traditional service/support model based around open source software example: i produce a high level language to help produce ISAPI or NSAPI modules. I completely open source this software but rely on support and maintenance for revenue. I also collect bug reports and fixes from the community because they have access to the code. d) completely open software except a couple of restrictions example: PHP. It's completely open except for the zend engine -- which is limited in that you can not use it in *other* proprietary products. You can, however use PHP wherever you want as long as it is still PHP e) open source software that is limited in that changes must come back to the company of creation. They own all changes. example: SCSL. Many companies wish only to use a language, application, or protocol. They do not wish to commercially gain from it. Now that they have the source, they can work it to their own ends. f) temporarily proprietary software example: Mysql. They have a delayed release model. They release their software under the GPL (if I'm not mistaken) when there is a sufficiently better proprietary product available. This way they can retain their advantage, but still release usable code to the public. g) for fun or coding in free time example: half the stuff on freshmeat? :) A lot of projects would not be possible without community input and work. We can all produce a product that *we* want without having to worry about commercial viability. We're directly fulfilling a need, usually without the exchange of money. This is very efficient. h) academia, research sectors, or R&d at large companies example: framework, pre commercial, standards based, or commercially unviable software I'd like to hear any other examples if anyone has any ;). |
GPL is obsolite arguments: component/remote execution related issues
Re:Foo! (Score:1)
by harlows_monkeys on Saturday January 01, @02:04PM EST (#120)
(User Info)The GPL does NOT prevent corporate interests from exploiting your work with no remuneration to you. For example, if I can arrange my money-making scheme so that all your GPL'ed code is running on my server somewhere, and the clients are just accessing it over the web, guess what? I'm making money from your code, and I don't have to give it to anyone. Clint/server approaches can take a lot of the bite out of GPL. Look at TiVo. They are certainly benefiting greatly from Linux, but the guts of their stuff runs as an application, and so does not have to be GPL'ed. They take the regular Linux kernel, make a few mods (which they GPL), and then use it to run their proprietary application.
And then there is component-based computing: COM on the Windows side, and CORBA everywhere else. GPL, which is fundamentally based on a dying model of how computer programs work, provides basically no protection then.
Ethic-related critique of GPL:
Try this: GPL and reason behind copyright (Score:0)
by Anonymous Coward on Saturday January 01, @02:05PM EST (#121)
First: GPL is proving itself an effect means to an (RMS's) end, namely, GNU (GPL-licensed OS+apps). Those who don't care about ethics, philosophy, etc., won't need to burden their minds further. Many of us find the discussion entertaining or important to influencing how we or others license the code to which we or other may want to add more code (ie, derivatives). Now, on to my seldom-seen point. Copyright law exists mainly to encourage people to create and publish works. (The law recognizes that complete loss of copyrights after about a hundred years will has little effect on that encouragement, for example.)
GPL-licensor's use of copyright law, specifically the viral aspect (you can't use my code if you don't GPL your additions), has little or nothing to do with encouraging new work. Few people would not develop software if they couldn't use the GPL. In fact, it discourages new work because it many developers will refuse to make derivatives of GPLed software because they refuse to be told how to license their own work.
BSD type licenses (and some parts of the GPL) do encourage new work by protecting reputation (attribution clauses, etc.) and protecting against liability (warranty clauses, etc.). But the nasty no-share clause of the GPL has nothing to do with the reason for copyright law and the GPL thus abuses the law. That is the business of (even) ethical lawyers, but it shouldn't be the business of ethical software developers. It's inherently selfish and should receive the same admonishment as other forms of selfishness outside the commercial world.
Right Wing Critique of GPL
Re:Stallman of Borg (Score:1)
by Ateran (ateran6@hotmail.com) on Sunday January 02, @12:31AM EST (#212)
(User Info) http://www.ateran.com
Okay, so the GPL is basically the same concept as communism. On paper, communism can work, but in a real world situation it eventually leads to corruption in government. This does not mean that it can not work for software.
Ignore the cults! (Score:0)
by Anonymous Coward on Saturday January 01, @11:27AM EST (#35)
The GPV is a licence to steal. It's a licence to force other people to work for free. It's a licence to infect traditional software models with a neutron bomb to kill the bottom line. It's a licence that pretends to be noble, but in fact, is completely insidious and misleading. It's a licence that twists words out of their normal meanings for the purposes of the cult.
LNUX and RHAT sponges (Score:1, Funny)
by Anonymous Coward on Saturday January 01, @11:40AM EST (#44)
So you prefer to work for the millionaires at RedHat/VA Linux for free? It really pisses me off that the only people who are able to make money off of GPV'd software are people like RHAT and LNUX. Why isn't the author making anything? Because of this collectivist mentality. The party favourites get their dachas, and the rest of us stand in line for bread.
[Dec. 11, 1999] Slashdot Ask Slashdot What about the Artistic License
GPL and forking (Score:4, Insightful) by Dr. Sp0ng (spong@SPAM.glue.SUCKS.umd.edu) on Thursday December 09, @09:30AM EST (#10) (User Info) http://www.wam.umd.edu/~spong/ The GPL allows forking, but it also implicitly prevents it, because any forks must also be released under the GPL. If the new features in the forked version are better than the original, there's nothing preventing the author of the original version from stealing those changes an integrating them back into his version. Meanwhile, he's been doing development, so now he has his changes PLUS the other guy's changes, and he comes out on top. To answer your other question about being able to create a commercial, closed source version of the authors need to pay the bills: the GPL allows this as well (as does any other license) The original author of the program retains the copyright to the code and can re-release it at any time under any license he wants. What the GPL prevents is OTHER people stealing GPL'ed code and selling it as a commercial, closed source program. (this doesn't, however, prevent other people from selling it as a commercial, Open Source product)
Too many licenses (Score:2, Insightful) by Mendax Veritas (mendaxveritas@yahoo.com) on Thursday December 09, @09:31AM EST (#15) (User Info) I feel there are too many more-or-less-open-source licenses, and the really annoying part is that they sometimes conflict with each other such that you can't merge code using License A with code using License B. IANAL, but the GPL and LGPL seem to me quite adequate for non-commercial work, and I don't see why you'd want to release source at all for a commercial work (it just encourages competition). And if you don't object to your open source code being used in commercial products, why bother copyrighting it at all? The public domain is a viable alternative if you don't care what anyone does with the code.
Why I Like the Artistic License (Score:3, Interesting) by chromatic on Thursday December 09, @09:32AM EST (#16) (User Info) http://snafu.wgz.org/chromatic/ As I read it, someone can take my program and modify it and choose how he wishes to release his modifications. He can make them available under the same license. He can make them available only in binary form. What he cannot do (under the license) is to distribute his 'non-standard version' (my program WITH his changes) in binary only form without also including my 'standard version' and the copyrights and disclaimers. It's like a mixture of the BSD (you can do anything you want with it, even make it commercial and secret) and GPL (you can do anything you want with it as long as you allow anyone else the same right with regard to your own modifications). It seems to allow commercial usage while still crediting me for my own work.
There are places where it's more appropriate than others, of course, especially for Perl middleware, where someone is likely to grab a bunch of components and modify them slightly to fit a particular task.
Commercial Forks (Score:3, Interesting) by Effugas (effugas@best.com) on Thursday December 09, @09:35AM EST (#22) (User Info) http://www.doxpara.com But if preventing forks is important, GPL doesn't seem to stop it. So why not just use the Artistic License? Then the authors can some day make money out of a commercial fork if they need to pay the bills!" The author of GPL code is not subject to GPL requirements, so I'm confused where you're going with this. If an author--like Alladin of Ghostscript--wishes to sell non-GPL licensed copies of his software, there's nothing preventing him, except the degree of code that hasn't had ownership signed over to him. Small patches can be presumed to have ownership signed(though it really should be explictly stated), and large ones will end up getting a shared-ownership scenario, one way or another. But the GPL just doesn't do anything to stop commercial forks if the author needs to pay the bills! Honestly, people genuinely don't realize how much work has gone into closing loopholes with the GPL. No matter how esoteric each clause seems, there really are good reasons for them to be there. The problem lies in the fact that overly simple licenses--of which I'm not necessarily saying the Artistic License is one of--have just as much potential for being Gotcha Source as the most complex, overwrought, and landmined license that you can find. Yours Truly, Dan Kaminsky DoxPara Research http://www.doxpara.com
Sounds good to this uninformed reader (Score:4, Insightful) by Taurine on Thursday December 09, @09:44AM EST (#29) (User Info) http://www.taurine.demon.co.uk/ The GPL was designed as a defense against commercial software, it seems. Its one of these 'property is theft' things - anyone care to explain what that means? The GPL basically turns the traditional license on its head - it protects the users instead of the producers. So long as they don't break the license, there is nothing to stop anyone that gets hold of something GPLd from doing something the author doesn't like. Because it provides some safety for users, it is attractive to developers who want to gain users. Personally I like the idea behind the BSD license - that it promotes the use of quality code by allowing anyone to borrow bits for use in anything, regardless of the next license, so long as it is acreditted. I think the GPL's political nature will ultimately prevent its apparent greatest ambition - to move to a world where everything is GPLed. It works fine for hobby projects, labour of love stuff, like Linux. But at the same time it excludes the larger part of the software producing world - industry - from benefitting unless they are prepared to change their whole business model to the one advocated by RMS and his wandering carrier bags. But it is doing us a great service by bring the whole open source thing back into relatively common use, like it was when Unix was young. Thanks for asking the question. I will make the effort to look at the Artistic license and see if I can learn from it. It sounds like a fair solution.
It's about freedom, not commercialism (Score:2, Insightful) by alisdair mcdiarmid on Thursday December 09, @10:05AM EST (#54) (User Info) RMS is not out to stop companies making a buck on their software. Their licence is not there to stop people forking their software, then selling it. The GPL is not defined as it is because they want to stop these things. The GPL is about freedom. The whole point of it is that, once a piece of software is GPLd, that source will forever be available. We want our software to be freely available to all. If you use the GPL, you are stating that you will not allow someone to close off your source and distribute their derivation. If all we cared about was whether commercial forks were possible or not, why not just stick "you may not sell this software for a profit" lines in your source? It's about more than that: GNU wants software to be free. Remember the concept of copyleft? How many times is this debate going to come up on Slashdot? A summary of the two main licences: 1) GPL - use this licence if you want your software to remain Free as long as you decide to keep it that way. You do not have to license subsequent versions with the GPL; you may relicense at any time. However, no-one else may relicense your software, or distribute binaries without source. This means that, in simple terms, your source code and any derivations will be available to anyone who has access to the binary. 2) BSD - use this licence if you want to get a protocol, standard or ethos popular. For example, if you want people to use your software as widely as possible, and the source is not as important as the idea behind it, this may be applicable to you. If this is wrong, please correct me.
One of the great myths about licenses (Score:3, Insightful) by PrimeEnd on Thursday December 09, @11:35AM EST (#102) (User Info) "So why not just use the Artistic License? Then the authors can some day make money out of a commercial fork if they need to pay the bills!" One of the great license myths is that the GPL prevents authors from making money and less restrictive licenses permit it. My experience is exactly the opposite. I wrote a GPL'd program which a big corporation wanted to use part of in a commercial product, which they did not want to GPL. They asked for a special license which I granted for a nice fee. If I had used the Artistic or BSD licenses, I would never have heard from them and never even known they used my code.
This is a big advantage of the GPL which is not often mentioned in these discussions.
In order to understand the Artistic License... (Score:3, Informative) by Arandir (arandir-at-meer-dot-net) on Thursday December 09, @01:47PM EST (#184) (User Info) http://www.meer.net/~arandir/ I used to release my works under the AL, but have switched to the BSD. But I still have a warm spot in my heart for the AL nonetheless. In order to understand the Artistic License, you first have to understand where it comes from. The AL first arrived on the scene with Perl. Perl, as you are aware, is a multi-disciplinary language. The hallmarks of Perl hackers are hubris, laziness and impatience. There is more than one way to do anything is the Perl motto. The Artistic License reflects all of these things, as well as the linguistic legerdemain of Larry Wall's humour. Perl was release under a dual GPL/Artistic license. Larry wanted the hacker community to embrace Perl, but understand that there was a large contingent of "GPL or Go To Hell" reactionaries within it. He also wanted it to be used by the suits, but also understood that many in the corporate world are frightened of the viral nature of copyleft. By releasing Perl under a dual license, the user could choose whatever license they wanted and no one would ever know. You could be secretly using Artistic Perl while everyone else around you thought you were using the party line GPL. Or vice versa. Talk about subversion! Bruce Perens perenially states his dislike for the AL because he thinks it is a "sloppy" license. Bruce Perens should take some classes in linguistics. "Artistic License" has a meaning beyond the mere name of a software license. The main gist of the Artistic License is that you can do anything you want with the software, but you must let the user know you're doing it. Thus, you can take AL's software proprietary, but the user can't be hoodwinked into thinking he's running the real stuff, and you have to let the user know where to get the real stuff if he wants it. If none of the above makes any sense, then just visualize the Artistic License on the middle of an imaginary line stretched between the BSD and GPL licenses.
LUCENT TECHNOLOGIES INC -- contains interesting modification limitations
3.1 Modifications which You create or to which You contribute are governed by the terms of this Agreement and must be made available under the terms this Agreement in at least the same form as the Source Code version of Original Software furnished hereunder. Any distribution by You of the Source Code version of Licensed Software must be made under the terms of this Agreement or any future version of this Agreement under Section 11.0, and You must include a copy of this Agreement with each and every copy of such Source Code version of Licensed Software which You distribute. You may not offer or impose any terms on any such Source Code version of Licensed Software that alters or restricts the terms of the applicable version of this Agreement or the Recipients€ rights and obligations hereunder.3.0 DISTRIBUTION OBLIGATIONS
3.2 You must cause all Licensed Software to which You contribute, i.e. Your Modifications, to contain a clear identification, e.g., a separate file, documenting the changes made by You and identifying You as the Contributor that reasonably allows subsequent Recipients to identify the originator of the Modification. To the extent You create at least one Modification, You may add Your name as a Contributor to the requisite notice described in Section 3.3.
3.3 With respect to Your distribution of Licensed Software (or any portion thereof), You must include the following information in a conspicuous location governing such distribution (e.g., a separate file) and on all copies of any Source Code version of Licensed Software You distribute:
"The contents herein includes software initially developed by Lucent Technologies Inc. and others, and is subject to the terms of the Lucent Technologies Inc. Plan 9 Open Source License Agreement. A copy of the Plan 9 open Source License Agreement is available at: http://plan9.bell-labs.com/plan9dist/download.html or by contacting Lucent Technologies at http: //www.lucent.com
All software distributed under such Agreement is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See the Lucent Technologies Inc. Plan 9 Open Source License Agreement for the specific language governing all rights, obligations and limitations under such Agreement.Portions of the software developed by Lucent Technologies Inc. and others are Copyright Ó 2000. All rights reserved.
The Problem with Plan 9 -- incoherent critique of some pro Open Source folks
Mozilla Public License version 1.0 a pretty interesting license that among other things tries to enforce some description of modifications. MPL is most similar to the XFree86-style licenses. The main difference is that modifications to existing source code must be released under the MPL. However, any added subroutines in separate files need not be released under the MPL. Proprietary extensions to MPL covered software can be easily added.
3.3. Description of
Modifications.
You must cause all Covered Code to which you contribute to
contain a file documenting the changes You made to create that
Covered Code and the date of any change. You must include a
prominent statement that the Modification is derived, directly or
indirectly, from Original Code provided by the Initial Developer
and including the name of the Initial Developer in (a) the Source
Code, and (b) in any notice in an Executable version or related
documentation in which You describe the origin or ownership of
the Covered Code.
(a) Third Party Claims.
If You have knowledge that a party claims an intellectual
property right in particular functionality or code (or its
utilization under this License), you must include a text file
with the source code distribution titled ``LEGAL'' which
describes the claim and the party making the claim in
sufficient detail that a recipient will know whom to contact.
If you obtain such knowledge after You make Your Modification
available as described in Section 3.2, You shall
promptly modify the LEGAL file in all copies You make
available thereafter and shall take other steps (such as
notifying appropriate mailing lists or newsgroups) reasonably
calculated to inform those who received the Covered Code that
new knowledge has been obtained.
(b) Contributor APIs.
If Your Modification is an application programming interface
and You own or control patents which are reasonably necessary
to implement that API, you must also include this information
in the LEGAL file.
3.5. Required Notices.
You must duplicate the notice in Exhibit A in each file of
the Source Code, and this License in any documentation for the
Source Code, where You describe recipients' rights relating to
Covered Code. If You created one or more Modification(s), You may
add your name as a Contributor to the notice described in Exhibit
A. If it is not possible to put such notice in a particular
Source Code file due to its structure, then you must include such
notice in a location (such as a relevant directory file) where a
user would be likely to look for such a notice. You may choose to
offer, and to charge a fee for, warranty, support, indemnity or
liability obligations to one or more recipients of Covered Code.
However, You may do so only on Your own behalf, and not on behalf
of the Initial Developer or any Contributor. You must make it
absolutely clear than any such warranty, support, indemnity or
liability obligation is offered by You alone, and You hereby
agree to indemnify the Initial Developer and every Contributor
for any liability incurred by the Initial Developer or such
Contributor as a result of warranty, support, indemnity or
liability terms You offer.
3.6. Distribution of Executable Versions.
You may distribute Covered Code in Executable form only if the
requirements of Section 3.1-3.5 have been met for that
Covered Code, and if You include a notice stating that the Source
Code version of the Covered Code is available under the terms of
this License, including a description of how and where You have
fulfilled the obligations of Section 3.2. The notice must
be conspicuously included in any notice in an Executable version,
related documentation or collateral in which You describe
recipients' rights relating to the Covered Code. You may
distribute the Executable version of Covered Code under a license
of Your choice, which may contain terms different from this
License, provided that You are in compliance with the terms of
this License and that the license for the Executable version does
not attempt to limit or alter the recipient's rights in the
Source Code version from the rights set forth in this License. If
You distribute the Executable version under a different license
You must make it absolutely clear that any terms which differ
from this License are offered by You alone, not by the Initial
Developer or any Contributor. You hereby agree to indemnify the
Initial Developer and every Contributor for any liability
incurred by the Initial Developer or such Contributor as a result
of any such terms You offer.
3.7. Larger Works.
You may create a Larger Work by combining Covered Code with other
code not governed by the terms of this License and distribute the
Larger Work as a single product. In such a case, You must make
sure the requirements of this License are fulfilled for the
Covered Code.
Ricoh Source Code Public License -- example of Modzilla-derived license
