In my opinion the betatesting of Corel's linux distribution is internal.
I don't see anything in the GPL to allow special privileges to people doing ``internal distribution'' (whatever that might be), or beta testing.
Regardless of that, as one of the copyright holders for some of the software that they are distributing, it was bizarre (to say the least) to find that I was being asked to revoke my right to distribute my own software.
Especially since if I had acceeded to the request, they would have lost their right to distribute my code (GPL clause 4) as soon as they tried it.
The Software or Product was developed entirely at private expense, and no part of the Software or Product was first produced in the performance of a Government contract.
and yet, if you run this grep -1 Security/usr/src/linux/drivers/net/*.c
You'll get quite a lot of this: 3c501.c- Copyright 1993 United States Government as represented by the 3c501.c: Director, National Security Agency. This software may be used and 3c501.c- distributed according to the terms of the GNU Public License, -- 3c503.c- Copyright 1993 United States Government as represented by the 3c503.c: Director, National Security Agency. This software may be used and 3c503.c- distributed according to the terms of the GNU Public License, -- 3c507.c- Copyright 1993 United States Government as represented by the 3c507.c: Director, National Security Agency. ...
If I download a bunch of GPL'd code, and change a single letter in it, am I
immediately bound to redistribute it?
There is nothing forcing distribution of GPL code, but if you do choose not to keep your changes to yourself, by distributing binaries, then the GPL insists that each person gets the right to ask for source, and also gets all the rights you had under the GPL, including onward distribution.
I'm sure Corel's lawyers would insist that without a license from them, that you are not even allowed to make backup copies of their proprietary software.
That also applies to GPLed code, so as soon as you take a copy of the program and give it to someone (be they an employee, a designated beta tester, or whatever) you are either doing it under the terms of the GPL, or you are violating the license. End of Story.
If I copy a GPLed program and hand it across the room to someone in the same company, the only thing that gives me the right to do that is the GPL, so by doing that I agree to abide by the GPL.
Since for your friends to have a useful opinion about your change, you'd almost certainly send them the source.
You would be in violation of the GPL if you did either of:
refusing to give them the source, on request
insisting that they never redistribute the source you send them (rather than just mentioning that you'd rather they didn't until it was tested, and relying on their good sense)
It's a risk I'd be willing to take too (apparently I cannot, being British)
The quality of the offer is not what's being complained about.
They selected a bunch of people who are almost bound to be long term spam victims (I know I am), and they spammed them.
That's just stupid.
If they'd asked (on their web site) for people that were interested, and and eligible, to mail ipo@redhat.com (or some such), everyone would be thoroughly cheerful about it, and they'd have got a nice pat on the back from/.
I got a copy of this, and reacted pretty badly (since SPAM really pisses me off), but I've calmed down now.
In my case this is definitely SPAM, since it's a get rich quick scheme that I'm not eligible for (I live in the UK). I'd still consider it to be SPAM even if I was eligible.
I'd imagine that some pointy-haired genius at RedHat thought that a mass mailing to a randomly trawled list of contributors would be a great idea.
It reminds me of the one where Dilbert sarcastically suggests that they mass mail all their customers, and the PHB says "Do it''
What they should have done, is publish a page, saying "e-mail us with a justification of your claim to be a open source (sic) contributor, and we'll send you a password.''.
I presume they didn't want to do that, because it would have caused them work, whereas they're perfectly happy to waste thousands of other people's time, and in many cases money downloading some crappy email that doesn't apply to them.
OK, so in conclusion we have the following facts:
-- dubious research compiling the list of victims -- disregard of other people's time/data costs, in order to save themselves effort -- responding to the email is likely to make money for the sender
Looks like SPAM to me.
P.S. I've go no axe to grind against RedHat in general, but IMO they don't get a license to spam no matter how generally wonderful they are.
While you may have written the scripts that were used to build ``bo'' CDs, I think we should probably credit Andreas Jellinghaus, who did an almost total rewrite for ``hamm'' (a.k.a. Debian 2.0).
I then maintained that set of scripts, but there has since been another rewrite by Steve McIntyre (for ``slink'', a.k.a. Debian 2.1), with contributions from a whole bunch of people on debian-cd@lists.debian.org.
Apart from that, you are correct in saying that the Official Debian GNU/Linux CDs contain only software that meets the Debian Free Software Guidelines.
Cheers, Phil. P.S. rsync ? I think you mean rdist. rsync is GPL. Debian's rdist is rdist-6.1.3 (usc.edu:/pub/rdist) which is BSD.
Well, I'm using a Linux web browser, but I'm also using Junkbuster which would show up as an old version of Mac Netscape in your stats, so who knows what one can conclude from your 1%
I see two reasons for using the plain swirl as the official logo, and the bottle one as the unofficial:
1) The plain swirl looks better IMO, and should look great if we can get it printed onto CDs so that it covers most of the CD surface. In order to print the with bottle logo on a CD it will have to be much smaller, which is appropriate.
2) If the lone swirl is the official logo, then the with-bottle logo effectively says ``contains Debian'', rather than ``is Debian''. Also, since it's an obvious genie reference, all genie stories have something powerful (i.e. Debian) hiding in a mundane object (the product that uses Debian in an unofficial capacity).
Personally, I'd much prefer that the source to the code that runs my Father's pacemaker was available to look at, and perhaps even fix. I can think of two ways of finding out that it has a Y2K problem. One is to read the source.
In every other field of engineering and science, peer review is undertaken on any serious project. So why should we allow Software Engineers to get away with it?
It's not as though the assumption of infallibility that was contained in your ``Medical Equipment'' comment was even vaguely justified.
At least you can generally trust the published breaking strain on a bolt, the same often does not hold for a line of code.
Free Software is the best mechanism anyone's come up with so far for reintroducing peer review into software development. That alone justifies it's use.
By the time I've typed this, it'll be over 70%, probably over 90% in an hour, so they'll probably discount the results, the way ``Hank'' got mostly discarded as a joke for the personality of the year vote.
The question is, does this sort of thing frighten the pointy haired types at the companies that get hit by the slashdot effect ?
If the PHB says ``set up a poll'' and the results come back so radically screwed that there is clearly no statistical value in them (rather than being bogus, but looking all right, which would be the case sans slashdot:-) does this not just have a tendency to make the PHB frightened of this bunch of marauding Techies, who screwed up his plan of making more golf time (by delegating his decisions to Internet polls).
Perhaps Hemos should send an appology for screwing thier poll up, pointing out that Internet polls are of no statistical value, whatever the result.
--
Re:What will it look like?
on
GNU Inside?
·
· Score: 1
Well, given that it's meant to be ``GNU Inside'' perhaps they should be indulging in a spot of xenophilia (did I just make that word up ?)
Given that copyright law relates to when one is allowed to copy something, attempting to restrict someone's use of a program once they have legally obtained a copy is not something that you can do with a copyright based software license (AFAIK).
Hence, If I download a copy of your code, to have a play with it (i.e. obtain a legal copy). Then, once I have the legal copy, it seems to me that I can quite legally use it to run my business --- I just cannot copy it further, and distribute it.
The only way to enforce this, is to get me to enter into a contract prior to giving me access to the code, in which I agree not to use the software for anything commercial. Dan Bernsein's take on the situation is probably worth reading, since I'm not a lawyer.
My only concern with the new license, is that as it stands it seems to be saying that if code is found to infringe a US patent, they will withdraw usage rights worldwide.
Unfortunately the US patent office has a tendency to grant totally bogus patents, which would not apply outside the US because either we have more sensible patent officers, or simply don't recognise software patents to the same extent.
This gives rise to a possibility my rights to use code which is perfectly legal in my country, will be restricted because of some dubious judgement in the US.
Assuming that my reading of this is correct, I'd say this is just enough for APSL 1.1 to fail to qualify as DFSG free.
I think the most pathetic faliure I've had on a windoze box was when I upgraded my CPU from a P133 to a P200 (or something like that), and on reboot it decided that I'd changed video cards on it (which I had not), and locked up. After that, it wouldn't even go into safe mode. I ended up having to install W95 from scratch (which worked, so there was no problem with the hardware).
Meanwhile of course, the Linux installation that was also on the machine didn't even blink.
This paragraph makes a couple of assertions, that are just not supported by the evidence we see in the world.
From an evolutionary stand point, one sees that we are motivated by the interests of the genes we carry. Said interests can often be totally at odds with the interests of the individual. Take parents risking their lives for their children.
Of course, there are clearly cases where factors other than gene propagation take the primary hand: Homosexuality tends to significantly reduce one's chances of passing on one's genes, and yet it still occurs.
Likewise, the assertion that religions tend to act in favour of their adherents is also unfounded. What they tend to do is act in favour of the memes that make up the core of the religion. This can sometimes benefit the carriers of the memes, but it can also cause them extreme hardship, or even death.
In both cases, the genes and memes act in their own self interests, not out of some universal compulsion to do so, but because the ones that don't haven't survived for us to look at.
Thus there are religions who's memes result in the belivers commiting mass suicide (against the interests of the individuals, the group, and the memes), but they tend to take their memes with them.
The fact that it's ``libre'' tends to result in it also being pretty much ``gratuit'' as well, but it's entirely possible to use the GPL on software for which you charge money.
For example, I could write a program and sell copies of it for $1000.00, licensed under the GPL. It's possible that my customers might decide not to give away the source that they have, until someone else does, because they might think that it would somehow devalue their investment.
Eventually, I could expect someone to publish the source either more cheaply then me (or even for free), at which point my ability to charge some of my potential customers $1000.00 would evaporate, but there would probably still be people willing to pay the price, because they are too clueless to realise that it was available for free, or think that there is something special about getting it direct from the author.
I remember thinking of schemes like this when I first came across the idea of Free Software. I've been thinking about it ever since (about 14 years) and have concluded that they won't work. Given that I make my living out of supporting Free Software, this is not simply an intellectual exercise for me.
The problem is that people are generally not motivated to write good software by money. There is quite a body of evidence that offering monetary incentives to programmers tends to reduce quality, as the programmers start putting effort into working the system, rather than coding. Obviously, people are paid to code, but the money is rarely the direct motivation for doing a good job.
He does touch on one of the primary motivations for commercial programmers contributing to Free Software, which is that it is often cheaper to add the features you want to an existing Free program, than to write, or buy something else.
Anyway, an interesting article, but it's fundamentally flawed in its assumption that COSS falls under the wing of Free Software.
Clause 6 of the DFSG (a.k.a. OSD) prohibits licenses that discriminate against specific fields of endeavour (such as making money, for example).
Even if that were not the case, DFSG compliant licenses must allow derived works (clause 2) which would mean that you could derive a work which differed only in the person to whom the money should be sent, which would instantly destroy the structure he's trying to build.
His ideas also seem to fall foul of the fact that you can do what the hell you like with legally obtained software, so the ``are you using it enough to pay for it ?'' stuff might be interesting to enforce, and certainly wouldn't result in a DFSG license.
On the subject of allocating points, I'd be stunned if anyone could come up with a scheme that would appropriately reward someone that spends six months tracking down an obscure (but serious) bug (say an intermittent networking bug).
Say you allocate 5 points (it's only bug fix, after all) and the contributor says ``that's not enough, I spent six months finding that bug!'' --- You end up with all the silliness of having to do a clean-room reimplementation of the fix ? Oh dear, oh dear.
Slashdot Mirror
In my opinion the betatesting of Corel's linux distribution is internal.
;)
I don't see anything in the GPL to allow special privileges to people doing ``internal distribution'' (whatever that might be), or beta testing.
Regardless of that, as one of the copyright holders for some of the software that they are distributing, it was bizarre (to say the least) to find that I was being asked to revoke my right to distribute my own software.
Especially since if I had acceeded to the request, they would have lost their right to distribute my code (GPL clause 4) as soon as they tried it.
Woo, paradox (sort of
grep -1 Security
You'll get quite a lot of this:
3c501.c- Copyright 1993 United States Government as represented by the
3c501.c: Director, National Security Agency. This software may be used and
3c501.c- distributed according to the terms of the GNU Public License,
--
3c503.c- Copyright 1993 United States Government as represented by the
3c503.c: Director, National Security Agency. This software may be used and
3c503.c- distributed according to the terms of the GNU Public License,
--
3c507.c- Copyright 1993 United States Government as represented by the
3c507.c: Director, National Security Agency.
...
Oops.
Try reading it some time.
I'm sure Corel's lawyers would insist that without a license from them, that you are not even allowed to make backup copies of their proprietary software.
That also applies to GPLed code, so as soon as you take a copy of the program and give it to someone (be they an employee, a designated beta tester, or whatever) you are either doing it under the terms of the GPL, or you are violating the license. End of Story.
If I copy a GPLed program and hand it across the room to someone in the same company, the only thing that gives me the right to do that is the GPL, so by doing that I agree to abide by the GPL.
You would be in violation of the GPL if you did either of:
(rather than just mentioning that you'd rather they didn't until it was tested, and relying on their good sense)
a) did not receive the e-mail?
... ?
No (or is that Yes?). I DID receive the e-mail.
b) do you currently invest in securities?
Yes.
c) do you have the budget to participate?
Yes.
d) do you trust on-line commerce enough to put money into e*trade?
Perhaps.
e) are you unable to participate due to other restrictions? (location, contractual agreements, etc.)
Yes. I live in the UK.
And your point is
It's a risk I'd be willing to take too (apparently I cannot, being British)
/.
The quality of the offer is not what's being complained about.
They selected a bunch of people who are almost bound to be long term spam victims (I know I am), and they spammed them.
That's just stupid.
If they'd asked (on their web site) for people that were interested, and and eligible, to mail ipo@redhat.com (or some such), everyone would be thoroughly cheerful about it, and they'd have got a nice pat on the back from
I got a copy of this, and reacted pretty badly (since SPAM really pisses me off), but I've calmed down now.
In my case this is definitely SPAM, since it's a get rich quick scheme that I'm not eligible for (I live in the UK). I'd still consider it to be SPAM even if I was eligible.
I'd imagine that some pointy-haired genius at RedHat thought that a mass mailing to a randomly trawled list of contributors would be a great idea.
It reminds me of the one where Dilbert sarcastically suggests that they mass mail all their customers, and the PHB says "Do it''
What they should have done, is publish a page, saying "e-mail us with a justification of your claim to be a open source (sic) contributor, and we'll send you a password.''.
I presume they didn't want to do that, because it would have caused them work, whereas they're perfectly happy to waste thousands of other people's time, and in many cases money downloading some crappy email that doesn't apply to them.
OK, so in conclusion we have the following facts:
-- dubious research compiling the list of victims
-- disregard of other people's time/data costs, in order to save themselves effort
-- responding to the email is likely to make money for the sender
Looks like SPAM to me.
P.S. I've go no axe to grind against RedHat in general, but IMO they don't get a license to spam no matter how generally wonderful they are.
Hi Bruce,
While you may have written the scripts that were used to build ``bo'' CDs, I think we should probably credit Andreas Jellinghaus, who did an almost total rewrite for ``hamm'' (a.k.a. Debian 2.0).
I then maintained that set of scripts, but there has since been another rewrite by Steve McIntyre (for ``slink'', a.k.a. Debian 2.1), with contributions from a whole bunch of people on debian-cd@lists.debian.org.
Apart from that, you are correct in saying that the Official Debian GNU/Linux CDs contain only software that meets the Debian Free Software Guidelines.
Cheers, Phil.
P.S. rsync ? I think you mean rdist. rsync is GPL. Debian's rdist is rdist-6.1.3 (usc.edu:/pub/rdist) which is BSD.
Well, I'm using a Linux web browser, but I'm also using Junkbuster which would show up as an old version of Mac Netscape in your stats, so who knows what one can conclude from your 1%
Whenever I'm tempted to write something as brainless, and offensive as these posts (which I am on occasion), I get the following vision:
........ mean ?''
[shot fades to several decades in the future]
Old man bouncing an eight year old on their knee. Eight year old looks up and says:
``Wow, these RayBan web glasses are ace Grandpa, I'm going to look your name up on deja.com.''
Pause.
``What does
Oh dear, how embarrassing.
Remember, your email's are likely to come back to haunt you, so consider carefully how you express yourself.
I see two reasons for using the plain swirl as the official logo, and the bottle one as the unofficial:
1) The plain swirl looks better IMO, and should look great if we can get it printed onto CDs so that it covers most of the CD surface. In order to print the with bottle logo on a CD it will have to be much smaller, which is appropriate.
2) If the lone swirl is the official logo, then the with-bottle logo effectively says ``contains Debian'', rather than ``is Debian''. Also, since it's an obvious genie reference, all genie stories have something powerful (i.e. Debian) hiding in a mundane object (the product that uses Debian in an unofficial capacity).
So, I think it's the right way round as it is.
Personally, I'd much prefer that the source to the code that runs my Father's pacemaker was available to look at, and perhaps even fix. I can think of two ways of finding out that it has a Y2K problem. One is to read the source.
In every other field of engineering and science, peer review is undertaken on any serious project. So why should we allow Software Engineers to get away with it?
It's not as though the assumption of infallibility that was contained in your ``Medical Equipment'' comment was even vaguely justified.
At least you can generally trust the published breaking strain on a bolt, the same often does not hold for a line of code.
Free Software is the best mechanism anyone's come up with so far for reintroducing peer review into software development. That alone justifies it's use.
By the time I've typed this, it'll be over 70%, probably over 90% in an hour, so they'll probably discount the results, the way ``Hank'' got mostly discarded as a joke for the personality of the year vote.
The question is, does this sort of thing frighten the pointy haired types at the companies that get hit by the slashdot effect ?
If the PHB says ``set up a poll'' and the results come back so radically screwed that there is clearly no statistical value in them (rather than being bogus, but looking all right, which would be the case sans slashdot
Perhaps Hemos should send an appology for screwing thier poll up, pointing out that Internet polls are of no statistical value, whatever the result.
--
Well, given that it's meant to be ``GNU Inside'' perhaps they should be indulging in a spot of xenophilia (did I just make that word up ?)
:-)
Check the copyright, specifically:
"Freeing the Source" is copyright © 1998 Netscape Communications Corporation. It is printed here with permission from Netscape
Communications Corporation.
"Giving It Away" is copyright © 1999 O'Reilly & Associates. All rights reserved to O'Reilly & Associates and Red Hat Software.
All other material is copyright © 1999 O'Reilly & Associates. All rights reserved.
Given that copyright law relates to when one is allowed to copy something, attempting to restrict someone's use of a program once they have legally obtained a copy is not something that you can do with a copyright based software license (AFAIK).
Hence, If I download a copy of your code, to have a play with it (i.e. obtain a legal copy). Then, once I have the legal copy, it seems to me that I can quite legally use it to run my business --- I just cannot copy it further, and distribute it.
The only way to enforce this, is to get me to enter into a contract prior to giving me access to the code, in which I agree not to use the software for anything commercial.
Dan Bernsein's take on the situation is probably worth reading, since I'm not a lawyer.
My only concern with the new license, is that as it stands it seems to be saying that if code is found to infringe a US patent, they will withdraw usage rights worldwide.
Unfortunately the US patent office has a tendency to grant totally bogus patents, which would not apply outside the US because either we have more sensible patent officers, or simply don't recognise software patents to the same extent.
This gives rise to a possibility my rights to use code which is perfectly legal in my country, will be restricted because of some dubious judgement in the US.
Assuming that my reading of this is correct, I'd say this is just enough for APSL 1.1 to fail to qualify as DFSG free.
I think the most pathetic faliure I've had on a windoze box was when I upgraded my CPU from a P133 to a P200 (or something like that), and on reboot it decided that I'd changed video cards on it (which I had not), and locked up. After that, it wouldn't even go into safe mode. I ended up having to install W95 from scratch (which worked, so there was no problem with the hardware).
Meanwhile of course, the Linux installation that was also on the machine didn't even blink.
This paragraph makes a couple of assertions, that are just not supported by the evidence we see in the world.
From an evolutionary stand point, one sees that we are motivated by the interests of the genes we carry. Said interests can often be totally at odds with the interests of the individual. Take parents risking their lives for their children.
Of course, there are clearly cases where factors other than gene propagation take the primary hand: Homosexuality tends to significantly reduce one's chances of passing on one's genes, and yet it still occurs.
Likewise, the assertion that religions tend to act in favour of their adherents is also unfounded. What they tend to do is act in favour of the memes that make up the core of the religion. This can sometimes benefit the carriers of the memes, but it can also cause them extreme hardship, or even death.
In both cases, the genes and memes act in their own self interests, not out of some universal compulsion to do so, but because the ones that don't haven't survived for us to look at.
Thus there are religions who's memes result in the belivers commiting mass suicide (against the interests of the individuals, the group, and the memes), but they tend to take their memes with them.
The fact that it's ``libre'' tends to result in it also being pretty much ``gratuit'' as well, but it's entirely possible to use the GPL on software for which you charge money.
For example, I could write a program and sell copies of it for $1000.00, licensed under the GPL. It's possible that my customers might decide not to give away the source that they have, until someone else does, because they might think that it would somehow devalue their investment.
Eventually, I could expect someone to publish the source either more cheaply then me (or even for free), at which point my ability to charge some of my potential customers $1000.00 would evaporate, but there would probably still be people willing to pay the price, because they are too clueless to realise that it was available for free, or think that there is something special about getting it direct from the author.
I remember thinking of schemes like this when I first came across the idea of Free Software. I've been thinking about it ever since (about 14 years) and have concluded that they won't work. Given that I make my living out of supporting Free Software, this is not simply an intellectual exercise for me.
The problem is that people are generally not motivated to write good software by money. There is quite a body of evidence that offering monetary incentives to programmers tends to reduce quality, as the programmers start putting effort into working the system, rather than coding. Obviously, people are paid to code, but the money is rarely the direct motivation for doing a good job.
He does touch on one of the primary motivations for commercial programmers contributing to Free Software, which is that it is often cheaper to add the features you want to an existing Free program, than to write, or buy something else.
Anyway, an interesting article, but it's fundamentally flawed in its assumption that COSS falls under the wing of Free Software.
Clause 6 of the DFSG (a.k.a. OSD) prohibits licenses that discriminate against specific fields of endeavour (such as making money, for example).
Even if that were not the case, DFSG compliant licenses must allow derived works (clause 2) which would mean that you could derive a work which differed only in the person to whom the money should be sent, which would instantly destroy the structure he's trying to build.
His ideas also seem to fall foul of the fact that you can do what the hell you like with legally obtained software, so the ``are you using it enough to pay for it ?'' stuff might be interesting to enforce, and certainly wouldn't result in a DFSG license.
On the subject of allocating points, I'd be stunned if anyone could come up with a scheme that would appropriately reward someone that spends six months tracking down an obscure (but serious) bug (say an intermittent networking bug).
Say you allocate 5 points (it's only bug fix, after all) and the contributor says ``that's not enough, I spent six months finding that bug!'' --- You end up with all the silliness of having to do a clean-room reimplementation of the fix ? Oh dear, oh dear.
The test iso's are exactly that --- test images.
The real ones are being built right now, but it takes a while, and obviously could not start until the mirror had updated, which also took a while.
If you already have the test images, the final ones should be fairly close to those, so help save some bandwidth by using rsync to get the new ones.
slink1 is most of main's binaries
slink2 is the rest of main, and the contrib binaries
slink 3 & 4 are the source.
check out http://www.debian.org/distrib/vendors for alternate vendors.
Being realistic, it'll probably take 24 hours before the CD images get out to most of the mirrors, so please bear with us.
Cheers, Phil.