Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
News

Changing the Software License? 100

Posted by Cliff from the decisions-decisions dept.
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?
This discussion has been archived. No new comments can be posted.

Changing the Software License? More

Changing the Software License?

Comments Filter:

  • Re:Licensing (Score:1)

    by Anonymous Coward
    I just stole the follow code from the Linux Kernel source and I am going to put it in a proprietary software package that's gonna make me millions:

    int i;

    BWAHAHAHAHAAHAHAHAHA just you try and stop me!

  • If all the authors agree, they can issue new licenses to people under different terms. But unless the original license has a unilateral termination clause, the original licensees can continue to abide by the terms of the original license on the original code.

    Thankfully, the FSF and other people have been mostly successful in discouraging Free Software with unilateral license termination clauses.
  • 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.

    That is simply not true. Yes, there is the odd bit, but there were never any "huge parts". The old ipfwadm code is the closest to an example, and that has been replaced (twice!) now.

    I suspect that there will be the odd ex-BSD driver, especially in the non-i386 ports, but otherwise, I think that your claim is rude.

    Matthew.

  • Sorry about that. It's been a long time since I paid attention to what's going on in the kernel space, and I am not a kernel hacker by any stretch of the imagination.

    The point I was trying to make is that GPL coders can freely borrow code from BSD codebases while the BSD coders can not borrow code from GPL codebases. I happen to know of several cases where the would _really_ like to (some of the file locking bits in Samba spring to mind).

    If I implied (even indirectly) that the Linux hackers relied on the BSD codebase to solve sticky problems please forgive me. I stand corrected.

    ipfwadm is a good example of what I was trying to demonstrate however. Due to the fact that Linux coders can use BSD codebases in their GPLed works there is nothing stopping them from borrowing ipfwadm until such time as they can come up with something else that they like better.

    This is a definite advantage that hackers who don't mind contributing to GPL projects have.
  • My computer must be malfunctioning. It shows this story as an "Ask Slashdot", not as news.
  • Two boundry conditions of interest...

    #1 What happens if a patch replaces entire program ? Who owns the program ?

    #2 What happens if a patch replaces one byte in the entire source tree ? Who owns the program ?

    I hope, answers are ALWAYS -- original owner.
    + part ownership to patch writer.

    If this is true:
    #3 what if you add a patch. now someone's patch
    removes all your additions ... Do you still retain
    part-ownership ? :)

    I hope answer is yes.

    BTW,
    #1 is an interesting way of donating your program's authorship :)

    - abhay
  • 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.
    Perhaps you could clarify the difference here? How is a proprietary developer not contributing to your code different from an open-source developer not contributing to your code? The legal theory is identical.

    I can see that there would be something annoying about the experience of seeing your code, with someone else's improvements incorporated into it, publicly available for anyone to use, but licensed in such a way that you can't use it yourself without modifying the terms of your software license; however, except for secrecy, this is true of proprietary code too.

  • If a Person purchased your software under License A then they follow license A until they die. But this continues! if they sell it to someone (I dont need this anymore, here dave.) That person now has that license. In fact your program can exist and be legally used for probably centuries as long as whoever is holding the license is abiding by that license. Now if your origional license had a "only joe blow can use this" where joe blow is the origional purchaser, or a "this license dies on 12/12/1954", or a "This license dies for any reason or at the whim of the facist programmer that wrote this" clause then you have no leg to stand on when trying to tell someone that they cant use version 1.0 of your program anymore. you cant revoke a license unless you put a revoke clause in it (Model yours after microsoft, they can revoke the license for any reason, or enslave you as Bill Gates towel boy.) Granted, consumers and companies are getting better.. the corp I work at has a special license with microsoft... we CANT be revoked, no revoking clauses exist, but then we pruchased a 10,000 user license, so we had the power of green. Basically if you are trying to take your older software from people you are screwed, and they can use it in spite of your tantrum.
  • Jason Earl wrote:
    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.

    Yes, but that is exactly what GPL-developers want: to protect their own code from commercialization by others. Allowing it to be put in the BSD kernel would mean it was no longer protected against that.

    For my part, I have always found the GPL more fair. I don't mind giving things away, but I do mind people misusing my gifts for their own profit, instead of giving something away to the world themselves.

  • I really don't understand where you get the idea that 10 lines of code or less are uncopyrightable/freely borrowable. Does that mean that me and a collective of say 20,000 volunteers can each "borrow" 10 lines of code from linux and devise our own proprietary kernel?

    No. You really aren't allowed to steal any code from a gpl'ed project, to my knowledge. It's just a lot of the code out there is so common that no one can rightfully say it's there. But if somehow somewhere i came up with a memory compression algorythim that was contained in 4 lines of code, doubled effective memory with an actual increase in performance and GPLed it, i'd be damn pissed if someone borrowed that for their shareware or commercial product if they weren't abiding by the terms that were set forth in the license.

  • 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.

    I don't think you can do anything you want with an excerpt from a book or a paper, though. Fair use allows you to quote for certain scholarly, artistic, or literary purposes, but it doesn't make the excerpt yours somehow, and it doesn't place the excerpt in the public domain.

    So you can take some FreeBSD code (for example) and publish it along with annotations as to how it works, etc, but I don't think you can just subsume it into your application as is. In the literary world, including a fair use excerpt but without marking it as quoted or including attribution would be considered plagiarism. In the software world this would probably be opposed under copyright grounds.

  • It depends on whether UCITA passes or not.

    No need to repeat what already been said at how bad that would be.

    I'm not sure how that would affect public licensing.

    Death to UCITA!!!
    Down with bad software
    Long live badsoftware.com
  • Remember Trumpet Winsock? It used to be the standard Windows 3.1 way to get onto the Internet. Because the creator (Peter Tattum) made no money out of of it (even though it was Shareware - no one registered it), and so after 2.1 he attempted to change the Copyright on it.

    This, amongst other things, led to the case of Trumpet v Ozemail (see http://www.austlii.edu.au/cgi-bin/disp.pl/au/cases /cth/federal%5fct/1996/560.html?query=%7 e+trumpet+ozemail). If you can get hold of a copy of a more recent version of Winsock, you will see a very strange non-Shareware licence.

    This new licence, and the fact that a free dialler was given away with Windows 95 rendered Trumpet Winsock a non-product.

    Change your licence at your peril. You can probably do it, but the GPL is the best.
  • You are confused. Red Hat does allow other people to "make money" from their code (and many people are attempting this; Mandrake Linux is an example of a branched-from-RedHat distribution). What they cannot do, is keep from releasing their modifications to RedHat's source code, if they distribute modified binaries. That is what the GPL requires.

    On the other hand, the BSD license (apparently) allows someone to make modifications and distribute the binaries, without releasing the source to their changes (as long as the original authors get attribution.)

    Hopefully that clears it up for you (assuming you weren't trolling).

  • Unless of course the license that you accept states that your use of the software can be terminated at any time for any reason by the owner which many commercial licenses contain a similar clause

  • Wine is moving away from their old wine license to the X/MIT license. The reason for doing this is that there were questions about the legality of the old license. They have chosen for the X/MIT license because that seems to be closest to their old license.

    You're right about the rest, of course.
  • IANAL, but:

    I think it is possible to put a patch like that under GPL. However, it will then be forbidden to actually patch the ISO code with it, because that would make it a derived work that can't be under the GPL. The GPL explicitly specifies that all derived works should be under the GPL, but that is in contradiction to the ISO license, so you just can't mix them. In short, this makes the patch legally useless.
  • I quoth from the GPL:
    ...
    These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
    ...
    (Formatting mine) I think his assumption 10 lines would fall under the nonidentifiable category is valid... if they are very special lines containing unique algorithms, that's different, however.
  • Incorrect.

    A license is like a contract, and if there is a termination clause, it can be terminated if the requirements are fufilled.

    Even more blantantly wrong is your UNIX history.

    AT&T and then Bell Labs after the monopoly was broken up has _always_ had UNIX as a commerical product. For tax purposes, educational institutions could get a source license cheap.

    BSD was, and still is with the exception of the Lite versions, dependant on UNIX source. Which is why you need a unix source license to get BSD (encumbered) source. (Although you can get one for personal use for free as of a couple weeks ago) UNIX never was, and still isn't, in the public domain.

    Moderators, shame on you for moderating up stuff that is incorrect :P

  • Because the CSRG didn't write their OS from scratch and instead
    started with UNIX, you needed a UNIX source license to get BSD.
    When they were preparing their final release, they had two versions planned:
    4.4BSD Encumbered (Which is like all of the other BSDs, source license required)
    and 4.4BSD Lite (Which had no UNIX source in it)

    Check http://www.sco.com/offers/ancient_unix.html for information on getting a unix source license for free if you can fufill some requirements.

    Yes AC, I know your knoweldge of UNIX history is sketchy :)
  • If I remember correctly from all the sources I've read, if the licence is BSD or X-ish, anyone can make a licence change to future versions. For GPL-ish licences, everyone who has contributed more than 20 lines of code to the program must agree to change the licence. However, /all/ licence changes apply only to future versions of the software. All versions out and under a licence must forever stay under that licence (hence OpenSSH)
  • There is no "line-limit" on software. If you contribute code, you are a "contributor" to the software. For example, contributing 19 lines to a 15 line program means you own over 1/2 of the code.

    --Twivel

  • #1 What happens if a patch replaces entire program ? Who owns the program ?

    There is no such thing as a patch that replaces an entire program. If that is the case, it is a completely new program and not associated with the previous one.

    #2 What happens if a patch replaces one byte in the entire source tree ? Who owns the program ?

    There is no limit to the size of a contribution. If you replace one byte you are a contributor.

    #3 what if you add a patch. now someone's patch removes all your additions ... Do you still retain part-ownership ? :)

    If your code is not within the main project, you are no longer a contributor. For example, if someone writes a GPL program, you contribute 5 lines to it. If he wants to release it commercially and you don't give him the right to do so, he must remove your code to do so.

    --Twivel

  • This post was off-topic. He was asking about contributions to something released under a particular license (the GPL). Not what the original auther can do with the program.

    If someone contributs to your product, it creates a derivative work including both yours and his code. Now he is a co-author. If your program was released under the GPL, his contribution back to you (unless otherwise stated) is also under the GPL. This means that you, the original author, cannot release the derivative work under a different license without all contributors permission. (e.g. the contributor must give you the right to release his code under a different license).

    --twivel

  • Yes, patches are covered by copyrights. It is "software" and all software, no matter how small, is automatically copyrighted by it's author per the US Copyright Act.

    -- Twivel

  • Read it carefully, you do not have to give the FSF those rights. If you release a program, you can release it under any license. All you have to do is say: "I release this code under GPL v2" and you are not giving the FSF any rights to change your program.

    -- Twivel

  • You are absolutely right, there are hundreds, even thousands of projects out there that receive very little support from developers. These are also used by very few people as well.

    But would you try to change the license of a program hardly used by anyone to a program that is commercial and proprietary, hoping to make a profit? Probably not. I would say the ones that are worthy taking proprietary are also those that would have tons of support from the internet community.

    In fact, sometimes a proprietary situation is enough to get people to actually unite and develop a free alternative.

    --Twivel

  • Ha ha ha! Beat you to it, I'm gonna hire Amazon.com's lawyers to rip you a new one buddy. Everyone knows that int i; is a concept I first propounded in the mid 90s, whilst still in school no less. Just call me the dot in dot com, baby. Don't even get me started on my pioneering use of malloc.
  • I have to say that I have used the later versions of Trumpet Winsock and DUN sucks badly when put next to it. Most notably because it's idea of timing out "when the connection is idle" seems to revolve around the creation of new TCP connections rather than the continued use of already open ones (fine for web browsing but crap for big file downloads) but also because if it has timed out, it dials up to close connections (for example persistent http connections for netscape) which costs me 5p a time (thanks a lot Microsoft). Trumpet Winsock seems to get it right.

    I was actually on the verge of registering it but bought another machine so now I IP-masquerade through Linux. Much more configurable, handles timeouts correctly and a cinche to script so that it could dial different numbers at different times of the day (I get free internet calls in the evening and weekends but it is a different number than the daytime one). It still dials up to close connections but I figure that using diald rather than pppd with on-demand will likely fix that.

    I agree with the above poster, Winsock cut themselves out of the market. Also, netmeeting doesn't work with it. Though I wouldn't put this beyond microsoft doing a bit of competitor-bashing since Trumpet oddly seem to be pushing their own OS (though not very vocally so far it seems)

    Rich

  • 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).

    The BSD license is suspect this way, Robert Young says that this was one of the reasons why he deliberately didn't do anything with BSD. Because as (hypothetically) Red Hat BSD they could develop all sorts of whizz bang things for the kernel or whatever, and then someone could come take it all and make their modifications to it proprietry. Thats verbatim from him (as well as I can remember.


  • >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...

    The only way you could stop someone from redistributing it is to have a clause that makes it illegal to redistribute it under the old license if a newer license exists, but this would have to be in the original release.

  • IANAL.

    The way I see it, is that yes, patches can have licences applied to them, but only the patch itself. When you apply a patch with licence X to a piece of code with licence Y, you get a result that is a hybrid between X and Y. X still applies to the patched stuff, and Y to the unpatched stuff.

    This means that what was done to LAME is valid, but you still can't use it commercially (including free distribution). You can still distribute the patch, and get the original from somewhere else. I don't see how this would be much of a danger to any of the big stuff like the Linux kernel because in order to remove the original licence from it you would have to completely rewrite the whole thing, which you could do anyway and change the licence. But I could see a commercial linux vendor making "changes" to the kernel and not sharing them back to the public this way. (but in order to work at all, it would still have to be visible source, if not open source)

  • OTOH, I usually wouldn't assign the copyrights on my code to anyone else, precisely because I don't want them to change the license on code that I wrote whenever they feel like it.
  • Too bad the question itself can't be moderated down (or can it?), as I think this is the prototype for a bad ask-/.-question. Why?

    a. It does not concern a difficult issue one would need /. to resolve. I'd say 5 minutes of www research would deliver all the answer.
    b. Since the answer is very straight, it's also not a good question to start up a useful discussion about the legal safety of OpenSource(TM) licenses in general.

    But what irritated me a little about all this was the way Cliff tried to make this seem relevant by talking about free things getting commercial. IMHO this type of oneliners is only ment for adding a little sensation to an otherwise dull question. Just say our free software might be threatened and it will cause lots of hits! I'm seeing this type of juicifying (?) but otherwise useless comments a bit to often on /. lately, giving /. some characteristics of a bad newspaper.

    Please feel free to prove me wrong if you like, or to add your opinion about this.

    Frank van Viegen.
  • Frank, I think you are being a bit harsh or assuming that everyone is off in an Open Source world.

    I would not know where to start to find out information on OpenSource licenses. I think the questions that are raised are totally relevant.

    I dont see you offering an answer with all your criticism, does this mean you don't know an answer to the above quewstions?

    I myself would like to know what happens to software when it moves from OpenSource to closed source. Has this ever happened before? I have heard of going the other way, closed to open.
  • (sorry, but I just have to say this)
    This doesn't have anything to do with UCITA. UCITA belongs to the USA. Software licences affect the whole world. If the worst (for you) would happen, and UCITA is passes, I welcame you all to europe.
  • It would be possible for there to be only one copyright holder. 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. The copyright could then be changed to a different license by the copyright holder without consulting anyone that contributed code.

  • I've been taking open source code and reselling it for years! Its really easy - at my company we have a somewhat strange naming convention so you'll see a lot of stuff like 'DWORD' or 'HRESULT' or WinMain() in our code. We just run this stuff through our code obfuscation product, plop a GUI on it, and out it goes!

    Sincerely,
    Bill Gates

  • For those who have been following the development of php [php.net] one answer to the question is obvious. Modularisation of additional features allows zend [zend.com] to decide exactly which features of the project they wish to gpl and which they would rather commercialise. It remains to be seen whether this amalgomy of open source and commercial principles will be popular among those consumers for whom open source is becoming a way of life.
    --
  • The GPL was very carefully designed to keep software free. One of the biggest reasons to release source code is for others to help troubleshoot, send patches, etc.

    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.

  • It seems pretty obvious that all holders of the copyright have to sign off on any changes. But, if plan on closing an open source project you will have problems keeping people from using the old code issued under the open source license. After all, during the development of software each release is a snapshot with a license. They retain the rights to that particuar snapshot. The license is a contract between two parties and the courts frown on one party alterning the terms of an agreement without consent or notification to all parties. The GPL has a specific recommendation for users of the license to put the words ,"This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version." but it should be noted that this is optional on the part of the user" in the licensing terms.

  • 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
    --
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • For my part, I have always found the GPL more fair. I don't mind giving things away, but I do mind people misusing my gifts for their own profit, instead of giving something away to the world 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

  • ...and then someone could come take it all and make their modifications to it proprietry.

    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
  • I really don't understand where you get the idea that 10 lines of code or less are uncopyrightable/freely borrowable.

    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/ [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.
  • 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
  • When you can contact all authors, but most refuse the license change, what happens then?

    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?

  • 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.

    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.

  • Wine just did this (Score:3)

    by bluGill ( 862 ) on Tuesday March 14, 2000 @11:20AM (#1202929)

    See Wine Hq. [winehq.com] 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.

  • You don't understand how this works... (Score:3)

    by MenTaLguY ( 5483 ) on Tuesday March 14, 2000 @12:24PM (#1202931) Homepage

    Note: IANAL. Do not consider this legal advice.

    Here's my question. Can licenses be applied to patches?

    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)

    Here's my point - are patches covered under the GPL (or any license?).

    Yes. See above

    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?

    ... nothing ... I don't see the problem there.

    Remember, what LAME does is GPL-infect a piece of code that is has no copyright on, simply by patching it.

    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).

  • Why did this even get posted? (Score:3)

    by seebs ( 15766 ) on Tuesday March 14, 2000 @11:22AM (#1202932) Homepage
    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.

  • Re:Yes, it is possible (Score:3)

    by Arandir ( 19206 ) on Tuesday March 14, 2000 @12:10PM (#1202933) Homepage Journal
    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.

  • It can be done, esp. with BSD, X, SCL etc... (Score:3)

    by kojak ( 84203 ) on Tuesday March 14, 2000 @11:02AM (#1202934) Homepage
    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.

  • you don't have to (Score:4)

    by Frac ( 27516 ) on Tuesday March 14, 2000 @11:32AM (#1202935)
    Note: I believe that the topic I mention here actually deserves an AskSlashdot article all by itself, since it's an interesting topic, but since my article submission has been sitting in the queue since February 20th, and CmdrTaco never did anything after I e-mailed him (I e-mailed him before he left), I'll post this question in a fairly relevant article. I'll ask my question first, and you'll see how it's not offtopic (Maybe touchy subjects like this is getting too controversial for Slashdot - if it's not, I'd like to see them make a new news article about it)

    Here's my question. Can licenses be applied to patches?. One good example of this is the LAME Encoder [sulaco.org]. 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?

  • Taking away what was granted (Score:4)

    by Myshkin ( 34701 ) on Tuesday March 14, 2000 @10:50AM (#1202936)
    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.

  • The GPL, for one, is versatile (Score:4)

    by ftobin ( 48814 ) on Tuesday March 14, 2000 @11:39AM (#1202937) Homepage

    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:

    Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.

    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.

  • Yes, it is possible (Score:5)

    by Rayban ( 13436 ) on Tuesday March 14, 2000 @10:52AM (#1202938) Homepage
    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.

  • Licensing (Score:5)

    by rcw-work ( 30090 ) on Tuesday March 14, 2000 @11:15AM (#1202939)
    IANAL.

    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.

Slashdot Top Deals

Love makes the world go 'round, with a little help from intrinsic angular momentum.

Close