Why hasn't anyone made an OSS implementation of Qt?
It's GPLed right now, and thus is already OSS. (Now, because it's under the GPL and not the LGPL, *commercial* development with Qt requires a commercial license, and that's a big chunk of the reasoning on why I'm not putting in the time to learn it -- but it certainly is open source).
It may be possible for an attorney to argue that the thing that was stolen was the sharing of the source code, and that a proper remedy for paying back "financial loss" would be to open the offending source code.
Nope -- the violation that occurred wasn't "failing to share the code", but copyright violation, since there's no law or contract which states that the defendant was obligated to share said code. That a license to use the code, in the form of the GPL, happened to be offered is irrelevant to the case as soon as it's shown that the terms of this license weren't followed -- okay, that (the license) is one less defense that's available to the defendant, and it proceeds as a regular case of copyright violation.
Since the GPL is irrelevant at this point, there aren't any special remedies in a copyright case where the terms of the GPL were available as opposed to a copyright case where usage under such terms was unoffered. Think about it: You can't sue for "failing to share the code", after all.
Re "financial loss" -- if you can show to a court that such loss happened, they want it in dollars and cents; if you can show that their actions were intentional, you might get 3x that amount. (Being able to demonstrate an amount of said loss is a place where it might be useful to, if you're the sole copyright holder, have a page detailing the terms and prices under which you'd make a copy of your app available under less-restrictive terms, if you're willing to do so).
There are a couple of good articles on (you guessed it) www.groklaw.net in which the kernel contributions of a couple of SCO developers are *very* thoroughly documented.
No doubt. I've been lurking at groklaw for quite some time, and am fully aware of just what a sieve SCO's case really is. My attempt above was to explain the theory under which SCO could claim that they didn't really offer the terms of the GPL to all the code they distributed (including that in question), not to represent any actual reality in which that claim would be taken seriously by a judge.
In the meantime, the kernel has gone through a release and others have used/modified the guy's file extensively for their own projects. What's the status of the code? Is it "irreversibly" GPLed, or does he get to pull it and screw over everyone who has since used it (in good faith) when they thought it was GPLed?
If other people have made use of it, relying on representations made by the individual who inadvertantly released their file, such that those individuals would be harmed by its withdrawal -- then you're right, it's effectively GPLed, as withdrawing the grant would be barred by promissory estoppel.
If you released code under the GPL intentionally, you can't withdraw your license grant, so you can't fuck over the folks you distribute to at all.
If you release something under the GPL accidentally, as SCO claims they've done, you may be able to withdraw -- I frankly don't know, and it'll be a question for the judge in IBM's countersuit.
Now, would the database schema/design now be GPL or would it be proprietary? It isn't compiled or linked to any 'librarys'. It is just instantiated into a physical instance. So, it should not be GPL'ed should it? What about a bunch of PHP scripts you run on Apache...those aren't GPL'ed are they?
Are you copying or modifying Apache source code to makes those PHP scripts? No? Then no, they're not covered. (And anyhow, Apache isn't GPLed -- it's under a BSD-style license which is much friendlier to commercial modifications).
Are you using Linux kernel (as opposed to libc) headers to compile your C app? No? Then no, it's not covered. (The only time you'll generally need the kernel headers is if you're, say, writing a kernel module or somesuch -- and Linus long back made some exceptions for such modules making licensing even more lax than usual).
Like Apache, the PostgreSQL license is BSD-style, is without many of the GPL's restrictions -- but even if it *were* under the GPL, unless you're actually compiling PostgreSQL code into your app, no harm no foul. (The libpq *headers* are what you'd want to be careful of -- traditionally, though, those would be licensed under the LGPL rather than the GPL proper, so you'd be fine).
I'm reminded of the stories little kids tell about how a woman gets pregnant by letting a man but his toungue in her mouth, or using the same water fountain, or so on. Your code won't become a derivative work by sitting on the toilet stall next to a GPLed app -- you need to actually do the deed.
This element of SCO's argument, as I understand it, is that they didn't really release that proprietary code because they didn't know that it was there. If they'd known chosen to release that code while knowing what it was, then they'd certainly have no right to revoke the license; their argument is that they didn't, which makes it more of a grey area.
So, roughly: SCO is a special case, they argue, because they didn't know what they were releasing. In most cases, however, folks unarguably do know what they're releasing, and so don't have the ability to pull it back.
Did you actually RTFA? Let me give you an example of a license which is not a contract (from the article, even, with only minimal adaptation):
"If you need somewhere to stay tonight, go ahead and use my guesthouse; the spare key's in the bushes to the right of the door".
Now, if you tell someone that, then you call the police to arrest them for trespass, they have the defense that you gave them a license to be there. It's not a contract, because there's no consideration -- they don't have to do anything for you; you simply granted them permission to do something they wouldn't have been able to do otherwise -- but it's nonetheless a valid defense against being charged with trespass.
The GPL is like that: It's a statement "okay, go ahead and copy, redistribute and make derived works as my software within these boundaries". There's no consideration -- it's simply a (limited) grant of permission. Hence, it's a license, and not a contract.
And no, IANAL -- but I've taken my business law classes, and am quite confident as to what I speak here.
And in closing: Please mod down this obvious troll (as someone who could make this claim after reading the article can be nothing but).
But it's the GPL, not Copyright Act that states the proprietary code needs to be released as GPLed open code. Why couldn't a judge order them to do that?
Because, as the article says, the GPL is not a contract but a license. Because it is not a contract, you will never be sued for violating said contract, and a court will never order you do to something to put yourself into compliance with that contract (which it isn't). Instead, what you can be sued for is copyright violation. Having a license (such as the GPL) is a defense against copyright violation -- you can say "no, I'm allowed to do that, because they gave me this license to do so". If you're not complying with the GPL, then all the party who's suing you has to do is show the court "no, that defense doesn't apply, because you weren't complying with the terms of the license, so we can proceed to still sue you for copyright violation". At that point the GPL becomes irrelevant, and the question is whether you have any other defenses to copyright violation. If you don't, you're guilty of copyright violation (not "violating the GPL" or anything like that) and the remedies available are exactly those that are available for other copyright cases -- which does not include forced relicensing.
GPL code owners have been pretty good about allowing accidental users of GPL code to back out things like that, however (replacing the library with a proprietary one, etc).
And if you'd read the article, you'd know that this isn't by accident.
Forcing compliance with a license isn't an available remedy for copyright violation. Period. Hence, a court will never force someone to release their application's code. That court *may* impose monitary damages, attourney's fees, or stop further distribution of the work until the infringing portion is removed -- but it will never require code to be released.
...and the article doesn't claim *nobody* will, just that a huge team won't materialize out of nowhere. That's about right.
I've been maintaining cscvs, a tool for breaking a CVS repository's history into changesets and (among other things) importing its contents into the GNU Arch revision control system. It's adopted a fair number of users (more as the documentation and such get better), and a number of developers have contributed patches. If I weren't quite so busy with my job right now, I'd have been able to help *another* developer with a bugfix he's asked for a hand in putting together (to fix mismangling of the repository locations of CVS repositories which have a delta between the path used in the CVSROOT and the one used in rlog output other than the single such case I'm currently fixing).
The other project my maintainership of which could be considered active within the past year would be the "Ticket Applet 2", a GNOME applet for showing and updating the status of ones' Kerberos ticket. It's received a quite major patch from one outside developer (providing compatibility with his alternate Kerberos implementation), and feedback from a number of users at my workplace -- but there was certainly no flood of support washing in the moment I put it up on freshmeat, and had I been expecting such I would have been mistaken.
I think the actual claim in the article is a lot more defendable than the little slashdot blurb -- to the point that the blurb really does both the readers and the author something of a disservice. (Indeed, the only one I completely disagree with is the argument that it isn't sometimes best to throw out working code for a complete rewrite should it become unmaintainable).
The only thing these 'activists' are trying to do is give RFID tags a bad wrap.
No, they also pointed out issues completely unrelated to the badges -- such as displaying members' information in such a way that others could observe or record it, easy circumvention of the metal detectors, and the like.
The security badges they scammed are no different than the ones we've all been wearing to get into our day jobs for the past 10 years.
The badge I wear to get into my day job is passive -- needs an EM field from the reader to do anything at all -- and readable only at a range tantamount to actual contact.
Pardon. I did indeed read the article, but my eyes somehow read "Information Security".
That said, I would argue that privacy and security are key among such issues, and would hope that those involved in such a society would be knowledgable regarding it.
It's a security conference. There's a reasonable expectation is that security experts:
Are innately concerned about avoiding unnecessary exposure of personal data (say, by displaying it in such a way that 3rd parties could observe or record personal information about other attendants).
Will be able to use access control which is not circumvented by such a blatantly trivial mechanism as a fake ID.
Will not permit other physical security measures (such as the use of metal sensors) to be trivially circumvented (as by smuggling in items which would not be permitted to be taken in during the conference itself beforehand).
And so forth. The issue is not necessarily so much that the organizers are hostile as that they're incompetant in the very matter they're holding a conference about.
So what he is? Refusing to sell a man fuel who needs it and using some principal as justification is still an exceedingly unkind, inappropriate and generally antisocial position.
Sure, he shouldn't have been careless. Sure, he could have been dead. That doesn't make it any more excusable to refuse to sell a man fuel when he needs it on the basis of some stiff-necked principal.
The bases did not refuse to sell him the fuel, they refused to give it to him.
Do you have actual evidence for that statement? I find it pretty darned unlikely. Yes, the wording of the story is that the bases "refused to give him fuel" -- but one who refuses to sell something is also necessarily refusing to give it. The wording is ambiguous, and I'm quite confident that most native English speakers would agree with me on this one. So, since either definition can easily follow, let's play the "What's More Likely" game.
(1) - This guy who has enough money to build this experimental plane lets himself stay stranded because he'll only take fuel if someone gives it to him for free
or
(2) - He is in fact attempting to buy fuel (as one would from "a gas station", which the bases insist they are not) and the bases are unwilling to sell.
Slashdot Mirror
Yes -- I should have said "proprietary" software rather than "commercial" software. My bad.
Why hasn't anyone made an OSS implementation of Qt?
It's GPLed right now, and thus is already OSS. (Now, because it's under the GPL and not the LGPL, *commercial* development with Qt requires a commercial license, and that's a big chunk of the reasoning on why I'm not putting in the time to learn it -- but it certainly is open source).
If your definition of "a few years" means about 20.
That might be acceptable in some fields, but in computing it just plain isn't.
It may be possible for an attorney to argue that the thing that was stolen was the sharing of the source code, and that a proper remedy for paying back "financial loss" would be to open the offending source code.
Nope -- the violation that occurred wasn't "failing to share the code", but copyright violation, since there's no law or contract which states that the defendant was obligated to share said code. That a license to use the code, in the form of the GPL, happened to be offered is irrelevant to the case as soon as it's shown that the terms of this license weren't followed -- okay, that (the license) is one less defense that's available to the defendant, and it proceeds as a regular case of copyright violation.
Since the GPL is irrelevant at this point, there aren't any special remedies in a copyright case where the terms of the GPL were available as opposed to a copyright case where usage under such terms was unoffered. Think about it: You can't sue for "failing to share the code", after all.
Re "financial loss" -- if you can show to a court that such loss happened, they want it in dollars and cents; if you can show that their actions were intentional, you might get 3x that amount. (Being able to demonstrate an amount of said loss is a place where it might be useful to, if you're the sole copyright holder, have a page detailing the terms and prices under which you'd make a copy of your app available under less-restrictive terms, if you're willing to do so).
There are a couple of good articles on (you guessed it) www.groklaw.net in which the kernel contributions of a couple of SCO developers are *very* thoroughly documented.
No doubt. I've been lurking at groklaw for quite some time, and am fully aware of just what a sieve SCO's case really is. My attempt above was to explain the theory under which SCO could claim that they didn't really offer the terms of the GPL to all the code they distributed (including that in question), not to represent any actual reality in which that claim would be taken seriously by a judge.
Yes, the copyrighted code can be removed if a convincing case can be made that it was accidentally put in and was not to be GPL'd.
I think they'd be prevented by pulling it via promissory estoppel.
In the meantime, the kernel has gone through a release and others have used/modified the guy's file extensively for their own projects. What's the status of the code? Is it "irreversibly" GPLed, or does he get to pull it and screw over everyone who has since used it (in good faith) when they thought it was GPLed?
If other people have made use of it, relying on representations made by the individual who inadvertantly released their file, such that those individuals would be harmed by its withdrawal -- then you're right, it's effectively GPLed, as withdrawing the grant would be barred by promissory estoppel.
Heh. Other way 'round.
If you released code under the GPL intentionally, you can't withdraw your license grant, so you can't fuck over the folks you distribute to at all.
If you release something under the GPL accidentally, as SCO claims they've done, you may be able to withdraw -- I frankly don't know, and it'll be a question for the judge in IBM's countersuit.
Now, would the database schema/design now be GPL or would it be proprietary? It isn't compiled or linked to any 'librarys'. It is just instantiated into a physical instance. So, it should not be GPL'ed should it? What about a bunch of PHP scripts you run on Apache...those aren't GPL'ed are they?
Are you copying or modifying Apache source code to makes those PHP scripts? No? Then no, they're not covered. (And anyhow, Apache isn't GPLed -- it's under a BSD-style license which is much friendlier to commercial modifications).
Are you using Linux kernel (as opposed to libc) headers to compile your C app? No? Then no, it's not covered. (The only time you'll generally need the kernel headers is if you're, say, writing a kernel module or somesuch -- and Linus long back made some exceptions for such modules making licensing even more lax than usual).
Like Apache, the PostgreSQL license is BSD-style, is without many of the GPL's restrictions -- but even if it *were* under the GPL, unless you're actually compiling PostgreSQL code into your app, no harm no foul. (The libpq *headers* are what you'd want to be careful of -- traditionally, though, those would be licensed under the LGPL rather than the GPL proper, so you'd be fine).
I'm reminded of the stories little kids tell about how a woman gets pregnant by letting a man but his toungue in her mouth, or using the same water fountain, or so on. Your code won't become a derivative work by sitting on the toilet stall next to a GPLed app -- you need to actually do the deed.
There are "commercial-with-source" licenses out there. In fact, there's quite a lot of software so licensed.
This element of SCO's argument, as I understand it, is that they didn't really release that proprietary code because they didn't know that it was there. If they'd known chosen to release that code while knowing what it was, then they'd certainly have no right to revoke the license; their argument is that they didn't, which makes it more of a grey area.
So, roughly: SCO is a special case, they argue, because they didn't know what they were releasing. In most cases, however, folks unarguably do know what they're releasing, and so don't have the ability to pull it back.
That's what people mean when they use the term "viral."
Then every commercial software license that doesn't provide the customer the right to make derived works is "viral".
Do you really believe that's true?
You can have a contract with no signatures ...but you can't have a contract with no consideration. Hence, the GPL is not one.
Did you actually RTFA? Let me give you an example of a license which is not a contract (from the article, even, with only minimal adaptation):
"If you need somewhere to stay tonight, go ahead and use my guesthouse; the spare key's in the bushes to the right of the door".
Now, if you tell someone that, then you call the police to arrest them for trespass, they have the defense that you gave them a license to be there. It's not a contract, because there's no consideration -- they don't have to do anything for you; you simply granted them permission to do something they wouldn't have been able to do otherwise -- but it's nonetheless a valid defense against being charged with trespass.
The GPL is like that: It's a statement "okay, go ahead and copy, redistribute and make derived works as my software within these boundaries". There's no consideration -- it's simply a (limited) grant of permission. Hence, it's a license, and not a contract.
And no, IANAL -- but I've taken my business law classes, and am quite confident as to what I speak here.
And in closing: Please mod down this obvious troll (as someone who could make this claim after reading the article can be nothing but).
But it's the GPL, not Copyright Act that states the proprietary code needs to be released as GPLed open code. Why couldn't a judge order them to do that?
Because, as the article says, the GPL is not a contract but a license. Because it is not a contract, you will never be sued for violating said contract, and a court will never order you do to something to put yourself into compliance with that contract (which it isn't). Instead, what you can be sued for is copyright violation. Having a license (such as the GPL) is a defense against copyright violation -- you can say "no, I'm allowed to do that, because they gave me this license to do so". If you're not complying with the GPL, then all the party who's suing you has to do is show the court "no, that defense doesn't apply, because you weren't complying with the terms of the license, so we can proceed to still sue you for copyright violation". At that point the GPL becomes irrelevant, and the question is whether you have any other defenses to copyright violation. If you don't, you're guilty of copyright violation (not "violating the GPL" or anything like that) and the remedies available are exactly those that are available for other copyright cases -- which does not include forced relicensing.
GPL code owners have been pretty good about allowing accidental users of GPL code to back out things like that, however (replacing the library with a proprietary one, etc).
And if you'd read the article, you'd know that this isn't by accident.
Forcing compliance with a license isn't an available remedy for copyright violation. Period. Hence, a court will never force someone to release their application's code. That court *may* impose monitary damages, attourney's fees, or stop further distribution of the work until the infringing portion is removed -- but it will never require code to be released.
...and the article doesn't claim *nobody* will, just that a huge team won't materialize out of nowhere. That's about right.
I've been maintaining cscvs, a tool for breaking a CVS repository's history into changesets and (among other things) importing its contents into the GNU Arch revision control system. It's adopted a fair number of users (more as the documentation and such get better), and a number of developers have contributed patches. If I weren't quite so busy with my job right now, I'd have been able to help *another* developer with a bugfix he's asked for a hand in putting together (to fix mismangling of the repository locations of CVS repositories which have a delta between the path used in the CVSROOT and the one used in rlog output other than the single such case I'm currently fixing).
The other project my maintainership of which could be considered active within the past year would be the "Ticket Applet 2", a GNOME applet for showing and updating the status of ones' Kerberos ticket. It's received a quite major patch from one outside developer (providing compatibility with his alternate Kerberos implementation), and feedback from a number of users at my workplace -- but there was certainly no flood of support washing in the moment I put it up on freshmeat, and had I been expecting such I would have been mistaken.
I think the actual claim in the article is a lot more defendable than the little slashdot blurb -- to the point that the blurb really does both the readers and the author something of a disservice. (Indeed, the only one I completely disagree with is the argument that it isn't sometimes best to throw out working code for a complete rewrite should it become unmaintainable).
The only thing these 'activists' are trying to do is give RFID tags a bad wrap.
No, they also pointed out issues completely unrelated to the badges -- such as displaying members' information in such a way that others could observe or record it, easy circumvention of the metal detectors, and the like.
The security badges they scammed are no different than the ones we've all been wearing to get into our day jobs for the past 10 years.
The badge I wear to get into my day job is passive -- needs an EM field from the reader to do anything at all -- and readable only at a range tantamount to actual contact.
Pardon. I did indeed read the article, but my eyes somehow read "Information Security".
That said, I would argue that privacy and security are key among such issues, and would hope that those involved in such a society would be knowledgable regarding it.
And so forth. The issue is not necessarily so much that the organizers are hostile as that they're incompetant in the very matter they're holding a conference about.
The guy is a complete moron
So what he is? Refusing to sell a man fuel who needs it and using some principal as justification is still an exceedingly unkind, inappropriate and generally antisocial position.
Sure, he shouldn't have been careless. Sure, he could have been dead. That doesn't make it any more excusable to refuse to sell a man fuel when he needs it on the basis of some stiff-necked principal.
The bases did not refuse to sell him the fuel, they refused to give it to him.
Do you have actual evidence for that statement? I find it pretty darned unlikely. Yes, the wording of the story is that the bases "refused to give him fuel" -- but one who refuses to sell something is also necessarily refusing to give it. The wording is ambiguous, and I'm quite confident that most native English speakers would agree with me on this one. So, since either definition can easily follow, let's play the "What's More Likely" game.
(1) - This guy who has enough money to build this experimental plane lets himself stay stranded because he'll only take fuel if someone gives it to him for free
or
(2) - He is in fact attempting to buy fuel (as one would from "a gas station", which the bases insist they are not) and the bases are unwilling to sell.
Well, you tell me: Which is more likely?
Compare them?
OpenOffice is not an IDE; Java Studio Creator is not an office application suite. They're not competing against each other.
Ahh, but consider: 74 degrees west is the same as 286 degrees east. Thus, NYC is obviously much further east than it is west. :P