dismiss all the points the article raises without addressing any of them
Do actually do that, I'd have to find the points first, which would require wading through way too much irrelevant character assassination and blind assertion to be worth my time. If you say there are real points worth discussing hidden there, I'll take your word for it; but don't expect me to do the writer's job for them.
A cantankerous and finger-wagging freewheeler, Stallman won't comment on any of this because he was upset by a previous story written by this writer.
Right, because all this writer does is spout vitriol and spread fear, uncertainty and doubt all in an apparent attempt to garner page views. It's no wonder RMS doesn't have time to respond to such a writer. [In fact, I've discovered that I don't have time to finish reading this article either.] One wonders why McVoy even bothered to respond.
Anytime a GPLed work has such a clickwrap, it's trivial to patch the work such that it no longer displays the clickwrap. Most distributions (I know Debian does in a few cases) should be doing this already, because clickwraps are annoying and generally get in the way of users actually using the programs that they have installed.
The difference is that Debian doesn't ever distribute the Official Use Logo in main. [It's even more doubtful that anyone would know what the official use logo is anyway, unless they already were a serious Debian user or recently visited the logo page.] (And really, no one in Debian is arguing with Mozilla's right to enforce their trademarks. We'd rather they didn't, but it's their decision to make. Once they've made it, Debian doesn't have a choice. We have to change.)
Kelsey (the FDA scientist that evaluated thalidomide) had an amazing luck: She was given something that was actually very harmful. She was pressured by both the company and her superiors to just approve it, but she didn't give in. She became a hero when the truth was known
This is a bit disengenous, as thalidomide has specific effects (primarily by blocking angiogenesis) and is quite useful in individuals who have leprosy and won't be undergoing angiogenesis (that is, they are adults.) In other words, unless your a fetus or embryo undergoing vasculogenesis or angiogenesis, it may not be harmful.
Understanding the effects of chemicals is best done by studying them. When there is reasonable evidence that they may be harmful, we should be cautious, but when repeated experimentation into the effects has been done and no evidence has been obtained, attempting to insight public panic over them is counter-productive.
There's been complaints for years and years at Mozilla over the dubious quality of some of the Debian patches, not to mention the very large amount of them (Debian users have a hard time getting support in the Mozilla IRC channels because there's a thousand and one new weird issues that are unique to Debian), and that's directly helped shape the policy that the trademarks can only be used with unaltered products, or with the alterations directly vetted.
Users of Debian are always encouraged to get support using the distribution's support paths, and to file bugs against the bts. We recognize that we make changes that may not be in the line that upstream expects, and that's why we filter bugs before sending them upstream.
As far as patches go, vague complaints about them have been made from time to time, but never with specific bugs and/or information about specific patches. It's not like we hide our firefox patches either. Feel free to check them out and file bugs if you find ones that are outdated or invalid; I'm certain that Eric would appreciate insightful responses.
According to the DFSG, they'd have to keep it in nonfree if they wanted to keep the name.
This is much less a questinon of where we distribute it, but instead a question of whether we can distributed it at all. [Trademark law applies no matter where it is distributed.]
No, the freedom preserved has always been that of the code. That is how it is different than BSD licenses or similar. Were the freedom truly the user's, there would be no obligations on whether or not they might have to give any change they make back or how they have to license something they create that may link to a GPL product.
The code has no use for freedom. It's not sentient, and therefore can't exercise freedom anyway. Freedom is primarily for the users of the code, so that they can modify the code as they see fit, and deploy those modifications. The requirement of giving changes back only applies to those to whom their modifications have been deployed. The GPL doesn't require that you send your modifications back to the original author.
The GPL is used as a lever, to try to force as much code that it can into allowing the user to have the freedom to modify it. In the cases where it fails to do so, such as DRM and/or Tivoisation, it's viewed as a failure of the license.
Not at many institutions that grant PhDs, and almost never in the sciences. (A masters degree is often the equivalent of 3/4 of the coursework for a PhD, with a fifth or less of the research.) [Yes, I'm a PhD student who currently does not have a masters... although, I suppose if I filled out the paperwork I could get one now.]
If you don't want perl in your imagemagick, don't install perlmagick. For the most part, when it makes sense to split out parts of a particular package, or have flavors of them, they're already built in Debian. When you think they do make sense, and they aren't, you can easily file wishlist bugs or compile them that way yourself. [apt-get build-dep foo; apt-get source foo;; munge configure options; fakeroot debian/rules clean binary is really all it takes.]
But solar powered boats can go in any direction with the same efficiency.
They're still subject to the waves and currents just like any other boat... and there are many places where the currents exceed 5 knots.
Sailboats for the most part do best on a broad reach.
While this is true for almost every boat, many high performance boats exceed windspeed when they are on a broad reach. Even for cruisers, it's not unusual to do 70-90% of windspeed, even upwind. [In normal trade conditions, that generally means 9-15 knots.]
And solar can power batteries for when there's no sun. I've never seen a wind battery for when there's no wind.
There are only a few places in the oceans where there is consistently no wind (the doldrums). If you're a marginally competent navigator and weatherman, you can pretty much tell where there's going to be sufficient wind on the ocean, and where there isn't. [And given the far superiour speed of modern sailboats, even if you are becalmed half the time, you'll probably still beat the solar powered boat.]
Aren't the 'GM' crops really just an extension of grafting and selective breeding that has been going on for thousands of years?
At what point would a fish and fruit mate?
Mating between species or varieties is not what is at issue here; that's a completely spurious objection. An appropriate question is whether there would ever be exchange of genetic material between the organisms in question. Considering the fact that it is relatively easy to get viruses to encapsulate various parts of plant and/or animal genomes, it is not inconceivable that genetic material could be shared across animal kingdoms. Indeed, many plants are quite capable of pulling in genetic material from almost anywhere. Indeed, that's how these transgenic plants are made in the first place.
You taking two or more genes from thing that would in no way be able to be breaded through natural selection.
Natural selection is an entirely separate process from the transfer of genetic material across species or from parents to offspring; bringing it into a discussion of transgenic plants and animals is nothing more than a red herring.
That being said, it is important to carefully examine and test the plants that we select for human and animal consumption, but that's something that is required even for "natural" food sources.
That's a question only UCLA and the researchers can
really answer, by providing us with the information about what the
research was. They refuse to do so.
You're talking about scientific research. The whole point of
scientific research (or at least the type of research done at public
universities like UCLA) is to publish. Exactly what research they were
doing is easily available via pubmed; if you don't happen to be on a
campus with a subscription, you can visit your local university and
look at the hard copy of the 28 publications that this
indvidual has actually authored.
Would it advance the overall level of freedom if the
customer were unable to purchase the product in question, but instead
had to rent it from the manufacturer, signing a contract that would
make him subject to a heavy fine for replacing the software? Would
that be compliant with the GPLv3?
If you don't own the hardware or you decide to limit the rights
that you have by signing contracts, there is little the GPL can do to
help you. At most it can restrict its use in such environments; it
doesn't do so currently because this is at odds with Freedom 0.
Or to look at this from a slightly different angle, how
about putting the software in an SMD ROM chip with a blob of glue on
top? That is compliant with the GPLv3 (see the link I posted in
another response on this thread). Whose freedoms does that
protect?
There are definetly use cases where people can use GPLed works in
such a way that users are unable to exercise the freedoms that the GPL
tries to guarantee. It's clearly not a perfect license. The current
draft of v3 goes farther to try to protect those freedoms, but even it
is unable to do so completely.
At some level the licence has to strike a balance between
protecting the freedom of users to modify GPLed works and the freedom
of distributors to deploy GPLed works in any way that they want. The
GPL has always been about this compromise, and the section on DRM and
TPM is attempting to finely adjust this balance by allowing
"legitimate" uses of DRM while disallowing uses which curtail user
freedom.
If you think the license has the balance wrong, comment on it at http://gplv3.fsf.org. I've personally
spent dozens of hours agonizing over this very issue (I'm on Committee
D, in case it wasn't clear.) You can see what else I've written on it
(and the draft of what I supplied to the FSF for the first draft)
here: http://svn.donarmstrong.com/don/trunk/projects/gpl v3/issues/drm_allowing_authentication/.
2. locked FOSS-using devices (the Tivo scenario)
I think the FSF, and software developers advocating GPLv3, are
seriously overstepping their bounds here. Basically, they're telling
hardware developers that in order to use FOSS, not only do they need
to give freely what they freely received (which is just reasonable),
but they also have to make THEIR OWN product convertable to any use
their customers see fit.
Didn't their customer purchase the product? Why shouldn't I as a
consumer be able to modify a product that I've purchased to implement
whatever fixes or features I want the product to run?
This immediately excludes building devices that need to
assure overall system integrity (from fair network gaming through to
voting machines)
This is actually not true (or at least, not the intention.) Being able
to verify that you're running a specific binary on the machine is
quite reasonable, however the end user has to be able to disable this
if they want to run their own software (possibly disabling their
extended warranty or whatever.) In the cases where the GPLv3 disallows
verification when the user agrees with it, the current draft is buggy.
Alternatively, they can choose to make their machines
physically tamper-proof (which defeats the intent of the license,
makes the license unverifiable, and the product unrepairable in case
of software problems).
It's basically impossible to do this; in the cases where it actually
matters, the proper method is to make the hardware device tamper
evident, not tamper proof. [Think voting software; where if you
wanted to have a DRM or TPM device, you set the jumper to enable it;
then seal the box with a voter and voting official verifiable seal
and/or lock on the case.]
The net result will simply be that hardware developers
will stop considering the use of FOSS, which will lead to them getting
what they want anyway, FOSS code getting less exposure and less fixes,
and end users receiving an arguably less technologically sound product
at a higher price.
Assuring user freedom is far more important to the FLOSS community
than companies who do not buy into the basic philosophy of FLOSS being
able to lower their development costs by using it. In the long run, if
companies are not interested in contributing to the movement, that's
fine. Interested volunteers who already do the work will
continue on doing the work.
The story title is a bit misleading; only accounts with bad passwords or those who (for $DEITY knows what reason) appeared to have private keys on gluck were locked out. Everyone who has sane passwords and/or only uses ssh keys to log into their accounts still have access.
Of course, anyone who could actually log in already knows this because they've read d-d-a (or have already logged in.) In any event, rather troubling that the PRCTL bug managed to find its way into the kernel, but good that the intrusion was caught relatively quickly and neutralized.
If you're a distribution who is derived from Debian, or derived from a derivative of Debian, there's no excuse for not complying with GPL 3a when you're distributing electronically, or 3b when you're distributing physically without making the source code equivalently available.
It's a simple as mirroring the diff.gz, orig.tar.gz, and.dsc of every package that you're distributing the.deb of. If you've modified the package, you've generated a new orig.tar.gz and a new diff.gz in the process; if you're using dak, you even had to send these to the archive in order for it to accept them. [If not, hopefully you're at least using something that makes sure you've uploaded all of the debs that you've built to your archive and checks the md5sum of them in the.dsc]
This isn't exactly a new problem, and it's one of the reasons why it's so trivial in Debian to get access to the source, and why all of the mirror scripts that Debian distributes also mirror the source.
I have worked with both dpkg and rpm, and there is no
question: rpm is vastly superior to dpkg, when it comes to building
packages, checking what package a file belongs to, or verifying the
installed software (can't do it with dpkg).
Lets take these claims one at a time, shall we?
building packages Lets see, to build a package we just
run apt-get build-dep foopkg; apt-get install build-essential
fakeroot; apt-get source foopkg; cd foopkg-*; fakeroot debian/rules
binary;. Hrm. That wasn't so hard...
checking what package a file belongs to Is the package
installed? Ok, dpkg -S foofile; Not installed?
apt-get install apt-file; apt-file update; apt-file search
foofile; Not running Debian? Visit packages.debian.org and search
for a file.
verifying installed softwarecd/; md5sum -c/var/lib/dpkg/foopkg.md5sums|grep -v OK. Too hard? Install
debsums and use it intsead.
Gee, I think all of these things can be done fairly easily using dpkg.
[Dunno how difficult they are to do using rpm, or why you had a hard
time figuring them out... they're all covered in the introductory
reference manuals on Debian.] The only claim that is even marginally
defensible is that package building is superior, but that's because
dpkg itself has nothing to do with building deb packages.
That's done using dpkg-deb (and more typically the sane frontends to
it).
Now, if I wanted to be truly evil, I'd just point at this rpm bug...
Lets call it spreading confusion then. (Or our esteemed editors spreading confusion in your name.)
On the other hand, your smug level is off the scale.
Perhaps, but reading summarizations of (important) scientific research which are inaccurate or promise far more than the research has in fact provided is really annoying to those who work in the field. This wasn't as bad as most, but definetly wasn't ideal.
The ability to return a cell to metaphase upon the removal of a chemical (Flavopiridol) which causes the mitotic exit of cells which are expressing non-degredatable Cyclin B is interesting, but it definetly tells us nothing about how to reverse this process in non-transformed human cells. The press release is a bit too effusive about the potential of this finding to radically transform the treatment of cancer, etc. as the finding primarily recomfirms the hypothesis that the degredation of cyclin B is what gives directionality to the cell process, and by blocking the degredation of Cyclin B, you can reverse the cell cycle.
And just in case you're confused like the submitter, there's way more than one protein involved in the cell division process in any eukaryotic cell; Cyclins like Cyclin B are very important, but it's a whole host of proteins that are involved in ushering the cell from G1 to S to G2 to M; assuring alignment, proper exit, arrest upon damage, etc. [One could even argue that the whole point of most cells is to divide, and so every bit of the cell is important and/or participates in some way in the process...]
Embronic stem cells from blood in umbilical cords: yes
These are not embryonic stem cells.
Embryonic stem cells come from the inner cell mass of a morula, 3.5-4 days after fertilization. They have nothing whatsoever to do with HUVEC (human umbilical vascular endothelial cells) or the hematopoetic stem cells which are used in the treatment of some hematopoetic disorders.
By their very nature, they are pluripotent cells. (These cells are NOT totipotent. This is because they DO NOT make placenta... therefore they are at most pluripotent.)
As others have pointed out, the study looked at rates of decline relative to initial performace, as opposed to examining the performance of individuals after 5 years of AD.
The tremendous benefits of cross-platform compatibility come from a package's interface being exactly the same on every system. It is a relatively minor benefit for different packages to have similar interfaces. Breaking cross-platform compatibility, as Debian does, for the sake of cross-package similarity is a horrible idea.
I should point out that I'm picking on Debian here because they are especially bad about this, but almost every major Linux distribution is guilty of unncessarily violating cross-platform compatibility in some way.
The FHS is what defines "cross-distribution" as well as "cross-package" compatibility. Packages that choose to stick things in locations which do not comply with FHS are broken. It's the job of distributors to fix these issues, and then try to get them accepted upstream. Our users expect packages to follow the FHS. If you'd rather have something else, well, feel free to use another distribution or LFS or something.
Slashdot Mirror
Anytime a GPLed work has such a clickwrap, it's trivial to patch the work such that it no longer displays the clickwrap. Most distributions (I know Debian does in a few cases) should be doing this already, because clickwraps are annoying and generally get in the way of users actually using the programs that they have installed.
The difference is that Debian doesn't ever distribute the Official Use Logo in main. [It's even more doubtful that anyone would know what the official use logo is anyway, unless they already were a serious Debian user or recently visited the logo page.] (And really, no one in Debian is arguing with Mozilla's right to enforce their trademarks. We'd rather they didn't, but it's their decision to make. Once they've made it, Debian doesn't have a choice. We have to change.)
Understanding the effects of chemicals is best done by studying them. When there is reasonable evidence that they may be harmful, we should be cautious, but when repeated experimentation into the effects has been done and no evidence has been obtained, attempting to insight public panic over them is counter-productive.
As far as patches go, vague complaints about them have been made from time to time, but never with specific bugs and/or information about specific patches. It's not like we hide our firefox patches either. Feel free to check them out and file bugs if you find ones that are outdated or invalid; I'm certain that Eric would appreciate insightful responses.
The code has no use for freedom. It's not sentient, and therefore can't exercise freedom anyway. Freedom is primarily for the users of the code, so that they can modify the code as they see fit, and deploy those modifications. The requirement of giving changes back only applies to those to whom their modifications have been deployed. The GPL doesn't require that you send your modifications back to the original author.
The GPL is used as a lever, to try to force as much code that it can into allowing the user to have the freedom to modify it. In the cases where it fails to do so, such as DRM and/or Tivoisation, it's viewed as a failure of the license.
They're still subject to the waves and currents just like any other boat... and there are many places where the currents exceed 5 knots.
While this is true for almost every boat, many high performance boats exceed windspeed when they are on a broad reach. Even for cruisers, it's not unusual to do 70-90% of windspeed, even upwind. [In normal trade conditions, that generally means 9-15 knots.]
There are only a few places in the oceans where there is consistently no wind (the doldrums). If you're a marginally competent navigator and weatherman, you can pretty much tell where there's going to be sufficient wind on the ocean, and where there isn't. [And given the far superiour speed of modern sailboats, even if you are becalmed half the time, you'll probably still beat the solar powered boat.]
That being said, it is important to carefully examine and test the plants that we select for human and animal consumption, but that's something that is required even for "natural" food sources.
When? Still in transit
Ah... the wonders of checked baggage.
If you don't own the hardware or you decide to limit the rights that you have by signing contracts, there is little the GPL can do to help you. At most it can restrict its use in such environments; it doesn't do so currently because this is at odds with Freedom 0.
There are definetly use cases where people can use GPLed works in such a way that users are unable to exercise the freedoms that the GPL tries to guarantee. It's clearly not a perfect license. The current draft of v3 goes farther to try to protect those freedoms, but even it is unable to do so completely.
At some level the licence has to strike a balance between protecting the freedom of users to modify GPLed works and the freedom of distributors to deploy GPLed works in any way that they want. The GPL has always been about this compromise, and the section on DRM and TPM is attempting to finely adjust this balance by allowing "legitimate" uses of DRM while disallowing uses which curtail user freedom.
If you think the license has the balance wrong, comment on it at http://gplv3.fsf.org. I've personally spent dozens of hours agonizing over this very issue (I'm on Committee D, in case it wasn't clear.) You can see what else I've written on it (and the draft of what I supplied to the FSF for the first draft) here: http://svn.donarmstrong.com/don/trunk/projects/gpl v3/issues/drm_allowing_authentication/.
This is actually not true (or at least, not the intention.) Being able to verify that you're running a specific binary on the machine is quite reasonable, however the end user has to be able to disable this if they want to run their own software (possibly disabling their extended warranty or whatever.) In the cases where the GPLv3 disallows verification when the user agrees with it, the current draft is buggy.
It's basically impossible to do this; in the cases where it actually matters, the proper method is to make the hardware device tamper evident, not tamper proof. [Think voting software; where if you wanted to have a DRM or TPM device, you set the jumper to enable it; then seal the box with a voter and voting official verifiable seal and/or lock on the case.]
Assuring user freedom is far more important to the FLOSS community than companies who do not buy into the basic philosophy of FLOSS being able to lower their development costs by using it. In the long run, if companies are not interested in contributing to the movement, that's fine. Interested volunteers who already do the work will continue on doing the work.
The story title is a bit misleading; only accounts with bad passwords or those who (for $DEITY knows what reason) appeared to have private keys on gluck were locked out. Everyone who has sane passwords and/or only uses ssh keys to log into their accounts still have access.
Of course, anyone who could actually log in already knows this because they've read d-d-a (or have already logged in.) In any event, rather troubling that the PRCTL bug managed to find its way into the kernel, but good that the intrusion was caught relatively quickly and neutralized.
If you're a distribution who is derived from Debian, or derived from a derivative of Debian, there's no excuse for not complying with GPL 3a when you're distributing electronically, or 3b when you're distributing physically without making the source code equivalently available.
.dsc of every package that you're distributing the .deb of. If you've modified the package, you've generated a new orig.tar.gz and a new diff.gz in the process; if you're using dak, you even had to send these to the archive in order for it to accept them. [If not, hopefully you're at least using something that makes sure you've uploaded all of the debs that you've built to your archive and checks the md5sum of them in the .dsc]
It's a simple as mirroring the diff.gz, orig.tar.gz, and
This isn't exactly a new problem, and it's one of the reasons why it's so trivial in Debian to get access to the source, and why all of the mirror scripts that Debian distributes also mirror the source.
Gee, I think all of these things can be done fairly easily using dpkg. [Dunno how difficult they are to do using rpm, or why you had a hard time figuring them out... they're all covered in the introductory reference manuals on Debian.] The only claim that is even marginally defensible is that package building is superior, but that's because dpkg itself has nothing to do with building deb packages. That's done using dpkg-deb (and more typically the sane frontends to it). Now, if I wanted to be truly evil, I'd just point at this rpm bug...
The ability to return a cell to metaphase upon the removal of a chemical (Flavopiridol) which causes the mitotic exit of cells which are expressing non-degredatable Cyclin B is interesting, but it definetly tells us nothing about how to reverse this process in non-transformed human cells. The press release is a bit too effusive about the potential of this finding to radically transform the treatment of cancer, etc. as the finding primarily recomfirms the hypothesis that the degredation of cyclin B is what gives directionality to the cell process, and by blocking the degredation of Cyclin B, you can reverse the cell cycle.
And just in case you're confused like the submitter, there's way more than one protein involved in the cell division process in any eukaryotic cell; Cyclins like Cyclin B are very important, but it's a whole host of proteins that are involved in ushering the cell from G1 to S to G2 to M; assuring alignment, proper exit, arrest upon damage, etc. [One could even argue that the whole point of most cells is to divide, and so every bit of the cell is important and/or participates in some way in the process...]
Embryonic stem cells come from the inner cell mass of a morula, 3.5-4 days after fertilization. They have nothing whatsoever to do with HUVEC (human umbilical vascular endothelial cells) or the hematopoetic stem cells which are used in the treatment of some hematopoetic disorders.
By their very nature, they are pluripotent cells. (These cells are NOT totipotent. This is because they DO NOT make placenta... therefore they are at most pluripotent.)
Education and rates of cognitive decline in incident Alzheimer's disease
N Scarmeas, S M Albert, J J Manly and Y Stern
Full text Abstract pdf
As others have pointed out, the study looked at rates of decline relative to initial performace, as opposed to examining the performance of individuals after 5 years of AD.