What about the Artistic License?
Swordfish asks: "Despite the avid discussion of the merits and vulnerabilities of the GNU lincense, almost no one discusses the Perl Artistic License
in slashdot. Why is there so little discussion of the Artistic License? It seems to me that the GNU License allows forking, but all forks must be free. The Artistic License seem to allow commercial, closed-source forks. 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!"
It's also true that there is not much discussion of the BSD-style-licenses in here - I think that perhaps the /. crowd is a bit closed-minded about other licenses. Not everything worth using comes under a GNU license. The artistic license, as well as other licenses, have their uses. The GPL-style licenses are not applicable to all situations. Even the Sun Community Source license has its place.
Visit
The whole point of a movement be it communism, christianity, or that of jimmy's secret club is to have a world view which is compatable. Spies wear black suits and most people use the GNU/GPL.
More seriously I think that it will allow all changes to be free regardless of forking thus allowing all development to contribute to the whole. This is a model which supports project centric thinking versus developer centric or corporate centric thinking.
Slashdot social engineering at it's finest
I think one reason may be that Larry Wall (and the Perl community in general) don't seem to focus on the license. The FSF has an ethical/political agenda that their license encourages, so they have to advertise it. It also happens that licensing ends up being on of the points in the BSD flame wars.
:)
If asked about the merits of Artistic License, Larry would probably just tell you that there's more than one way to do it
Dana
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)
"Software is like sex- the best is for free"
-Linus Torvalds
The Right to Fork (RtF) is important because it ensures that in the event that the code maintainers go crazy, decide they refuse to incorporate features that many users want, etc. that otthers can take the codebase and fork it.
For example this happened with GNU Emacs, which forked into Xemacs over design and philosophy disputes.
The end result of forking is usually good, in the way in which the GPL allows it. Because all the resultant code must be open and Free, the incentive is to maintain compatibility so as to get people to actually use your forked code. And The GPL is Compatibility-Wise Viral (or some such buzzword enabled thing).
I guess my point is that forking isn't inherently bad, and the GPL doesn't intend to prevent it, just make sure it is done by a set of rules that encourage Freedom and compatibility.
Using Gnu, or any other method or means to produce something, shouldn't make any difference as to whether someone can package it commercially. The time and creative effort to compose the package has to be worth something.
Althought I believe in what you are saying about developer time I think that this can work both in the same vein adom has both commercial features and features that are essentially free (the program has compiled versions for dos and linux x86) and allows for purtchessing of a commercial version for about $20 which allows for special features. This helps both causes: the developer, and the user.
Giving away a product on the premise that you can sell support is fine, if it can fly. But I'd rather have cash in hand.
Again this is fine. However if you want your product to fly if you are doing this freelance usually you get a wider audience if you use the GPL because concievably it could be included say in the next version of Debian or Red Hat.
Slashdot social engineering at it's finest
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.
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.
--
how to invest, a novice's guide
As a Linux user, I'm always glad I can look at the source code. So, when discussing something like a license, I think it would be a good idea to read the actual license. The http://www.opensource.org has the text of all the licenses we are discussing here, specifically at this page.
http://www.opensource.org/licenses/
...so as I was daydreaming at my desk one day in the large, evil, multi-megacorp I work for, I was considering ways that Microsoft, or some other "interested party", might pervert Linux to its own ends. A comment I had heard some little time previously came to mind, likening Windows to a "booster stage" of a rocket that could now safely be discarded that Microsoft had acchieved dominance in applications programming.
I thought to myself, how could Microsoft parasitize the Linux hype in the popular media, and at the same time destroy the organized movement against it? The answer struck me: port IE to Linux, close the source, throw on a few bells, and sell an MS distro. Consumers leery of a new OS would prefer the MS-sanctioned copy, and a port of IE would allow gradual porting of the MS Office APIs and apps.
The only pitfall is the "viral" property of the GPL, under which much (all?) of Linux's code is licensed. Microsoft naturally would not undetake a port of its cash cows, or even IE, if that entailed opening their source. Despite criticisms from men like Tom Christiansen, it seems evident to me that the viral GPL is serving to protect open source "while we sleep" in ways many of us never imagine.
-konstant
-konstant
Yes! We are all individuals! I'm not!
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
I think that some people consider the Artistic License to be ambiguous and possibly not as watertight as the GPL or XFree86 licences. What is a bug fix, for example?
Also, rightly or wrongly, it suffers from being YAL and it's a good idea to choose the XFree86, LGPL or GPL licences instead, to let other free programs reuse your code. (Dual-licensing, as with perl, solves this problem.)
IMHO, all the fuss the AL makes about non-standard executables having non-standard names is unnecessary - it's unlikely there would be a conspiracy to replace your program with a different version without telling anyone. The requirement of the GPL to make it clear when code is modified, or Apache's requirement that you can't call your version 'Apache', seem like a better way to do things.
-- Ed Avis ed@membled.com
I think that people don't discuss the artistic license because it isn't ideologically motivated. The Artistic license strikes me as entirely pragmatic, allowing people to modify the work in question so long as they distinguish between their version and the standard version or make their modifications available. This discourages philosophical flamewars - not many people can argue with a pragmatic license, especially one which is so strongly concerned with rights of authorship and proper attribution.
The point of the GPL is not to discourage forks. So far as I know, and so far as I've read and reread, the point of the GPL is to encourage forks and code reuse. In other words, they have almost totally opposite goals. The Artistic license doesn't even touch on code reuse, which speaks volumes.
GPL authors can still make money ("to pay the bills") by rereleasing under an alternative, proprietary license. I'm not sure if that's possible under the Artistic license - for that matter, I don't think that that's necessary under the artistic license. Which one has the potential to be more profitable is up for argument, of course.
--
--
There is no premature anti-fascism. -Ernest Hemingway
Ok, I admit this is offtopic, however, this is the closest story I can think of that's come up recently....
.000000001 per record returned... something like that.
Recently there has been lot of discussion of databases, and who owns them. The US either is considering or passed a law saying a Database(and info contained there-in) is owned by the creating person/company. [I honestly can't remember.]
At anyrate, this got me thinking of a the (possible) need for DGPL. Basically the same as the LGPL, but adding that the database host (i.e. the owner of the server hosting the specific instance of the db) can put restrictions on access allowing them to offset the cost of hosting the machine (administration, i'net connection, etc.). Examples of acceptable restrictions would be 1) any program accessing this database must display the advert. provided, 2) a cost of
Is there a lic. that allows this kind of thing, or should I be working on one?
I'm aware this would be hard to enforce, but I think it has some potential...
[Yes, this directly related to something I'm currently working on....and no, I don't want to give out specifics, I will talk in generalities though...]
Myddrin
It seems like the right to fork, far from being a liability of the GPL, is a signifigant strength. Its a way to get a bunch of random people to work very hard to reconcile their visions of what a system should be like- nobody wants a code fork, so people try very hard to work together.
On the other hand, when visions are really irreconciliable, the option to fork can be a good thing- Lots of people like Xemacs, and lots of other people like emacs classic, and this code fork let those people do there thing where it was needed. And both emaxen are open source. Everybody still wins.
With the Artistic license things seem to become much more difficult. A lot more responsibility rests with the community- If MegaCorp markets 'MegaPerl', complete with non-standard name & clear documentation of differences, the perl community has to catch up, and quick. Especially when MegaCorp starts introducing Value Adding Incompatabilities® That nobody else gets to see... If one fork of emacs dies tomorrow nobody loses. If perl dies and MegaPerl continues everyone does.
The way to deal with this is aggressive development and promotion. Perl has this, thanks to an amazing community with great leadership. Ad as long as that keeps up, and new features keep getting added to the system, MegaPerl is doomed to failure. But they live in a much more dangerous place than their GPL'd bretheren.
Its the Ideology(tm)!
I'm a big fan of the GPL precisely because it doesn't allow proprietary forks. In fact, without the GPL I probably wouldn't be developing open source code at all.
If I write code and give it to the world, I'm doing it because I choose to, I think people might appreciate my work and maybe I'm feeling a little bit altruistic.
But I wouldn't do this if it were possible for somebody to take my work, make it into proprietary software and make a profit off my labour. I like the GPL because this is precisely the abuse it is designed to prevent. It's important to know that your code won't get ripped off.
As for open source forks, I actually think these are a good thing. Good ideas will flourish, unsucessful forks won't last long. This is the key to evolution, and as long as forks are guaranteed to stay free, I'm quite happy to see them happen.
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.
Nothing in the GPL prohibits authors from releasing commercial versions of their own software -- or closed-source versions either.
In fact, you can't write a license that limits your rights as the author; the GPL is based on copyright law, which says that authors can do anything, but other users have to do what the author says (thus the "nothing else grants you permission to modify or distribute the software" note in the GPL).
So you're free to release your software under as many different licenses as you want, closed and/or open. IIRC, perl itself is a good example of this -- it's available under both the GPL and the Artistic License, so people who want to incorporate it into GPLed projects can do so, while people who need more flexibility have that option as well.
Some of the confusion may arise because if you want your program to become part of the GNU project (as distinct from part of the larger category of "software distrubuted under the GNU GPL") you have to assign your copyright to the Free Software Foundation (give the software to them, in other words). By doing that you relinquish your rights as author and can no longer release closed-source versions.
-- Some things are to be believed, though not susceptible to rational proof.
--
Xenu loves you!
GPL allows forks, indeed ENCOURAGES forks, in many ways, but with all forks free and open (UNLESS the code is significantly re-written, and the amount of GPLed code used is small). This works in the same way as evolution. If something has an advantage, it'll thrive. If it doesn't, it'll die. This leads to the digital equivalent of bio-diversity (electro-diversity?), with a large proliferation of specialised tools, all performing similar, but usefully different, functions.
The BSD licence makes some fundamental assumptions IMHO - that well-designed and well-maintained programs fork rarely and that evolutionary forces are not as significant in programming as market forces (although both exist). This leads to having a relatively small number of variants, all performing a wide range of functions and all very similar (if not identical).
Each of these has a place. The GPL is -not- useful for producing "office" applications, IMHO, because the needs are too structured. There's no room for evolution to take place. Also, each application has to do too many things, and there's little room for diversity. The BSD licence is -ideal- for this kind of application, for the very same reasons.
On the other hand, something like speech synthesis or speech recognition, search engines, toolkits, etc, would be horrible to try under a BSD licence. The drive to fragment, and the fact that any of those fragments can close & become commercial, would rip the project apart, before long. The GPL, though, is perfect for this, encouraging and promoting the very things that would destroy the work, under a BSD licence.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
GPL doesn't prevent forks, in fact, the right to fork a project is something the GPL was designed to protect.
However, since all forks must be GPL'ed as well, it will always be legal to remerge the forks. This is a big difference compared to licenses that allows proprietary forks, for example the BSDL. The many proprietary BSD derived operating systems can not be remerged without permission of all the copyright holders.
- This source code is free.
Of course, this leaves the restrictions and legal remedies somewhat unclear, but I think the license's brevity and artistic merit (cough) make up for that.One flower becomes many.
Make your code free too.
Interesting idea, however they can't "infect" us merely by porting IE to Linux. Conversely, we can't "infect" them unless they are foolish.
...
If MS did release "MS Linux - All Singing, All Dancing and Whiter Whites" then I think they would come under a great deal of scrutiny which would (hopefully) prevent them from subverting the GPL.
Assuming they can't subvert the GPL, then if they wish to keep their code secret the only way they go is port their own set of libraries (and only link to LGPL libraries) and maybe produce a binary-only kernel module(*) or two. I imagine their stuff would only work on their own distribution if at all possible, though even that might prove difficult as a lot of people would try and reverse engineer it if they tried
* - this could/would become an issue the next time the kernel team changed the interface and everyone's MS Office installs stopped working!
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.
Not that I am an rabid supporter of the GNU license, but it seems that the questions, especially as worded, is flame bate on this forum.
If you want to eat, you have to write some software that is so hard to use, that it requires significant documentation. Then you can sell that documentation. You first have to develop some evangelical devotee's to install the software en mass, so that people will need to buy the documentation.
Or you could just make it hard enough to use that people need to call you for help. Then instead of writing software for a living, you can write once, sell support for ever.
But never mention selling software with closed source code here, it is almost a certain death sentence. How dare anyone make money for their efforts.
Because, lets face it, once you have free speech, you have free beer. No matter what license it is under, if I can download the source, and compile it, why pay for it.
The AL certainly doesn't purport to stop you from adding your own extensions. And if you do that, it certainly doesn't tell you under what conditions you can or cannot distribute or charge for this work, nor does it say anything about whether you must provide source for your own work. (Actually, it says that it doesn't say that. :-) That would be wicked because it would mean trying to exert control over some other software besides the original; that is, stuff that whoever issued the licence didn't themself write. I don't even know whether it's legal, but it's certainly not programmer-friendly.
As I dimly understand these matters, Larry just doesn't want you to write something and then pretend that it was Larry who really wrote it. I don't blame him, and I'd be surprised if anybody did. I doubt you'd want somebody other than a legitimate owner of that name putting "written by [your name here]" all over their own software.
fraud, not about restricting anybody's freedom. I hardly see these two matters as alternate faces of the same issue, but perhaps some people do.
If you intend to make your software as useful as it can be to as many people as you can, then you should make it free software. Which is a terrible word, because of word games from the FSF. I mean free as in "gift". As in "free of restrictions" or as in "no strings attached". There are plenty of licences out there that do this. Short licences are better than long ones. The best license is "do as thou wilt".
Here's one that's been floating around:
And here's another:As you see, a free licence is simple, to the point, and generous. It is not an insidious imposition of your person moral choices upon others. If you decide their choices for them a priori, they can make no moral decision. There is no goodness in being automata. You must let people choose for themselves.
Some people prefer to install poison-pills in their licences. Usually, this poison pill is about using the software to make money with. Sleepycat Software has that, the GPL has that, and so do lots of others. I suppose some selfish people have good reasons for this, but let's not be pretending that software with a poison-pill in it is somehow "free", or that it does the most good. It doesn't. A selfish poison pill tries to make sure that the original authors' socio-economic-political dogma gets spread through the world at the cost of helping fewer people. "Use" licences like this hamper code reuse and hurt programmers. A gift, on the other hand, comes without a price tag on it.
Every author has to make up their own mind here. I personally prefer software freely given away--without restrictions, without legislated morality, without poison pills, without any agenda beyond trying to help to make the world a better place. The AL seems to do a good job at that.
Try, please, to remember what the greatest gift of all is. If you know what it is and why, then you'll understand. If you do not, then I'm not sure I can convince you. But the answer is charity.
For some projects that I have written, I used a modified Artistic License, a "General Artistic License".
Parts of the Perl Artistic License seemed to me to be specific to Perl, so I removed them.
If you have time, look at it, and tell me if its ok.
http://www.dma.org/~dma hurin/files/software/wkn/doc/LICENSE
Of course, there are ways around that, effectively converting the GPL into the LGPL as applied to libraries. Better not to use the viral version in the first place, though.
OK, the big Free Software licenses are: GPL, LGPL, Old BSD, New BSD, Artistic and X Consortium. All of them allow the author to release the software under a proprietary license. The author can do anything they want with the software. All of them assert copyright and require that copyright be included when redistributing the software. The differences boil down to: additional restrictions, advertising and linking to software under other licenses.
-> The New BSD license and X Consortium license allow additional restrictions, and linking to anything. I see no functional difference between the two.
-> The Old BSD license is the New BSD license plus the advertising clause. It (and the many unique BSDesque licenses derived from it) are the only ones which requires notice during advertising, so I won't bother mentioning each one that has no advertising clause.
-> The Artistic license prevents additional restrictions (i.e. relicensing by others), but allows linking to anything
-> The LGPL prevents additional restrictions. It allows non-(L)GPL apps to link to it, but it's unclear whether or not it can link to non-LPL libraries.
-> The GPL prevents additional restrictions. It also prevents linking to software under any license that doesn't meet very strict requirements, which the GPL, LGPL and X Consortium license definately meet, the New BSD license probably meets, but few others do.
Thus the Artistic license does not allow switching to a proprietary license any more than the GPL does. What it does allow you to do is develop Free Software in a proprietary world. Free software developers on Windows should consider it, as many libraries and tools there are proprietary, and Artistic offers better protection than, say BSD. Also, Free Software developers developing for Qt and/or KDE should consider it, as it works very well with the QPL, with no arguments from GPL developers.
----
----
Open mind, insert foot.
You are right, but not for the reasons you gave. Microsoft is bound legally by agreements from their transaction with SCO regarding Xenix. They cannot sell a Unix operating system and therefore have a vested interest in the success of Windows. They have had IE ported to Solaris for quite some time now. They have enough capital and enough good minds there to crank out a Unix/Linux/whatever port of any app very quickly, they choose not to as it would not be in their best interests.
"Cause there's 40 different shades of black, so many fortresses and ways to attack, so why you complainin'?"
The problem with the BSD and the Artistic for me is that I'm not interested in facilitating someone else's proprietary software without getting something back from them - I am only interested in sharing with people who give me the same rights that I give them. I can still make my own proprietary software with my own work, because I hold the copyright and can issue my work with any number of licenses. If I want to use someone else's work in proprietary software, I can buy a license from them, just as I can sell a license to other people who want to make proprietary use of my work. This is hardly anti-commercial. In fact, you could say that the GPL is neutral regarding proprietary work, because it allows you to buy and sell separate commercial licenses and do pretty much what you'd do with conventional software licensing if you wish.
Thanks
Bruce
Bruce Perens.
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.
So "Let's work on a GPL Napster/javac/VMWare/X/..." comes up a lot, but "let's make a GPL Perl" hardly makes any sense.
He missed the point entirely.
These are not "loopholes". They are permission to make your own ethical decisions.
Larry Wall has a strong belief that people must be allowed to make their own ethical choices. He will give away his code, because this makes him happy. He does not expect you to feel obligated to him by this. If you are obligated to anyone, you are obligated, in his words, to the Author of his story.
Don't like it? Don't use perl.
I think Perens has made a totall ass of himself. "use of Artistic waning"? Perl is still out there, and doing quite well. And, personally, I think Artistic is the best of the licenses.
:)
Don't let the fact that you don't want to allow people certain choices blind you to the fact that allowing them those choices isn't a "loophole".
GPL is a demand letter with a court date; Artistic is a polite request.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
Section 5 prevents other people from charging a fee for your work, not you from charging a fee for your work. The idea is to prevent someone just packaging it up and selling it without modifications.
Matt. Want XML + Apache + Stylesheets? Get AxKit.
Suppose programmer A writes a program. The program is still in alpha, but when it becomes complete, programmer A plans to market it.
Since programmer A has other things to do, and the program is already somewhat useful, he releases the program under the GPL, so that others may benefit from his brilliance.
Programmer B finds a bug in the program and fixes it, following the GPL and releasing his bugfix to the code under the GPL.
Now, if programmer A wants to release the final version, he either has to 1) find another bugfix to correct the problem, or 2) convince programmer B to release that bugfix to programmer A under other terms than the GPL.
Programmers C, D, E, and F all find additional bugs and submit fixes, all under the GPL. At this time, programmer A would either have to find alternative solutions or else convince programmers B-F to release their changes to him under terms other than the GPL.
As those who understand statistics and human behavior, the chances that programmer A can either convince all of the other programmers to release those changes to him or have enough time to rewrite his code so that it neither contains the bug nor includes GPL fixes--approaches zero.
GPL has effectively "poisoned" the development of the product. Programmer A dumps the project in disgust and resolves never to use the GPL again. Programmer A has just lost his time, efforts, and an idea for a project which is now polluted by the GPL.
Some enterprising programmer *might* pick up that code and reuse it or fix it. But it is unlikely that the code will reach anywhere near what it could have been, had programmer A not dropped the project.
The bottom line is: if you use the GPL, you're stuck with it. It locks you into that licensing scheme, and unless you have the time, energy, and will to completely rewrite a piece of software released under the GPL, you will lose control of your idea and your software, even if that was not your original intent.
-CD76
Good luck getting permission from Oracle. Do you really not understand the problem?
You write: 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.
You're over-simplifying things. For trivial changes, yes you're right, but for non-trivial ones it's as likely as not to be impossible to integrate the changes back into the original tree. For example, some idiot could reformat the entire package to his preferred style when he grabs it to make changes and then publish "his own improved" version. And even if such pathological modification hasn't happened, why is the onus of back-integration on the original author? His time is better spent on continued development rather than on tracking code forks.
The GPL is generally good, in my estimation, except in the single area of code forking guidelines: namely, it doesn't provide any. At the very least, it should state somewhere that public forking is discouraged when the software is still in active consensual development by the primary author or group.
Currently it's only because of the goodwill and commonsense of the community that we don't have a forking nightmare on our hands. The GPL ought to enshrine that commonsense in its preamble.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
You can't steal something that's free.
What you write is yours. What I write is mine. And I can do whatsoever I please with what I write. I choose to make it a free gift. I don't care what others do with it. That's not up to me. If it were, it wouldn't have been a free gift.
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.
A Government Is a Body of People, Usually Notably Ungoverned
As long as you did not change the license on the part that is mine, sure. And you, as the author of the package, are perfectly free to do this.
I would encourage you to make a note in your distribution that you have done this, though.
A Government Is a Body of People, Usually Notably Ungoverned
Once more: YOUR CODE IS GUARANTEED TO REMAIN ALWAYS FREE. The GPL is not the way to make that happen. The BSD licence does that, too, but the GPL does something else.
The GPL is a way to immorally coerce others into making the choices that you want them to make. The LGPL, being non-infective, is much less evil.
Remember that there are many ways to avoid GPL'd libraries, too, so the library might was well be LGPL'd. Notice how the bc program is handled on OpenBSD. It manages to use the GPL'd program without contamination.
If you give something away, it is free. If you tell them what to do with it, it is not. Free is better.
Uh, I forgot that they can't sell a UNIX variant (because, apparently, of an agreement with SCO) That might also have something to do with it.
Daniel
Hurry up and jump on the individualist bandwagon!
Bzzt. Thanks for playing.
3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2
above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above
on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing
source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on
a medium customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for
noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b
above.)
Therefore, you can charge as much as you want for the binaries, as long as you make the source available seperately for free.
Glückwünsche, haben Sie Slashdot ermordet, indem Sie zum korporativen Druck beugten und Subskriptionen einlei
Your argument is pure sophistry. I don't care about angels dancing on the head of a pin. The reality of the matter is that this is a royal pain in the posterior, and no weasel words are going to change that. It's unnecessary, and unbecoming in a free gift.
Now how did I know this would be yet another license war? :)
Now let me say something that seems to be very misunderstood. I am a free software advocate. Now, most people who like free software have nothing against using software under the BSD, X, AL or any other free software license. The important part is that it is free, that is the rights of redistribution, modification, and use. Free Software does not equate to GPL-only.
Now when you are developing things are different. A lot of people don't want to contribute to propietary software. Just as many propietary software developers don't want their code to end up in free software. There are also people who want their code in either free or propietary software. Hence the copy-centered (thanks for the word, some AC) licenses. Now copy-centered software can be either copy-lefted or copy-righted (turned into propietary software I mean in this context). The problem is, when either happens, the code gets stuck. So you end up with at least three forks eventually, a copy-lefted that always demands complete openness, a copy-righted that always demands complete closedness, and a lesser copy-centered fork that continually gets sucked into the other two.
The real irony here is that you'd think that authors of copy-centered software wouldn't care about what license is used. Yet there are advocates everywhere.
My main point here is that the user should only be concerned that it is free software he using. I, for instance, will have no problem using KDE 2 and qt 2. If it is great software then I will use it because it is free. But the developer of that software is the only one who may choose the license. Contributers remember must choose to reuse the developers code. Just as I may choose not to develop qt because of the restrictions in its licensing. There are many people who do not mind the restrictions and code it any. Since qt is not the only choice, it is not a huge problem.
But remember folks. The issue is freedom. There is nothing morally or ethically wrong with any free software license. Remember, developers must reuse his/her code.
If I write a shell script that calls out to getopt(1fsf), that shell script is still my work, and their virus has no hold upon me. The FSF will be quick to agree to this.
Now, if I write a program that links to readline(3fsf), it is certainly my work.
I know this. You know this. Even the FSF knows this. But then they realize that they're about to let the cat out of the bag, so they backpeddle. They try to pretend that the foofunc(1fsf) program doesn't infect the calling program or script, but that the equivalent foofunc(3fsf) does. That's where they screw up.
When I use foofunc(3fsf), they would really, really like all the world to believe that they've now infected me, that they get to tell me what I can and cannot do with the software I wrote.
Guess what? That's bunk. They haven't infected me. I'm merely using a library function in the way that library functions are meant to be used: they're an API, and you link to them. It is of no consequence whether it's statically linked at link/load-time, dynamically linked at start-up, or accessed at run-time during execution via any one of myriad forms of RPC. It's API only, not material inclusion. APIs aren't viral.
This is really no different than the situation with the Linux kernel: its GPLness doesn't infect privately-held commercial device drivers linked against the kernel. This is good. Sure, it pisses off the FSF (read: Stallman, as with nearly any reference to the FSF). But so what? Lots of things piss him off. Tough. Linking to drivers like this only makes Linux more useful to more people.
BSDI found this out a long, long time ago. They wanted to completely open source, but couldn't get the drivers they needed that way. Vendors refused, important vendors whom they really needed. So they made an exception. I think folks have forgotten that lesson.
The FSF pretend not to try to control an API. They pretend not to try to control fair use. Very well. These false pretenses are a two-edged sword. Nice people don't play with knives, but since they're waving theirs around, so be it. It can cut them, too.
Most Linux operating systems ship with all of these various functions, like strlen(), getopt(), or readline(). It is ludicrous to believe that some infect and some do not. It's complete hypocrisy with no basis in reason. Libraries are for using. You can't control use through copyright. No copyright will let you require someone who buys your book to shelve it only with other books you approve of, or to read the book only under a full moon, or to stop you from reselling the book at a used bookstore.
It was this that this hypocrisy that inspired me to expose the fact that libraries cannot be infectively GPL'd, because that's trying to use copyright to dictate use. Thinking of the issues of getopt(1fsf) and getopt(3fsf), I as a simple demonstration, liberated readline from its erstwhile nonfree state.
And there was much rejoicing.
No, really--there was. I've received a good bit of joyful mail for this blow against tyranny and for freedom. I don't think it was as heroic an act as the mail often phrased it, but it was something that definitely needed being done. I also learned that at least two (and I think three) other implementations exist, so it's all water under the bridge now. You've an API you can link to freely. Enjoy. That's what freedom's for.
People needed to see that you cannot control employ the GPL to dictate use of libraries. And you shouldn't want to. That's not free. That's coercive. Be charitable. Set your software free.
Think about it. Microsoft has spent ten years copyingApple, which has now gone to a *BSD with macos/X. Do you really think ms will make a separate decision *this* time? A different *BSD, perhaps. Linxu? why on earth would they do that?
Take, for example, Enlightenment.
Do any of those libraries contain the FSF's poison pill? You bet they do! Now, with E, it's not a big deal, but what happens if Netscape or Adobe Acrobat or Word Perfect or any other provider of commercial software links with one of those, not realizing that they've just screwed themselves beyond belief?Very bad things.
We end up with a vendor who gets burnt by free software. Beautiful. Whether we have a court battle or a vendor withdrawing their product, or both, this will be the Kiss of Death.
What can be done? Here are three pro-active suggestions:
- Have the FSF make a blanket statement that the GPL on a library does not infect the resulting executable through mere use of that library, as many of us already maintain.
- Create condoms for all the currently virus-carrying libraries.
- Change the build process and the libraries so that a loader error is produced if you accidentally generate an infected binary without having specified some option that says you don't mind that. For example, if the default were to tolerate it, you could create a gcc --free flag to blow up in case something viral were used. On the other hand, if the default were to complain (as I believe it should be), you could create a gcc --viral flag to not blow up if you accidentally created a viral library.
Good luck with any of them.You have discovered a very, very important point, and that unless we want to see Linux die back to a niche system without any commercial software available for it, that this issue must be addressed, and as soon as possible.
Gee, I simply can't imagine why people think they're a cult. :-)
"I would be pretty pissed (mostly out of jealousy and greed) but damnit I would have every right to be, they used my work to make their money and I am not getting any cut of it. First of all, that would be shitty of someone to do that, but you gotta realize that people are evil, so someone would."
I'm glad you used the terms jealousy and greed. Nothing to be too ashamed off, because none of us are perfect. I might even feel the same way if it happened to me.
However, there is nothing wrong with earning a living. The usual course of doing so involves trading what you have for what you want. It is perfectly natural for a developer to use his development skills to earn a living with. He creates a cool game program and trades it to gamers for money.
Now why did he use your 3D toolkit instead of forking over hundreds or thousands of dollars for a proprietary one? Easy. You already said your toolkit was free, free and in free beer and free as in free to use. Nowhere in your license did you say "you can only use this if you write free programs." If that was your intent, then make your toolkit under the GPL. But by putting it out under the LGPL you are explicitly giving the game manufacturer permission to make money off of it.
Instead of getting jealous of the game designer, you might think instead of how cool your toolkit really is. After all, with only a "very thin" client program gamers from all over paid good money for it. Maybe you should consider writing your own game with it and selling it. After all, who better than the toolkit creator to write the perfect game for it.
A Government Is a Body of People, Usually Notably Ungoverned