The nice thing about GPLv2 was that it was just about readable by the average human, written by people with fairly clear ideals wanting to get across a message. Now it's the culmination of special interests, reading like something designed by committee, dealing with such contemporary minutiae as to confuse anyone coming to Free software development after a few months from now, while completely turning off any of the "Just click Next until the damn software installs" crowd. GPLv3 will have nothing like the staying power of GPLv2.
Firstly, the Free Software movement has ballooned massively since 1991. It wasn't even a dot on the landscape back then. Now it's a movement whose ideals are sweeping the world, and have diversified into the arts, law, and legislation too. According to Eben Moglen at a recent talk in Edinburgh, over ten thousand people were directly involved in the process of designing the license. It was designed by a committee -- and a very large one!
Secondly, there are many parties who are desperately intent on finding chinks in the armour of the Free Software movement. As we've seen with Microsoft and their recent unsubstantiated patent blustering.
Unfortunately, the English language is an imprecise tool, and there are about 192 countries where the license has to be legal, and uphold the idea of Free Software, and have as few exploitable holes as possible. It's a bit like writing a tool that has to run on x86, x86-64, MIPS, SPARC, ARM and Power when you have to write in assembly. It's going to be long, and it's not going to be as neat as you'd like.
Re:tivoisation
on
GPLv3 Released
·
· Score: 3, Insightful
There should be no expectation that a manufacturer make its hardware available for third party development.
Proprietary systems have there drawbacks, but they are a fact of life. If one has an issue with the fact that a given consumer
device is a closed platform, one ought not purchase the device. This ought to be how the issue of so-called Tivoization ought
to be decided, by making the business model non-viable for the company, not some poorly constructed, arbitrarily defined licensing
scheme that restricts only the freedom of some, and not all. The fact that there is a "commercial device" exception indicates
that the case for so-called Tivoization has a valid application and should therefore be allowed. Banning the practice for
"consumer devices" is simply an arbitrary confinement of freedom that is a slippery slope.
The clauses in the GPL v3 simply say: "If you use my software, for free, to create a device which you then sell back to me at a steep price, I'd better bloody well be able to put any further modifications I make to that software onto said device. Furthermore, because I think that's pretty neat, I'd like you to extend that ability to your other customers too. If you don't like it, write your own damn software."
I paraphrase and over-simplify, but the gist is there. It's not legislation, banning the practice generally. It's very specific.
The user is a casino, the box is a slot machine. If someone accuses them of cheating (which will happen), it is great for them if they never had any ability to modify the code in the first place.
There are such a thing as ROM chips, and there are such a thing as tamper-proof stickers. This is a good example of a situation in which both would be appropriate, and compatible with both the relevant legislation and the GPL v3 (neither vendor nor user has ability to change code after delivery).
Secondly, as you mention, both of the examples you give do not fall within the category of "consumer product" as defined by the GPL v3, and therefore the Tivoisation sections don't apply. I should probably have mentioned this when posing my challenge!
As I mentioned in another posting, the gaming problem is pathological, and I repeat my response to the other poster: do you you really want to be a member of a community where the problem of cheating is such an issue that you need to surrender your freedom to cope with it?
Re:tivoisation
on
GPLv3 Released
·
· Score: 2, Informative
Jesus Christ, I've mentioned it twice already: networked multiplayer games. Because I can't run a modified executable on my machine, I can't cheat, and neither can anyone else.
Fair point. And although you might (probably should) agree that this is a pretty pathological example, I did only ask for one!
My response would be to ask whether a community so rife with anti-social behaviour is one which you want to be part of, but I suppose you've already answered that question too.
Re:tivoisation
on
GPLv3 Released
·
· Score: 4, Informative
Allow me to make some introductions: Peter, meet BSD. BSD, meet Peter.
Oh yes, GPL3 anti-Tivoisation clause, meet irrelevance and backlash.
I suspect that you don't understand what I'm talking about.
Quite a lot of open-source software (or at least user-written software) has been created in response to the encroachments of Digital Restrictions Management on the abilities of users to view the media which they have purchased in the false belief that such purchase entitles them to view where and when they like.
Requiring general-purpose consumer computer equipment to prevent code unsigned by the vendor from being run provides a number of benefits from the point of view of both the media cartel and large software companies:
Lock-in of consumers to "approved" software is easier, increasing sales and thus profits for a small number of "certified" vendors.
Pernicious anti-DRM tools can be stopped at source.
Market barriers to entry are greatly increased, reducing profit-limiting competition.
Sony, in their position as a vendor of "trendy" hardware but also as a major stakeholder in the media market, is in the ideal position to introduce such a device, and I would expect them to do so within the next two years or so. Assuming Microsoft survives the damp squib that is Vista, I would expect the device to be announced jointly by the two players as a new "secure mobile computing platform" (not marketed as a "traditional" PC).
Software vendors would be able to acquire signing keys (relatively) easily, but they would not be available for operating systems and would likely require small per-user fees in order to squash out open source software. In addition, a Sword of Damocles contract would be required, whereby distributing software later found to be non-compliant with the terms of the signing key contract would result in all software signed with that vendor's key to be remotely deactivated.
Your mention of BSD is entirely irrelevant in the context of my GP comment, so (at the risk of being accused hypocritical) I respectfully suggest that you shut up and stop being a condescending moron.
Re:tivoisation
on
GPLv3 Released
·
· Score: 4, Insightful
Likewise, my Tivo is my computer. It's running in my house. It's connected to my network. I have a right to know what it's doing. Would you be as forgiving of a builder who wouldn't let you keep a copy of the plans to your house? Would you tolerate a car dealer who's welded your hood shut? It's your house. It's your car. You have a right to know where the plumbing goes. You have a right to look at the engine.
Actually, this is a poor analogy. In defense of Tivo, they are very good about complying with the letter of GPL v2 in that they distribute the sources to all of the GPL software that they use.
Another way of looking at it is this (I don't have a Tivo, but hopefully my argument will make sense). Suppose you have a great idea for a way to improve the way the Tivo interface works for you, and you see that the modifications you need to make to the code which Tivo distribute to you are quite trivial. However, when you send the patch to Tivo they tell you they won't implement it because the business case doesn't support it -- you're the only one of their customers likely to use such a change. Then you're left hanging: as you mentioned, you own a more or less generic computing device and now you also have some code to run on said computing device, but you're at the whim of a third party (non-enforceable EULAs notwithstanding) as to whether or not you can put those two components together.
As many people have pointed out, the right to make modifications and improvements and to use said modifications and improvements is pretty fundamental to the whole point of Free Software, and that's exactly what Tivo have been trying to get around.
I agree that they need to be stopped, and I support the GPL v3 in its strategy to deal with this.
Re:tivoisation
on
GPLv3 Released
·
· Score: 3, Interesting
In general, it's often good for networked devices (other than general-purpose computers) to only run signed code, because it makes it significantly easier to guarantee network stability. So even if we accept that there are cases where Tivoisation is bad, and that the FSF ought to try to prevent them, we're left with the fact that it can only do so with a broad brush, eliminating a lot of good uses along with a lot of bad ones. They're taking away as much freedom for the user (freedom to use GPLv3 on their trusted platform while maintaining that trust) as they're giving.
Surely having code signed by the owner achieves the same results in this case as having code signed by the vendor, assuming that the owner is not stupid enough to keep the private key for the signing process on the box which they are requiring to run signed code?
I challenge you to provide me with one example of a case where using the user's key to sign the code running on their box is inferior to the same box running the same software signed by a vendor key which the user does not have access to.
Re:tivoisation
on
GPLv3 Released
·
· Score: 5, Informative
But, let's be realistic. It would be absolutely impossible to Tivoise all general-purpose computers.
That is exactly what the likes of Microsoft and Sony want to do for anything consumer-available.
And it's not like you couldn't build your own.
They want to stop you from doing that too (or at least make it economically infeasible).
3) The plane has almost completely electric, without the high-pressure pneumatic systems that older planes had. In particular, the AC systems are electric. This will be somewhat more efficient, and safer.
Although I can't comment on the safety point, I'd be interested in seeing some numbers that support the claim that electric air conditioning is more efficient that the thermodynamic cycle currently used for aircraft air con.
At the end of August, all user accounts will be deleted; just because it hasn't happened yet doesn't mean it's not in the works.
Unless, of course, it was last summer's vacation spent on discussion2 and these other changes, in which case the deletion of user accounts may also take nine months to roll out.
Of course, he could now be living in the southern hemisphere.
The thing that irritates me most is installers that force you to read and agree to a Free Software license before using the program. Free Software licenses are distribution licenses, not EULAs, and so there is no need to agree to them, or even read them, before using the software.
The "NO WARRANTY" part of the GPL *should* be in a EULA-type window, IMHO.
Suggesting that there is a younger generation of programmers emerging that are not as pissed off by Microsoft as their elders believe. Perhaps - just perhaps - the beginnings of an adolescent rebellion against the middle-aged spread, the predictable pieties of free and open source.
Bahahahahaha. Every capable young software engineer I know here at Cambridge University uses and codes for Linux. In fact, make that every young software engineer I know. Because it's easy to get and set up development tools on Linux and they have good documentation, and you can actually get help when you have a problem. As an engineer (a real one), I'd choose Linux (or possibly *BSD) as a development target whenever possible, because getting fast, small, portable programs written is orders of magnitude easier than I found it to be on Windows (when I last bothered to try).
Photoshop - You're unlikely to replace that one. Although, someone else mentioned Pixel which could possibly cut the mustard depending on your needs. Otherwise, there really is nothing to compare to Photoshop.
I usually use Krita, which is really really good, supporting several different colourspaces, as well as having a more Photoshop-like interface than most open source editors. It also integrates really nicely into KDE, which is a big plus for me.
And last I heard most if not all of the major 3D CAD softwares don't run natively on Linux.
Cambridge University Engineering Dept does all 3D CAD teaching using Pro Engineer. On Knoppix boxes with NVidia graphics hardware. It runs very fast, even with moderately complex models.
I manage a 7 GB CVS repository serving 200 developers and you are totally wrong. If I could get buy-in from the 10 or 20 relevant stakeholders I would change to mercurial in a pinch.
The GPL Electronic Design tools project will be moving to git soon. Unfortunately, not all of the developers are on platforms supported by git (and others just don't like git), so there is going to be a git-cvsserver set up to support them. This is generally considered to be a good way to do gradual migration.
I think you just described git - I can do all of that in git.
Faster and with less faff than using *any* other version control system I've tried. However, MKS Source has some really nice features... shame it's so expensive, really!
It takes TIME for an ANSI or ISO standard to be created. If ODF were to undergo this process it would create the impression that it was a rough or draft standard that had yet to have all the edges polished and kinks worked out.
ODF has already gone through this process. It is already an ISO standard (ISO 26300, IIRC). The vote was on whether the ISO standard should also be adopted as an ANSI standard.
I know your comment was meant to be amusing but I think you've actually come up with a very good idea. If the OS could signal somehow to the app that its getting close to its limit and to either reduce its resource usage (of memory , IO whatever) or it'll get suspended/killed etc. I wonder if this has been implemented anywhere?
There's nothing wrong with making malloc() fail for certain programs which are using vast amounts of memory. Anything using truly colossal amounts of memory should have implemented a way of coping with that... and those that don't will die, freeing up lots of memory.
AudibleMagic claims to have invented an algorithm that can recognize the same video in different forms better than the human brain can, across any format? That must mean the video is decoded into it's component frames before hashing, since that's how our brains get it. And better yet, this "Hash-Every-Frame" routine (which is apparently better than any other by leaps and bounds) will run on a site the size of MySpace without a BlueGene/L driving it? Uh-Huh. Say, NewsCorp, I've got this old bridge...
I reckon it wouldn't be too difficult to implement, actually. First, there's no need to examine every frame; one in every 50 would probably be enough. Then, the procedure is probably as follows:
Convolve the image with a Laplacian of a Gaussian to identify interest points ("blobs"), say at two different scales. Compression artefacts mean that there probably wouldn't be any point in trying to identify features smaller than say 1/8 of the height of the frame, and that will probably give you enough points anyway.
Around the features identified, use a low-pass filter to identify edges, and create a histogram of edge directions in the vicinity of the feature, scaled by normalised distance from the centre of the feature.
Normalize each histogram by orientation and magnitude. You now have a set of values (usually around 128) which identify that feature in a way which is robust to rotation, scaling, changes in brightness/contrast and changes in colour (this is called a Scale Invariant Feature Transform, or SIFT, descriptor). Take say 3 or 4 principle features per frame examined, and put them in a database.
Any video which has more than 5 frames in a row which match a series of 5 frames in the database is a positive match. This corresponds to ~10 s of video. It would be possible to use algorithms developed in bioinformatics to optimise your database for that kind of search.
The false positive rate from such a system would be negligible, and robustness and accuracy could easily be increased by recording more features from each frame. This is a mature technology, and it's been designed for much harder computer intelligence tasks than the one described.
Oh well, it doesn't affect me either way; I have cable at home, and use a non-verizon Cellphone. I have not had a land line since 1996 since I detest Verizon. Why should I speak up on the matter since it doesn't affect me?:-p
I think Martin Niemöller said it best:
When the Nazis came for the communists,
I remained silent;
I was not a communist.
When they locked up the social democrats,
I remained silent;
I was not a social democrat.
When they came for the trade unionists,
I did not speak out;
I was not a trade unionist.
When they came for me,
there was no one left to speak out.
music 600 years ago was....primitive.
Its not classically the classical period.
Music was often tones with word on it, but not in a way that flowed with the music.
WRONG. I'm a member of the Schola Gregoriana of Cambridge, and we specialise in singing music from between the 10th and 17th centuries, primarily Gregorian song (the original music of the Catholic Church, sometimes called "plain chant"). Several of our members are researchers who study ancient manuscripts to find out about music in the dark ages and the early rennaissance, and believe me; this stuff really doesn't deserve it's reputation for being "primitive". Unfortunately, the rubbish these people have come up with is just that, and really doesn't do the period justice.
The way that you hear a lot of Gregorian song sung today is actually based on a style introduced by the monks of Solesmes in France during the 19th century, and I agree with you: generally it's sung very badly in a way that is unsympathetic to the text.
Unfortunately, people try to apply modern stylisms to the music (high or long notes are important, the text should fit to the music). In actual fact, the notes of the tune are embellishments to a much simpler pattern that moves around the "reciting note" (a bit like the key note in modern music). What a lot of singers do when they attempt these songs is that they end up emphasising notes which shouldn't be, and brushing over the important ones. In addition, a lot of experience is required to know what the rhythm of a given song should be, as there are no fixed tempi or rigid rhythmical notations.
So you're right in a way, I suppose; the words didn't flow to the music. The music was fitted to the words, and the words provided the shape of the music. However, to say that it was "primitive" is the epitome of foolishness; "different" is perhaps a more appropriate adjective. I will accept the argument that the notation is primitive, and has failed to preserve more than the basic form of the music through the years, but actually this is an opportunity; since the use has changed so much over the last millennium, there are lots of wonderful things you can do with the music, reconstructed from descriptions in manuscripts; for instance, our choir recently tried a technique called "organum" (of 10th century origins) which takes the tune and constructs parallel fourths, fifths and sixths around it with mind-blowing effect.
Slashdot Mirror
Firstly, the Free Software movement has ballooned massively since 1991. It wasn't even a dot on the landscape back then. Now it's a movement whose ideals are sweeping the world, and have diversified into the arts, law, and legislation too. According to Eben Moglen at a recent talk in Edinburgh, over ten thousand people were directly involved in the process of designing the license. It was designed by a committee -- and a very large one!
Secondly, there are many parties who are desperately intent on finding chinks in the armour of the Free Software movement. As we've seen with Microsoft and their recent unsubstantiated patent blustering.
Unfortunately, the English language is an imprecise tool, and there are about 192 countries where the license has to be legal, and uphold the idea of Free Software, and have as few exploitable holes as possible. It's a bit like writing a tool that has to run on x86, x86-64, MIPS, SPARC, ARM and Power when you have to write in assembly. It's going to be long, and it's not going to be as neat as you'd like.
The clauses in the GPL v3 simply say: "If you use my software, for free, to create a device which you then sell back to me at a steep price, I'd better bloody well be able to put any further modifications I make to that software onto said device. Furthermore, because I think that's pretty neat, I'd like you to extend that ability to your other customers too. If you don't like it, write your own damn software."
I paraphrase and over-simplify, but the gist is there. It's not legislation, banning the practice generally. It's very specific.
You have an objection to this?
There are such a thing as ROM chips, and there are such a thing as tamper-proof stickers. This is a good example of a situation in which both would be appropriate, and compatible with both the relevant legislation and the GPL v3 (neither vendor nor user has ability to change code after delivery).
Secondly, as you mention, both of the examples you give do not fall within the category of "consumer product" as defined by the GPL v3, and therefore the Tivoisation sections don't apply. I should probably have mentioned this when posing my challenge!
As I mentioned in another posting, the gaming problem is pathological, and I repeat my response to the other poster: do you you really want to be a member of a community where the problem of cheating is such an issue that you need to surrender your freedom to cope with it?
Fair point. And although you might (probably should) agree that this is a pretty pathological example, I did only ask for one!
My response would be to ask whether a community so rife with anti-social behaviour is one which you want to be part of, but I suppose you've already answered that question too.
Allow me to make some introductions: Peter, meet BSD. BSD, meet Peter.
Oh yes, GPL3 anti-Tivoisation clause, meet irrelevance and backlash.
I suspect that you don't understand what I'm talking about.
Quite a lot of open-source software (or at least user-written software) has been created in response to the encroachments of Digital Restrictions Management on the abilities of users to view the media which they have purchased in the false belief that such purchase entitles them to view where and when they like.
Requiring general-purpose consumer computer equipment to prevent code unsigned by the vendor from being run provides a number of benefits from the point of view of both the media cartel and large software companies:
Sony, in their position as a vendor of "trendy" hardware but also as a major stakeholder in the media market, is in the ideal position to introduce such a device, and I would expect them to do so within the next two years or so. Assuming Microsoft survives the damp squib that is Vista, I would expect the device to be announced jointly by the two players as a new "secure mobile computing platform" (not marketed as a "traditional" PC).
Software vendors would be able to acquire signing keys (relatively) easily, but they would not be available for operating systems and would likely require small per-user fees in order to squash out open source software. In addition, a Sword of Damocles contract would be required, whereby distributing software later found to be non-compliant with the terms of the signing key contract would result in all software signed with that vendor's key to be remotely deactivated.
Your mention of BSD is entirely irrelevant in the context of my GP comment, so (at the risk of being accused hypocritical) I respectfully suggest that you shut up and stop being a condescending moron.
Actually, this is a poor analogy. In defense of Tivo, they are very good about complying with the letter of GPL v2 in that they distribute the sources to all of the GPL software that they use.
This explanation is much better, in my opinion.
Another way of looking at it is this (I don't have a Tivo, but hopefully my argument will make sense). Suppose you have a great idea for a way to improve the way the Tivo interface works for you, and you see that the modifications you need to make to the code which Tivo distribute to you are quite trivial. However, when you send the patch to Tivo they tell you they won't implement it because the business case doesn't support it -- you're the only one of their customers likely to use such a change. Then you're left hanging: as you mentioned, you own a more or less generic computing device and now you also have some code to run on said computing device, but you're at the whim of a third party (non-enforceable EULAs notwithstanding) as to whether or not you can put those two components together.
As many people have pointed out, the right to make modifications and improvements and to use said modifications and improvements is pretty fundamental to the whole point of Free Software, and that's exactly what Tivo have been trying to get around.
I agree that they need to be stopped, and I support the GPL v3 in its strategy to deal with this.
Surely having code signed by the owner achieves the same results in this case as having code signed by the vendor, assuming that the owner is not stupid enough to keep the private key for the signing process on the box which they are requiring to run signed code?
I challenge you to provide me with one example of a case where using the user's key to sign the code running on their box is inferior to the same box running the same software signed by a vendor key which the user does not have access to.
That is exactly what the likes of Microsoft and Sony want to do for anything consumer-available.
And it's not like you couldn't build your own.They want to stop you from doing that too (or at least make it economically infeasible).
Although I can't comment on the safety point, I'd be interested in seeing some numbers that support the claim that electric air conditioning is more efficient that the thermodynamic cycle currently used for aircraft air con.
Unless, of course, it was last summer's vacation spent on discussion2 and these other changes, in which case the deletion of user accounts may also take nine months to roll out.
Of course, he could now be living in the southern hemisphere.
Just a thought.
If you like. It might be a more worthwhile use of time & money to put a spaceport there.
The "NO WARRANTY" part of the GPL *should* be in a EULA-type window, IMHO.
Bahahahahaha. Every capable young software engineer I know here at Cambridge University uses and codes for Linux. In fact, make that every young software engineer I know. Because it's easy to get and set up development tools on Linux and they have good documentation, and you can actually get help when you have a problem. As an engineer (a real one), I'd choose Linux (or possibly *BSD) as a development target whenever possible, because getting fast, small, portable programs written is orders of magnitude easier than I found it to be on Windows (when I last bothered to try).
That would be "Execute Rectangle Kill". How is that not intuitive?
I usually use Krita, which is really really good, supporting several different colourspaces, as well as having a more Photoshop-like interface than most open source editors. It also integrates really nicely into KDE, which is a big plus for me.
Cambridge University Engineering Dept does all 3D CAD teaching using Pro Engineer. On Knoppix boxes with NVidia graphics hardware. It runs very fast, even with moderately complex models.
The GPL Electronic Design tools project will be moving to git soon. Unfortunately, not all of the developers are on platforms supported by git (and others just don't like git), so there is going to be a git-cvsserver set up to support them. This is generally considered to be a good way to do gradual migration.
I think you just described git - I can do all of that in git.
Faster and with less faff than using *any* other version control system I've tried. However, MKS Source has some really nice features... shame it's so expensive, really!
I'm sure that you're pleased to hear that they do.
ODF has already gone through this process. It is already an ISO standard (ISO 26300, IIRC). The vote was on whether the ISO standard should also be adopted as an ANSI standard.
There's nothing wrong with making malloc() fail for certain programs which are using vast amounts of memory. Anything using truly colossal amounts of memory should have implemented a way of coping with that... and those that don't will die, freeing up lots of memory.
I reckon it wouldn't be too difficult to implement, actually. First, there's no need to examine every frame; one in every 50 would probably be enough. Then, the procedure is probably as follows:
The false positive rate from such a system would be negligible, and robustness and accuracy could easily be increased by recording more features from each frame. This is a mature technology, and it's been designed for much harder computer intelligence tasks than the one described.
I think Martin Niemöller said it best:
When the Nazis came for the communists,
I remained silent;
I was not a communist.
When they locked up the social democrats,
I remained silent;
I was not a social democrat.
When they came for the trade unionists,
I did not speak out;
I was not a trade unionist.
When they came for me,
there was no one left to speak out.
What about Akademy 2007 in Glasgow?
WRONG. I'm a member of the Schola Gregoriana of Cambridge, and we specialise in singing music from between the 10th and 17th centuries, primarily Gregorian song (the original music of the Catholic Church, sometimes called "plain chant"). Several of our members are researchers who study ancient manuscripts to find out about music in the dark ages and the early rennaissance, and believe me; this stuff really doesn't deserve it's reputation for being "primitive". Unfortunately, the rubbish these people have come up with is just that, and really doesn't do the period justice.
The way that you hear a lot of Gregorian song sung today is actually based on a style introduced by the monks of Solesmes in France during the 19th century, and I agree with you: generally it's sung very badly in a way that is unsympathetic to the text. Unfortunately, people try to apply modern stylisms to the music (high or long notes are important, the text should fit to the music). In actual fact, the notes of the tune are embellishments to a much simpler pattern that moves around the "reciting note" (a bit like the key note in modern music). What a lot of singers do when they attempt these songs is that they end up emphasising notes which shouldn't be, and brushing over the important ones. In addition, a lot of experience is required to know what the rhythm of a given song should be, as there are no fixed tempi or rigid rhythmical notations.
So you're right in a way, I suppose; the words didn't flow to the music. The music was fitted to the words, and the words provided the shape of the music. However, to say that it was "primitive" is the epitome of foolishness; "different" is perhaps a more appropriate adjective. I will accept the argument that the notation is primitive, and has failed to preserve more than the basic form of the music through the years, but actually this is an opportunity; since the use has changed so much over the last millennium, there are lots of wonderful things you can do with the music, reconstructed from descriptions in manuscripts; for instance, our choir recently tried a technique called "organum" (of 10th century origins) which takes the tune and constructs parallel fourths, fifths and sixths around it with mind-blowing effect.