Slashdot Mirror
Changing the Software License?
plaa asks: "I was wondering what it would take to change the license of some software. Is it enough if all the authors accept the change or do the licenses have to be 'compatible'? Does this affect the older versions of the program in any way? What if somebody has already used some code from the program in a program of his own? How easy would it be to migrate software to it (so that the older version was not an option to the user)?" What, in particular, do users and developers have to worry about when something that once was free, becomes commercial?
Keep in mind, every patch you receive is by default a modification to your original program and (unless otherwise specified) is released back to YOU under the GPL. This means that YOU cannot redistribute that piece under any other license at a later time! Because you are now bound by the GPL yourself.
If you get that person to release it back to you under multiple licenses, or even give up all rights for the patch back to you, then you may be able to change the license. But you have to be careful to do this for *(every)* patch received.
Assuming you took all precautions and had all contributors give up rights (or release it back to you under the BSD license AND the GPL) then you may turn the latest release into a proprietary release. (Do you really want to attempt to screw over all the internet friends who patched your code? well, thats another debate all together) But there is absolutely no way to reclaim all previous releases of the program.
This is in fact one of the reasons the GPL was designed, to keep software open. If you stop providing the source for your GPL program and release it under a proprietary license, more than likely you will force a split in development. Someone will continue developing the "free" version (based on previous GPL releases) and you will head down the proprietary software path. The only problem is this... it's now just you against an army of programmers on the internet. :-)
The moral of the story? Don't leech off of the world of free developers then expect to reap the profits. :-)
--Twivel
One of the major reasons that hackers use the BSD style licenses (as opposed to the GPL style licenses) is that it allows people to create proprietary versions of the software. If that is part of the original goal of the project then I can see why it would be annoying to have to contend with people adding pieces to the software that are licensed under the GPL.
The Linux kernel is a good example of why BSD advocates have a hard row to hoe. There are huge parts of the Linux kernel that were "borrowed" from one or another of the BSDs, and now find themselves under the GPL. The sticky part is that now that this code is under the GPL it can't be used in BSD style projects without tainting their code (and causing it to fall under the GPL).
In this manner GPL code is far more dangerous to BSD codebases than proprietary code. Proprietary code simply borrows code, GPL code not only borrows code, but it oftentimes borrows Open Source developers as well. Much of the work that is being done by Linux developers can't be used by BSD developers unless they are willing to use the GPL style licenses as well.
I understand why this would be annoying.
However, to many people the politics behind the GPL are very attractive. They aren't concerned about the rights of people who want to make software proprietary, and they want to make sure that their contributions remain open. If the BSD advocates really have a problem with the GPL then they should release their software under a license that didn't allow it to be co-opted by GPL hackers. What you need is the anti-GPL.
In the meantime, you can't hardly blame the GPL advocates for feeling strongly about their politics. You feel strongly about your politics, don't you?
It gets even more exciting when you take into consideration software written under licenses similiar to the BSD style license.
Basically these licenses allow you to change the license that you release derivative software under as long as you give them credit for the software you are borrowing. This not only allows for things like the BSD TCP/IP stack to be used in Windows, but it also allows for GPL hackers to "borrow" BSD code, make a few modifications and release the derivative under the GPL.
For some reason BSD advocates don't mind it when their work becomes proprietary, but they tend to hate it when their work becomes GPLed.
Go figure.
For instance if a program was started and copyrighted by an individual and put up on a web site under GPL for interested parties to contribute code with the understanding that any code contributed becomes property of the copyright holder.
Then this license wouldn't be the GPL. And it would still mean that the snaphot of code initially released (ok, minus any improvements submitted by users) is still freely distributable.
Additionally, it is doubtful that such a license would stand up in court. In existing copyright law the nearest comparable example is the relationship between writers and editors. This case law has shown that there is a very fine line between providing editorial support (small changes to improve readibility or clarity or spelling and grammar) to becoming a co-author. So if you were to incorporate a function submitted by someone else they may in effect become co-authors and have equal rights to the intellectual property.
"God fights on the side with the best artillery." - Napoleon, Marshal of France - speaking truth to power
"God fights on the side with the best artillery." - Napoleon, Marshal of France - speaking truth to power
IANAL either, but GPL only applies to distribution. You can patch all you like, you can compile all you like. You can't give it to anyone else, though, under any license due to the conflict between GPL, and ISO.
People, get this through your heads: There is NOTHING in the GPL which says that if you mix GPL'd code with non-GPL-license compatible code, that you cannot USE the result. What it DOES say is that you cannot DISTRIBUTE the result.
Otherwise, you wouldn't be able to use GPL programs that were compiled with commercial compilers and linked against commercial libraries. (Redistributing those binaries, of course, is a different issue.)
--Joe--
Program Intellivision!
This is not correct. None of the work of AT&T Unix was in the public domain. What BSD did was to effectively rewrite all of the code. Bad things started happening when they tried to change the requirement for an AT&T source lisense. Lawsuits and the like, which were settled in such a way as to remove the offending intellectual property of AT&T.
Once a license is granted, it cannot be revoked unless there's a revokation clause.
New versions of a product can be issued under whatever license the copyright holders want.
It is very tricky to argue against complex clip-wrap licenses that would be allowed by UCITA, but support licenses such as the GPL (basically a click-wrap).
Are you a copyright holder? If yes, you have a problem. You will need to get Wine to remove your code if their new license is not acceptable.
If you are not a copyright holder then tough beans. Submission of small patches does not make you an owner. This is not the stock market, you do not get a share of the ownership. If you submitted larger pieces of code and neglected to include your own copyright statements on them, then you have only yourself to blame.
A Government Is a Body of People, Usually Notably Ungoverned
I think you misunderstood me. BSD authors have no problems at all with GPL authors using their code. They have a big problem with people attempting to subvert the copyright.
But the key word here is "use". If all you do is fiddle with a few bytes, you can't relicense it. It's not a separate work. It's against copyright law. The BSDL does not grant users the right to relicense, only sublicense. License your work as a whole under the GPL, but keep the BSD license intact with the BSD source code, as required by the BSDL.
A Government Is a Body of People, Usually Notably Ungoverned
You are correct. It is a very good idea to reject any bugfix patches that contain their own copyright notice. For any contributions that are larger than this, the author should contact the submitter and request that rights be assigned before it gets rolled in.
A Government Is a Body of People, Usually Notably Ungoverned
If you don't want to assign the rights away to your bugfix, perhaps you should think about forking the codebase. After all, if you don't want your code held hostage by the author, perhaps he doesn't want his held hostage by your bugfix.
A Government Is a Body of People, Usually Notably Ungoverned
The copyright holders can license under any terms they like. If there are mutliple holders, agreement would be needed between them.
Of course, rights granted to others based on previous licensing cannot be taken away.. but the license for future versions could be changed. This is perfectly within the rights of the copyright holders themselves.
The GPL doesn't force people "borrowing" your code to release their modifications to the world. It's only that if they distribute the modifications, they have to provide source. But if the modifications remain in a closed circle, so can the sources of those modifications.
-- Abigail
Well, no, they can't. Sure, they can take a copy, make a trivial modification to it, and make that proprietary, but so what? They can't take away the license on what's released, all that code is still available. Red Hat BSD cannot remove code they don't own from the available pool of code. If the modifications are insignificant, who cares whether there's a proprietary version? If the modifications are substancial, with lots of new features, you would be better off if the proprietary stuff was open, sure. But if the alternative was no new features, you are off worse, as you have less choices.
-- Abigail
Well, in theory it's simple. If you made it, you own it, and you can release it and re-release it under as many licences as you like, whenever you like (though of course you can't unrelease any open-source code).
However, when others modify it, they own those modifications, so in theory, if you want to base a proprietary product on an open-source product, you have to secure the permission of the author of every modification.
Here's where it gets tricky: if you can't contact (or secure the cooperation of) all the authors, you can recreate their work. You are free to read their code and use the ideas. But here the line between copying and recreation from ideas blurs.
Say you release a GPL'd program and someone fixes a for(i=0; i<limit; i++) loop to
for(i=0; i<=limit; i++) and this cures a boundary condition bug. What kind of copyright hold do they have on the insertion of a single character? Should you delete the '=' and reinsert it? Would even that be legal, or would you have to express it differently? (this is the minimal example, but the issues are essentially the same for all true bug fixes)
I don't have any answers as to how this would work out in court, and I suspect nobody else does either (I'd happily be demonstrated wrong, though). Copyright was not designed to protect the formal specification of mechanisms, and doesn't really deal very well with multiple holders with dramatically different levels of contribution anyway. It certainly wasn't designed with anything like the GPL in mind. If anyone can come up with a relevant legal precedent (either from the software world or, say, when a proofreader or editor claimed copyright on fixes or other changes he made to a story), I'd be very interested.
IANAL, TINLA
You can do anything you want with 10 lines of code for the same reasons you can do anything with an excerpt out of the paper or a book. It's called fair use.
If you write a 4-line memory compression algorithm - it's just that, an algorithm. There probably wouldn't be that many ways if any to rewrite it. You'd have better luck protecting it with a patent.
10 lines is just a guideline I've heard over and over. There is, of course, no clear definition of fair use in the US, and recent Congresses wish to keep it that way. Check http://fairuse.stanford.edu/.
I am not a lawyer. This is not legal advice. Consider it a list of questions that you should have answers to.
First, unless there were specific provisions in the original license that would allow it, you won't be able to impose a new license on existing users. The obvious choice is to grandfather them, allowing them to continue to use the version they have under the old license.
Second, you will need the agreement of the authors in some form. The FSF handles it by getting copyright assignments from contributors. As the copyright holder, they can then act alone. For small changes in the license, especially those that would make a free software project freer, you may have little problem.
Finally, if the copyright holders are okay with it, you can offer the user a choice of multiple licenses. Perl, for example, can be used under either the GPL or the Artistic License.
The net will not be what we demand, but what we make it. Build it well.
I was just at a GeoTrain (Global Knowledge) class for Cisco certification, THEY HAVE REDHAT CERTIFICATION CLASSES ALL OVER THE US. Sylvan does the cert. so what is the big deal. $5000? no problem, a CCIE cost $25,000 with classes (no joke) with only 3,000 CCIE's in the US the 1,500 RHIE's does not look bad at all. The MCSE is worthless 'cuz anybody and there brother can pass it, and have. IT companys want us to have some letters and numbers behind our names that help them sell product, but dont help us sell our carreirs. I just wish they would make a spell checker for HTML forms :P
Is it then possible that the program forks, in the sense that you have:
1. Propriaty code with all recreated bug fixes;
2. GPL code
both on continues base?
Can't the community keep on supporting the GPL'ed versions then?
Bizar technology?
Actually, one of the very nice things about this is that changes in the license this way work like a ratchet; they can make things more favorable for the licensee but never less favorable.
Suppose, for instance, that I license my software under GLP 2.0 or later. A few years down the road, RMS sells his soul to Satan and releases GPL 6.6.6 that requires you to send your firstborn to FSF in order to use any software licensed under it. Users of my program are still perfectly fine, though, because they retain the right to license under a version between 2.0 and 6.6.6. OTOH, if the courts find some flaw in 2.0 that prevents licesees from doing something that they want to do, they can still use the hypothetical 3.0 that repairs the hole that the court found.
Of course, this isn't actually limited to the GPL. The Perl license, for instance, lets you license under either GLP or Artistic License- and you don't actually have to choose or tell anyone which one you're licensing under.
There's no point in questioning authority if you aren't going to listen to the answers.
See Wine Hq. The license on Wine just (is in the process of?) changed from GPL to BSD to fit the goals of Wine better.
First of all, all old GPL code is still GPLed. They simply contacted all the authors they could find (and in fact gave them some time decide) Results were about 95% in favor, 2% opposed, and the rest unfindable. The 2% of coders were deemed insignificant in that it wouldn't be too difficult to re-code their contributions. The other will probably end up re-coded eventially if the authoers cannot be found.
There are pros and cons to all licenses, please do not get into an argument of should Wine have changed. They did, and unless you contribute code you have no voice in the change. The topic is can it be done, and obviously they have proven it can. If you want to do the same things read their archives, there is no point in repeating mistakes they made.
For this one there is a short anser and a very short anser.
The short one is that if you can get hold of every single author and they all agree to the new license it doesn't matter what the old license or the new license are. The change wold happen. This happened with KISDN when the authors changed from GPL to a proprietary, per user, per CPU etc... license. Latter after seeing how small the market was and that others wold simply continue building the GPLed version they switched back.
However the change wold have no effect on already released software. If you release something the depends heavily or lightly on a piece of Free Software then the free software is relicensed as something you can't use ( I.e. from LGPL to SCSL ) you must either start from scratch or consider the free code abandoned and find a new maintainer for it ( yourself if you can handle the extra work ).
As for proprietary work going open source that is even simpler. When you work for a company and collect a salary you are essentially selling them full rights to any code you write on the job. If at any time for any reason they feel the need to change the license on that code they don't even have to consult you. If you no longer work for them you will have to here about it on SlashDot just like the rest of us.
The very short anser is that; Yes, the authors can change without contacting anyone who didn't write code and that wold not be retroactive in any way.
--= Isn't it surprising how badly I spell ?
Note: IANAL. Do not consider this legal advice.
Yes. Patches in excess of 10 LOC are copyrightable (and thus under current law implicitly copyrighted) material. (the 10 LOC is a matter of legal precedent)
Yes. See above
... nothing ... I don't see the problem there.
I believe you misunderstand the nature of GPL "infection". What you end up with is a compound work carrying the copyrights (and respective licenses) of _both_ copyright holders, each retaining copyright on the portions of the work they contributed. No license is changed.
If the licenses are compatible (e.g. not contradictory -- this is the case with LAME and the ISO encoder), you're fine. If not, you just have a compound work that is illegal to distribute.
Under copyright law, you have no rights to do anything with a copyrighted work except those explicitly granted you by the copyright holder(s) through licensing, and those rights granted you by law and legal precedent (i.e. fair use).
Therefore, if the "compound license" is "impossible" (self-contradictory), then you have no license, and thus no legal right to redistribute the compound work.
It is certainly possible and legal to make a patch for the Linux kernel under a proprietary license, but it would still be illegal to distribute a Linux kernel (in source or binary form) with the patch applied, without prior permission from the copyright holders of the Linux kernel (which in practical terms would mean you being given a copy with a license other than GPL to have your way with).
DNA just wants to be free...
This is a FAQ, and a well-documented FAQ.
As the owner of code, you can do whatever the hell you want with it. Period. You can give it to one person on the condition that he may only use it on nights of the full moon, and another under the GPL.
Of course, you can't *stop* the person who got it under GPL from giving a "less-restrictive" copy to the guy who got the full-moon license...
Anyway, this is silly. Users can continue to use the "existing" code under the license they got it under, developers can continue to use the old code under the old terms, and anyone who wants the new stuff can get it under whatever terms the author wants to give them.
Nothing tricky at all. You get something, it has terms, you're under those terms for that thing forever, other things (or even the same thing) may later become available under different terms.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
I don't mind at all if derivatives are under the GPL. But I do get annoyed when the only reason you put it under the GPL is because you have a political disagreement with my license.
A Government Is a Body of People, Usually Notably Ungoverned
If all the copyright holders (i.e. ALL the authors) get together, then they can decide to make a non-free version of the program, since it's their property, under ANY license.
But as the number of authors tends to infinity, the difficulty of doing this, even if the others are willing to re-code the "non-content's" work, becomes too great to be practical. Some fraction of the authors will object. So sendmail, the linux kernel, etc. are probably safe.
On the other hand, Mozilla intentionally isn't safe, neither is anything done under Sun's "Community License", or anything under the old X license. This is because those licenses intentionally allow the license writer to allow or make closed binaries that may be derivative works.
The idea in Mozilla's case is that Netscape/AOL/Time/Warner can make and fork their own proprietry browsers and sell them based on your improvements. On the other hand this is not such a bad deal, because by far the greatest part of the code is theirs anyway, and they're giving it to us to play with for free.
The BSD license is also slightly suspect this way, I think, but the real-world risk of it happening with any major project approaches zero (I hope).
However, the upside is that once an open source licensed piece of code is out there and mirrored widely, that version at least will always be there, propagating through the general population. So the effort to fork will only work if the proprietry system is *much* better, which is for well known reasons unlikely.
Go see ESR's work on this stuff at tuxedo.org. Its good and clear.
IANAL.
Here's my question. Can licenses be applied to patches?. One good example of this is the LAME Encoder. A little more background for those who don't know what it is. There is an ISO-based mp3 encoder, along with source code, that is freely available for download. The source code though, is heavily broken in many places, and the sound quality of a ISO-based mp3 encoder is very subpar compared to the commerical mp3 encoder of Fraunhofer, one of the leading companies behind the technology of mp3. However, Fraunhofer owns a lot of patents to the methods behind encoding mp3, so a couple of years ago, they decided to send legal threats everyone that offered a compiled version or modified version of the ISO-based encoder.
LAME, according to the homepage, is "not an mp3 encoder. It is a GPL'd patch against the dist10 ISO demonstration source. LAME is totally incapable of producing an mp3 stream. It is incapable of even being compiled by itself. You need the ISO source for this software to work. The ISO demonstration source is also freely available, but any commercial use (including distributing free encoders) may require a license agreement from FhG."
Here's my point - are patches covered under the GPL (or any license?). If yes, what's going to stop someone from creating a Artistic license patch for Linux the linux kernel? Or a Sun Community License? Or a completely proprietery license? Remember, what LAME does is GPL-infect a piece of code that is has no copyright on, simply by patching it. By extending this analogy a little further, you can see that there is no real need to respect the original author's copyright, since you can just patch his source code with whatever license you got.
So, the answer is yes, you can change the license - it's all too easy. But should it be this way?
A software liscense grants users the right to use a piece of software in a specified manner. Once granted it can't be taken away. There is no way to remove the rights a person has already been granted by the copyright holder. Subsequent releases need not be released under the same terms. A case in point is the 'commercialization' of UNIX by AT&T. All prior work remained in the public domain and became BSD unix.
Many complain about the GPL's restrictiveness, but it is more flexible than most other licences in one crucial way. The standard license which most people apply says:
In my opinion, this is one great, saving feature of the GPL; if at some time the FSF decides that the license needs to be changed, they can affect so, so many pieces of software in existence.
While many may feel that giving this sort of licensing power to the FSF is a bad thing, there are many of us here who feel that the FSF has good intentions, and will appropriately yield the power to release our code in a good manner if we pass on.
I asked the FSF about this one a little while back and it applies to all licenses.
Unless you sign away your copyright for a license, the work is, and always will be, yours. The license only tells *other* people what rights they have.
If you aren't the full copyright owner, you MUST get the other author's permission. Once you have that, you can change the license without worrying about legal stuff. I'd recommend you get it in writing if you have physical contact with the other authors.
This is how people can release source code under multiple licenses. There's nothing stopping you from releasing something under the artistic license, the GPL and having a closed source version at the same time!
In short: if everyone agrees, everything is A-OK.
æeee!
By default, everything copyrightable is Copyright The Author, All Rights Reserved. Licenses are just contracts to grant you, the user, certain copy rights (like the right to install it onto your computer or put it on an ftp site).
You can hand out as many of these contracts as you like, they can all be different, and you can change new ones that you hand out, but once you give someone a license to do something with that code, you cannot retract that license unless there was a termination clause in the license.
Free software licenses are kind of unique because they license everyone automatically.
So, say ssh was created and licensed to everyone under the BSD license. SSH Communications Security , the owners of this code, decide they can make money off of ssh, so they release it under a license that suits them. Anyone that had a previously-licensed copy of ssh is still free to do anything they like under the BSD license, including fork it into OpenSSH.
In order to prevent people from using the old code under the old license, you either have to terminate their license (using a termination clause already in the license agreement) or you have to make the old code worthless to them. Usually any progress in this direction is at the expense of your users and is considered evil. :)
If you are the author of foobarbaz, a shareware app for Linux, and you include code from other people's software (other libraries, etc) then you have to respect those licenses (i.e. releasing under GPL would be a bad idea) or reimplement those functions so that you don't need the other libraries. If it's under 10 lines of code, it's fair use to do anything with it (less than 10 lines of code are not copy protected, thus no licenses are needed). If your buddy helped write code for foobarbaz, and there's more than 10 lines, he/she has copyright over his portions and you need to ask permission from him/her first.
This is why the Netscape -> Mozilla transition had to rip out a lot of things like Java and RSA support.