| |||||||||||||
Making kernel license upgradeableMaking kernel license upgradeablePosted Oct 14, 2004 11:12 UTC (Thu) by copsewood (subscriber, #199)In reply to: Buying the kernel by gravious Parent article: Buying the kernel
I won't comment on b. Your suggestion a. would also need much more than a comment in source code to be effective. Essentially, as I understand this, to make it possible to transition to a more effective license in the spirit of
Not an easy, or in my view a likely prospect.
(Log in to post comments)
Making kernel license upgradeable Posted Oct 14, 2004 12:33 UTC (Thu) by hummassa (subscriber, #307) [Link] There is one thing even Jon forgot: even if you purge some parts owned by me from the kernel, you would have to use filtration-abstraction-comparison tests to determine if other people's copyrights are not derived from my work... If they are, independently of the will of the copyright owner, you cannot re-license it, too.
Suppose, as an example and illustration only, that I was the guy who, in 1992 (this is just an example), wrote the original mutex implementation. Suppose, furthermore, I fell out of the surface of the world yesterday -- I went to live in the Tibet, up the Himalaya, and no-one can contact me. Suppose there is not one line of kernel code that I wrote in the current kernel, but suppose, too, that all implementations of mutex are derived from one another, adding things, removing things -- ie. making TRANSFORMATIONS to my code --, till you get to the current status quo.
The current author of the mutex code has no right to relicense it. Period. It's a derived work, and I (as a copyright owner of the original code) have a MONOPOLY on what can be done with ALL derived works. And the only thing I have authorized before getting out of touch is to license them under the GPL.
IMHO, the thing stretches even more: as lots of things in the rest of the kernel are derived works from my work, those can't be relicensed too. More: imagine, graphically, if you "yank" the current mutex implementation from the kernel. You would have to write (clean-room) something that fits in the "void/hole" left behind. But to do this, you would have probably to use other code that is derived on my code... gotcha! Your code now is derived from mine and you have no other option to distribute it than doing it under the terms of the GPL.
Point being: the linux kernel is, for all purposes, un-relicensable in practice. This is a GOOD THING. It's even safer than the FSF social contract in assuring the code will remain GPL'd and won't ever be closed. I explain myself: in the case of a liquidation (if the FSF went bankrupt), the successor could close-source all of the GNU code, because it all belongs to the FSF. Obviously, forks could be made, but the damage would have been done.
To prove me wrong, you would have to make a directed graph of copyrightable chunks of the kernel and/or kernel patches, where the chunks are the nodes and the derivation relation are the edges. Then, if you find any clicks (and I don't believe it for a moment), you can in theory remove that click and rewrite it.
Making kernel license upgradeable Posted Oct 14, 2004 16:15 UTC (Thu) by bfields (subscriber, #19510) [Link] in the case of a liquidation (if the FSF went bankrupt), the successor could close-source all of the GNU code, because it all belongs to the FSF. Is that really likely? In any case, even if the FSF were somehow completely taken over, wouldn't there still be the problem of breaking all the contracts the FSF has signed with copyright assigners? I seem to recall their standard assignment agreement including a clause where the FSF promises that the licensing of the code will always be "in the spirit of" the GPL, or something like that. I doubt the GNU stuff is really at any more risk of proprietary branches than is Linux. --Bruce Fields
Making kernel license upgradeable Posted Oct 14, 2004 23:19 UTC (Thu) by giraffedata (subscriber, #1954) [Link] even if the FSF were somehow completely taken over, wouldn't there still be the problem of breaking all the contracts the FSF has signed with copyright assigners? I seem to recall their standard assignment agreement including a clause where the FSF promises that the licensing of the code will always be "in the spirit of" the GPL, or something like that. "successor" here means the person who bought the former assets of FSF, in particular, its copyrights. That person is not a party to the contract under which the author assigned the copyright, so he's not bound by anything in it. On the other hand, it is common in contracts like this to say that the assignment is revocable and in the event the copyright is ever transferred, the assignment is revoked -- a poison pill. I wonder if the FSF contract has that. Some US states view some such clauses as an interference with free trade that is not in the public interest and won't enforce them. And maybe copyright law (I know contracts, not copyright) makes a revocable assignment impossible.
Making kernel license upgradeable Posted Oct 21, 2004 11:25 UTC (Thu) by Wol (guest, #4433) [Link] "successor" here means the person who bought the former assets of FSF, in particular, its copyrights. That person is not a party to the contract under which the author assigned the copyright, so he's not bound by anything in it. OH YES HE IS !!! Let's say I buy your house and give you 100K for it. I then go bankrupt and the mortgagor repossess it. You'd scream blue murder if the mortgagor then proceeded also to reclaim the 100K I gave you for it - you've lost the house, and you've lost what was paid for it!
If the contract by which the FSF purchased the copyrights has covenants on it, then even a "successor in bankruptcy" can't ignore those covenants - to do so voids the original sale because the successor-in-interest has reneged on the original price. Cheers,
Making kernel license upgradeable Posted Oct 21, 2004 16:14 UTC (Thu) by giraffedata (subscriber, #1954) [Link] Let's say I buy your house and give you 100K for it. I then go bankrupt and the mortgagor repossess it. You'd scream blue murder if the mortgagor then proceeded also to reclaim the 100K I gave you for it - you've lost the house, and you've lost what was paid for it!You got your example backwards. To be analogous to the FSF copyright assignment case, it would be: Instead of giving me 100K for my house, you promise to pay me 100K next year -- and without a security agreement (i.e. collateral, e.g. mortgage). The bank (who is btw the mortgagee, not the mortgagor) repossesses and I then try to get my 100K from the bank. I will not succeed. If you're broke, I've lost my 100K and my house. If the contract by which the FSF purchased the copyrights has covenants The only kind of property I've ever heard of with the ability to have a convenant run with the title is real property. In a contract, a "covenant" is nothing but a promise from one person to another and exists independent of any property whose transfer might also be part of the contract. There is a special case (isn't there always) where there is an automatic "purchase money lien," but that doesn't apply here. the successor-in-interest has reneged on the original price. He can renege only if he was obligated to pay the price in the first place, which I say he wasn't. Successor in interest is a fairly recent invention in law, which means it is applied inconsistently from one jurisdiction and circumstance to the next. For example, in California if you buy most of the assets of a business and continue to operate it as essentially the same business, you become liable for the seller's unpaid sales tax under a successor in interest law. But it definitely doesn't say that any time property changes hands, it's an assignment of all the contracts of sale under which it previously changed hands. That's why people execute security agreements (liens) and file them in a public office when they sell property. Then a subsequent transferee has a chance to know he might owe some 3rd party additional money for the property (not really -- he still doesn't assume any obligations -- he just might have to hand over the property). Without it, the 1st party has no claim against the 3rd.
Making kernel license upgradeable Posted Oct 14, 2004 16:18 UTC (Thu) by khim (subscriber, #9252) [Link] The current author of the mutex code has no right to relicense it. Period. It's a derived work, and I (as a copyright owner of the original code) have a MONOPOLY on what can be done with ALL derived works. And the only thing I have authorized before getting out of touch is to license them under the GPL. IMHO, the thing stretches even more: as lots of things in the rest of the kernel are derived works from my work, those can't be relicensed too. More: imagine, graphically, if you "yank" the current mutex implementation from the kernel. You would have to write (clean-room) something that fits in the "void/hole" left behind. But to do this, you would have probably to use other code that is derived on my code... gotcha! Your code now is derived from mine and you have no other option to distribute it than doing it under the terms of the GPL. Do you work for SCO ? This is exactly what they try claim, you know. The truth is that the only thing you can compare is your code before Tibet expedition and current code in kernel. And you can not appeal to "ideas": you need something textually similar (trivial modifications like variables renaming is Ok, complete rewrite is not). It's difference between copyright and patent... It's not so hard to create clean-room implementation if really needed: you ask some fellow to write API starting from point where mutex code is still in kernel and then you ask other person to reimplement API. What you'll get if API was without code snippets and without parts of you code big enough to be copyrightable is new code without any relation to original mutex implementation. The real problem lies not in bare need to reimplement something but in sheer number of things included in kernel...
No one is prosco here :-) Posted Oct 15, 2004 21:23 UTC (Fri) by hummassa (subscriber, #307) [Link] Seriously, you have to abstract-filter-compare. In the case of SCO, once you abstract and filter System V versus Linux, NOTHING is left to be compared. You can search for yourself if you don't believe me.
Making kernel license upgradeable Posted Oct 14, 2004 22:24 UTC (Thu) by rickmoen (subscriber, #6943) [Link] hummassa wrote:I [should] explain myself: in the case of a liquidation (if the FSF went bankrupt), the successor could close-source all of the GNU code, because it all belongs to the FSF. More precisely, the successor organisation (as owner of the copyright title) could issue additional code instances under proprietary licences. Recipients of the existing instances would immediately fork off the earlier codebase and continue exactly as before -- classifying the successor group as damage and routing around it. A few people have asserted that the new copyright holder could in some fashion retroactively terminate redistribution of the existing codebase instances and development of derivative works, but I'll believe that when I see a relevant appelate court judgement. Rick Moen
Making kernel license upgradeable Posted Oct 14, 2004 22:45 UTC (Thu) by rickmoen (subscriber, #6943) [Link] [I missed this bit, earlier, or I would have included it in my other reply.] hummassa wrote: [Most of mutex hypothetical snipped.] But to do this, you would have probably to use other code that is derived on my code... gotcha! Your code now is derived from mine and you have no other option to distribute it than doing it under the terms of the GPL. This is a persistent misconception that I would like to see disappear, finally, from licensing discussions. If my derivative work has been issued under terms incompatible with those of your original, you have zero power to force me to do anything. What you have is a tort claim against me. This entitles you to take me to court, prove your copyright title, attempt to enjoin me from further infringement, and possibly extract monetary damages. You could not twist my arm into releasing my code under any terms at all, because you would simply not have any ownership interest in my additions, only in your original work. What free / open-source software people seem to fail to realise is that licensing conflicts come up in business all the time, and the outcome is never that the infringing firm "has no option but" to issue an instance of its derivative creation under some licence or other. Firm A accidentally includes business partner Firm B's proprietary code in its binary derivative of an upstream GPLed utility from Coder D. Firm C downloads it, and requests matching source code under GPLv2 clause 3b. Does Firm A comply? Probably not. It will probably tell Firm C "Sorry, our binary release was accidental and has been removed from our ftp site". Violating Firm B's contract and shafting a business partner would be a serious legal matter; a brief, accidental, already-corrected infringement of Coder D's copyright is not. Rick Moen
You misinterpreted me Posted Oct 15, 2004 21:24 UTC (Fri) by hummassa (subscriber, #307) [Link] But you emphasized just my point: If the derived code author wants to distribute it, the original code author eventually can stop him -- via a tort.
You misinterpreted me Posted Oct 16, 2004 20:09 UTC (Sat) by rickmoen (subscriber, #6943) [Link] hummassa wrote:But you emphasized just my point: If the derived code author wants to distribute it, the original code author eventually can stop him -- via a tort. Actually, you're completely disregarding my correction and changing the subject: You were saying that the author of the derivative work "has no option" but to distribute it under the upstream work's terms. My point was that this is absolutely false -- and is a very common error. Rick Moen
Making kernel license upgradeable Posted Oct 15, 2004 3:00 UTC (Fri) by jamesh (guest, #1159) [Link] It's even safer than the FSF social contract in assuring the code will remain GPL'd and won't ever be closed. I explain myself: in the case of a liquidation (if the FSF went bankrupt), the successor could close-source all of the GNU code, because it all belongs to the FSF. I think you are wrong here. If the FSF went bankrupt and someone bought their assets, they couldn't just buy the copyrights, they'd be buying the copyright assignment contracts signed by the original copyright holders. Unlike some copyright assignment contracts, the FSF one actually places some restrictions on what the assignee can do with the work. For instance, there is the 1999 contract I signed for some modifications to a GNU program included the following text: The Foundation promises that all distribution of the Work, or of any work "based on the Work", that takes place under the control of the Foundation or its assignees, shall be on terms that explicitly and perpetually permit anyone possessing a copy of the work to which the terms apply, and possessing accurate notice of these terms, to redistribute copies of the work to anyone on the same terms. These terms shall not restrict which members of the public copies may be distributed to. These terms shall not require a member of the public to pay any royalty to the Foundation or to anyone else for any permitted use of the work they apply to, or to communicate with the Foundation or its agents in any way either when redistribution is performed or on any other occasion. If the FSF or its assignees (that would include people who bought their assets in the case of bankruptcy) do not abide by the terms, then there is no contract and ownership of the copyright would revert. Do you really think an organisation smart enough to come up with the GPL would leave such a large loophole in their assignment contracts?
In this point, I stand corrected. Posted Oct 15, 2004 21:26 UTC (Fri) by hummassa (subscriber, #307) [Link] I was under the assumption -- the WRONG assumption -- that original copyright holders just waived their (c)s to the FSF, no strings attached. This would be silly and I recognize it.
I apologize for talking thru parts of my body not engineered no evolved for talking :-)
Making kernel license upgradeable Posted Nov 1, 2004 13:28 UTC (Mon) by BrucePerens (guest, #2510) [Link] A 501(c)3 corporation can only dispose of its assets <i>to another 501(c)3</i> in case of liquidation. It's part of the IRS rules. And any successor in assignment to FSF's property would be bound by contracts of FSF, including the copyright grant covenants. So, I don't think it's possible for closed relicensing to happen.<p><i>Bruce</i>
|
|||||||||||||