Criminalizing the mere possession of something just because it could potentially be used in a crime is pretty stupid. Until you do something that actually harms someone, where's the crime? "Innocent until proven guilty" remember?
In Britain, at least, this kind of law has existed for a long time. There is a crime, for instance, of "going equipped to commit burglary"; that is, carrying tools that might be useful in breaking into a house and behaving in a way that makes the police suspicious that you might intend to do it. I bet all the locksmiths got really nervous when that one was passed, and with good reason. They're relying on the police and the courts to be sensible with it. I'd rather them than me.
Once again we must rely on the Lords to stop the knee-jerk stupidity of the Commons foisting more draconian laws upon us. Let's hope they continue to do their job.
I have this recurring fear that Blair's last act as PM will be to force through a new Parliament Act that renders them completely powerless.
This is more sensationalist shit like the story about the RIPA. The law isn't very effective because the police can't force you to hand over keys that are used only to ensure the integrity of messages.
Well, frankly you're arguing against a strawman here. The problem with the RIPA has nothing to do with message authentication codes, hell it isn't even that it allows the police to demand your encryption key (I don't have a problem with this). The problems with it are:
1. It does not require an order made under it to be issued by an appropriate authority. The authority to make orders extends essentially to any police officer in pursuit of his duty. It should require judicial oversight (e.g. only a magistrate or judge could issue the order).
2. The secrecy requirements on orders are potentially problematic. They never expire, so if you are subject to one you cannot tell anybody about it, ever... other than your lawyer.
3. It shifts the burden of proof. If it can be proved that you once had the key, your only defence is to prove that you no longer have it. How this is likely to be shown I don't know.
I wrote an essay in 2003 and you can read it here.
Your analysis misses the point of what the law is for -- it isn't targeted at breaking SSH connections or similar systems where the key is not stored permanently. The law's drafters knew very well that they couldn't attack these systems without making them illegal, and I suspect didn't want the consequences of criminalising HTTPS. The main target is getting keys for access to encrypted hard disks and e-mails, which with current technology are very much covered. The law achieves what it was originally intended to achieve.
The short and long of it is that it is very tough indeed to prove beyond reasonable doubt that someone that you put the software there.
Huh? I'm not sure what you're talking about. This law criminalises providing tools to a 3rd party that are either designed to be used in a crime under the CMA, or where the transferer believes (knowing UK law this will be interpreted as 'a reasonable person in the same situation would have believed', as of course an individual's state of mind is nearly impossible to prove beyond reasonable doubt) that it is likely to be used in such a crime.
Believe me I know, I was a witness in a Child Porn case. The defence won because when we found the content we didn't follow CPS guidelines in the data recovery method.
Laws on handling of evidence exist for very good reasons: to make it harder for anyone to plant or falsify evidence against a suspect. The only evidence required here is evidence that the supply took place. This could be found from (e.g.) web server access logs, ISP logs, or police monitoring the activities of a downloader who is already a suspect, among other possible sources.
As an aside, you mention that you did data recovery in the case you talked about -- it's worth noting that downloading child porn to a computer and immediately deleting it would not (provably) constitute an offence in itself, as I understand the law. You must intentionally do it, in the full knowledge of what is contained. If the suspect deleted it, this could be seen as evidence that the suspect did not know the contents of the files he downloaded and did the reasonable thing on discovering them -- immediately delete them. Without knowing the details of your case, I surmise that this is probably why the CPS wouldn't use recovered files; they couldn't be certain they had been kept for any length of time.
I guess if you're making stuff that you believe is -likely- to be used to break the law, you have a certain level of responsibility to try and make sure it doesn't. For example, I've refused on an occasion to write software for someone because of how it was going to be used (in this case, it was for managing unsolicited mailouts aka spam).
Let's take another case. This one is also real. Back in the 90s, I was involved with a project called NASM, a free assembler for Intel processors. Back in the early days, we had a rather nasty bug in the preprocessor that caused it to segfault if you tried to use a certain feature in a certain way (I forget the details, but it was hard to work around if you wanted that feature). The bug was reported, and we fixed it. However, it was clear from the way that it was reported that the reporter wanted it fixed because he needed that particular feature for a toolkit for virus writers.
So: do we fix the bug, and release software that is "adapt[ed]... to assist in the commission of... an offence under section 1 or 3" and "believing that it is likely to be so used" (in fact, we damn well knew for certain that it would be used that way), or do we sit on it?
Well, we sat on it for a while. But in the end, there were other users who needed that bug fixed. So the virus writers got their toolkit.
But if this law had been in place then, we'd have had to seriously consider whether we were committing a criminal offence that could earn us 2 years inside. And by my interpretation, we would have been.
I guess a written constitution does have some utility.
1. I don't think it would protect you from this. While I'm not familiar with it in-depth, none of the aspects of it that I'm aware of would prevent the criminalisation of the supply of a tool in the knowledge that it was likely to be used to commit a criminal offence. In fact, the language here is almost identical to the anti-circumvention language of the DMCA, which is widely believed to be constitutionally fine.
2. Much of the British constitution is written; it just isn't written in a single document like the US constitution. See the summary here that describes what parts of it are written. Particularly the Human Rights Act 1998.
Although now it seems our illustrious leader wants to... er... "clarify" that act, but it doesn't matter -- it seems that whatever our parliament does, the European Convention on Human Rights is, as per our treaties with the EU, placed above everything else.
Of course, as you cant prove there is no encrypted information on your computer, they basically have a carte blanche to lock up anyone they feel like for no reason at all.
That's not quite how it works. They have to have "reasonable grounds" to believe that you have an encryption key -- finding the encrypted data is the most commonly cited grounds. You can then rely on the defence that you don't have the key... but have to give reasonable evidence to suggest to a court that you don't.
They already have this ability. It's called the Regulation of Investigatory Powers Act [wikipedia.org] and it was passed in 2000. RIP, don't ya just love it...?
Yes and no. Yes, the RIPA was passed in 2000, but it (or at least Part III, the part that relates to encryption) is apparently not yet in force (the act states that it will come into force as & when the home secretary so orders, which he has yet to do). They are considering bringing it into force now.
At least, that's my understanding based on TFA, which isn't particularly well written, and having read the RIPA a few times back when it was enacted.
It really depends on how you see the binary driver. It is possible to view it as data that is acted on by the GPL portion, whose purpose is to serve as a link loader. That binary driver is *not* linked to the module (not in the traditional sense of the word, anyway; it is treated by the linker as a blob of data, not code). I'm not saying that this is how a court *would* interpret it, but it is certainly how a court *might* interpret it. And, lord knows, nVidia have lawyers.
MPEGLA seem to think you're wrong. Here is a list of sample claims that they believe cover MPEG2 applications. Some clearly apply to decoding (like "Halting input of data when decoder buffer fills", US Pat 5,291,486 claim 12 -- I'm not kidding, either. Halting input of data when decoder buffer fills? What else are we going to do, overrun it?). Others might or might not, they describe MPEG related data structures, and it isn't clear whether only creating the structures or also interpreting them might be covered. Although it seems I was wrong to describe it as a $5 fee, it's actually only $2.50. I'd guess that CSS probably forms the other $2.50.
The issue here is not linux, but the fact that the manufacturer didn't supply drivers for your card.
Well, yeah. But the point is, and the point made way upthread that I was defending here: almost all card manufacturers provide drivers for Windows, and very few provide drivers for Linux and unless and until that disparity is sorted out, the experience of installing hardware on a Linux machine cannot be as good as the experience of installing hardware on a Windows machine. The kernel cannot ship with open-source drivers for every piece of hardware a user might install. It's impossible to keep up with new technology, not to mention the problems of inadequately documented hardware.
And until the Linux kernel supports a stable driver ABI, with a simple and standardised way of installing new drivers from a manufacturer-supplied CD, it's a lot of effort for a manufacturer to go to. They don't want to ship source code (even if they don't have trade secret or licensing issues in doing so, they don't want the support nightmare it would produce), but they don't want to have to ship a binary for every little variation that's possible in your kernel either. It simply isn't worth it for a minority of customers. Let somebody else have those customers, they'll say.
As a HTML/CSS developer you are not doing your job if you are not working to standards. Simple as that.
Actually, as an HTML/CSS developer I wouldn't be doing my job if I didn't produce a solution that does what the client wants within the budget that I told the client would be possible. If I can produce something that complies with the relevant recommendations (note: not standards, the W3C doesn't produce standards) at the same time as meeting those constraints then that's so-much-the-better. However when problems arise that can't be solved without breaking one of those two more important constraints the solution is to violate the recommendation every time. Yes I produce web sites that use <nobr> tags when necessary, and I produce web sites with HTML and CSS that uses proprietary extensions to achieve things that can't be satisfactarily achieved without them. I produce sites that render as the client wants in IE. I test in a few other browsers to make sure it works at-least acceptably in those. I follow "standards" when possible. I don't slavishly adhere to them at the cost of my clients' interests. To do so, I feel, would be unprofessional. And if you disagree, keep that disagreement to yourself. You'll never convince me otherwise, or any of the others like me. And we're the vast majority of developers.
Bad HTML/CSS is the equivlent of really bad, messy perl/php/actionscript2/c code. I wouldn't for a second think about employing someone who was any less than perfect at standards.
Not adhering to standards doesn't mean that I don't understand the standards, and doesn't mean I can't use them when applicable. However, if I'm putting together a client site with a 3rd-party ecommerce application, I'm not going to pick that app's code apart in order to fix the bug that causes it to omit </option> tags in some circumstances. Sorry, not unless the client is willing to pay for it. And I highly doubt you'll find one that is, if you explain to them exactly how it benefits them.
Can you give us a list of 3rd party modules are uncompliant?
A PHP-based content manager my company used to work with, I don't recall its name unfortunately. Actinic catalog (validate their demonstration site here: http://validator.w3.org/check?verbose=1&uri=http%3 A%2F%2Fwww.premiumtyresonline.co.uk%2Facatalog%2Fs hop.html). I'm sure there are others, but I don't remember them right now. I find that *most* web applications generate URLs in links that contain unescaped ampersands. This works with all browsers, but is *not* valid HTML (at least according to the HMTL4 spec).
I have found meeting web standards, developing with CSS rather than tables and writing (hopefully) semantic HTML has made my development process far far more efficient and no slower than the table-based layouts and non-standards compliancy days of old.
Perhaps you could help me out here. I'm not a CSS expert by any means, but I currently have a requirement to implement a site that has three vertical columns, the leftmost and rightmost of which should be the smallest possible size to fit their variable content into and the central one should expand to fill the available space. I'd love to know how I can do this without a table, but I couldn't figure it out, and all the CSS layout tutorials I've been able to find will only do columns of predetermined width. Having wasted two hours on this fairly simple requirement now, I'm about to go back to using a table like I normally would.
Aaargh! You imply that developing a website using web standards takes longer. False! It _does_ require that you exercise more care.
Sorry. If you're doing something more complicated than building a 10-page static site, or even something with a little PHP-driven database, then it will take longer. It'll limit your choice of available third-party modules, and you'll have to evaluate each one you consider for its standards compliance. You'll have to hire more competent developers when you outsource. You may have to redesign legacy code that's already on the site (I've just finished doing this for a text-html autoformatter that was in use on a number of sites my company maintains, and which produced the most horribly non-standard html you can imagine rendering correctly -- two days' work, and if I hadn't been able to justify it in terms of being able to extend the range of formatting options it supports, I'd never have got the finance to do it).
If WAI is an issue, you'll have to examine the text that has been supplied by people other than yourself, going through it and putting expansions of abbreviations and acronyms in place for screen readers using ABBR and ACRONYM tags, for example.
And developing a CSS-based layout that fits the specification the graphic designer has handed to you, rather than a deprecated table-based one, is often quite tricky.
No, for anything beyond trivial requirements, meeting web standards can be time consuming. Sorry.
Peer to Peer financing has been around for decades. It is called a Credit Union.
That's a good start, but I'd look more at the shared-ownership mortgage for a model -- this is where a broker puts a house buyer in touch with an investor who's willing to finance (usually) half of the cost of the house, in exchange for the ability to collect rent from him on half its value for some period of time afterwards. There are some brokers who will arrange this kind of scheme with individual investors, matching investors and house buyers in the same kind of way these sites do.
Existing Credit unions are in fact quite different than these new P2P efforts; credit unions generally:
1. require membership (member of a trade union, church, etc),
2. are geograpically regional, and
3. don't require or enable any relationship between the lender and the borrower. (the credit union institution is the middleman.)
Perhaps in the US, but the UK equivalent (the Building Society) generally has none of these restrictions (although most started out as regional societies, they won't generally refuse someone credit on the basis of their address, and many operate nationally).
Absolutely, transcode & mencoder (once you learn the command line options) are the best video conversion software out there.
I'd add ffmpeg to that list. I've found it second-to-none for quickly knocking up VOB files for DVD authoring. Quality isn't perfect, but good enough for reencoding Internet-sourced XViDs, and much faster than most of the alternatives.
So good, in fact, that I've installed it on my Windows machines too.
The issue is not that they don't work, but that you still have to install drivers for them. The point being that in Linux you still have to install drivers for many hardware packages that are out there.
The issue isn't installing drivers. I've never met a Windows user who was willing to buy & install new hardware but has trouble logging in as administrator, inserting the disc that came with the hardware and following the onscreen instructions.
However, _I_ dread having to install new hardware on one of my Linux machines. Why? The following is about representative of my experience with new hardware installations.
I needed to connect a Linux machine to a wireless network that had been set up by my housemate. The network's fairly standard: 802.11g with a Belkin access point. My local computer shop offered a fairly standard PCI 802.11g card, also manufactured by Belkin.
First step I had to take that a Windows user wouldn't: I looked up the model on a hardware compatibility list to ensure that it was compatible with the available Linux drivers. The list said it was based on a Broadcom chipset that was known to work with the 'ndiswrapper' driver.
I bought the card and installed it in my machine. I restarted the machine and tried to follow the instructions that I'd found on the web site for installing the driver. I loaded the driver disc that came with it.
Second step I had to take that a Windows user wouldn't: The instructions didn't work. The instructions relied on the driver executable file being located in a specific file on the CD, but the file had moved. Into the inside of a Windows-only self-extracting compressed archive. I took the disc to another machine that ran Windows and extracted the archive, copied the required file (which had a different name to the one I was expecting) onto a USB disk and moved it over to the Linux machine.
I tried to install the driver with ndiswrapper. The driver loaded. I enumerated the available networks, and the one I wanted was listed. I entered the network key and connected to it.
Third step I had to perform that a Windows user wouldn't: Nothing happened. I tried again. Still nothing. I rebooted and tried again. Still nothing. I downloaded an updated version of ndiswrapper. It depended on a more recent kernel than I had, so I upgraded my kernel. I recompiled both and tried again. Still nothing. I investigate in more detail and discover that the board I have is different from the one originally described -- it has a different chipset to the one expected, and this chipset doesn't work with Linux yet (a native driver is in development, but isn't ready for use yet).
At this point, I give up on getting the device to work, install it in a Windows machine and use network bridging to connect the Linux machine via a cable to that one. My other alternative was to take the card back to the shop, try to convince them to take it back despite the fact that it has been used and has no faults, and buy a more expensive one that would work.
I don't think this is an out-of-the ordinary experience, given how many times I've had similar ones.
Distros will not be able to come equipped with the ability to play all the patent-encumbered media formats,
There's no reason a $20 commercial distribution couldn't come with a "non-redistributable" disc that includes these in closed-source form.
And when new linux users complain of drivers not being installed automatically, they're probably thinking of their new ATI or Nvidia card that have proprietary, GPL unfriendly drivers.
Interesting. My last SuSE install automatically installed the ATI drivers for me. It did have to download them from the Internet because they weren't on the disc it came on, but the install program knew exactly where to get them from. Are you sure you're not using a particularly unfriendly distribution?
Yes, and the source of the kernel module is distributed under the terms of the GPL. I don't see any violation here. It happens that part of the source for it is a lump of binary data that it manipulates by causing it to be executed, but that's fine as that data is *not* derivitive of the kernel, and you won't find a court of law that will say otherwise, which is the key issue here.
Copyright licenses (like the GPL) only apply when copying is taking place. The binary driver does not copy anything from the kernel, so the GPL doesn't apply to its distribution.
"E.g. if glibc was GPL it means you couldn't write closed source binary only software. Therefore the glibc package is LGPL which allows this."
Just correcting a minor misapprehension: glibc is *not* LGPL; it is "GPL with the libc exception", which is GPL modified by an extra grant of rights that allows you to (this is my paraphrasing, because I don't have the text in front of me) link to the library and redistribute under any terms you wish as long as what you distribute does not fulfil substantially the same purpose as the original library; i.e. you can't use it as the basis to write another C library, but just about any other use is fair game.
You misunderstand a basic element of copyright law, which is this: there must be copying taking place for any licence (which the GPL is) to be relevant.
In this case, there is no copying:
1. Linus et al write the Linux kernel, and design interfaces that allow it to dynamically load modules. They license this under the GPL. 2. nVidia develop software that manages their video cards which has an interface defined by nVidia to allow it to integrate with operating system kernels that support this interface. No copying has taken place, and this software can be licensed under whatever terms nVidia wish. 3. nVidia write a compatibility layer that uses the interfaces designed by Linus et al in step 1 to provide the interface they designed themselves in step 2. This may legally-speaking be a derivitive work of the work produced in step 1, at which point it may only be distributed under a license agreed to by the authors of step 1 (i.e., it can only be distributed under the GPL). Or it may not, it's kind of hard to tell. Relevant case law includes the decision that the fact that BSD Unix copied interface definitions from System V Unix doesn't mean that BSD Unix is a derivitive of System V. The waters are rather muddy and a court case could go either way in my non-expert opinion. It may also be a derivitive of the code produced in step 2, but that's ok because that was written by nVidia who will automatically grant permission to use this under the GPL. 4. The code produced in step 1 is licensed under the GPL, so distributors are free to distribute it as they wish, as long as they do so under the terms of the GPL and either provide source code or an offer to provide source code at a later date. 5. The code produced in step 2 is licensed by nVidia for free redistribution in binary form, so distributors can distribute it however they like. 6. The code produced in step 3 is licensed by nVidia under the GPL, so can be distributed under the same terms as step 4. 7. The GPL states that "mere aggregation on a storage medium" does not bring code under its scope, so there is no problem with distributing all 3 together.
You can see that at no point has any license condition been violated. It's pretty important, however, that step 2 takes place either before step 3 or by a totally independent group of developers. Otherwise step 2 could be argued to have copied from step 3. The step 2 developers also should not know the details of the Linux kernel interfaces, so that it can be argued that step 2 cannot possibly be a derivitive of step 1 (i.e. it should be a clean room implementation). As long as nVidia et al have followed this procedure, there is absolutely no legal issue with distributing their code. And if they haven't, it is nVidia who are violating the GPL, not Kororaa.
IMO, the "shim" is irrelvant from a legal perspective. It only exists for engineering purposes because there is no standard module ABI.
You're wrong. The shim is very important legally speaking. The shim itself is a derivitive of the linux kernal, therefore legally speaking it must be distributed under the GPL. However, parts of it are not derivitive of the kernel -- these are the parts that were designed entirely independently from the kernel. If the ABI that it supports is one of these parts (it need not be for engineering reasons, but for legal reasons the companies that have produced these *should* have ensured that it was by having it designed by somebody with no knowledge of linux kernel internals) then anything implemented using that ABI is *not* derivitive of the Linux kernel and need not be distributed under the GPL.
This is absolutely basic copyright law, and anyone who yells "but the GPL says..." or "but Linus says..." are missing the point. It doesn't matter what either of these are saying, because all that matters is whether what nVidia et al have done is *unauthorised copying* under copyright law as it currently stands. And that hinges only on the question of whether the ABIs they have produced are derivitive of linux kernel internals.
To put it another way, it is possible to develop a "shim" of precisely the same nature as the ones we're discussing that would enable you to load binary drivers with some preexisting ABI. This has, in fact, been done more than once: captivefs is a shim that lets you use Microsoft's NTFS driver, and ndiswrapper is a shim that lets you use drivers written to Microsoft's NDIS network driver ABI. Does the existence of these layers mean that all of these drivers, developed with no intention of running them under Linux at all, are suddenly GPL violations? Or are captivefs and ndiswrapper's shims GPL violations despite the fact that they distribute source code under the GPL as required? Or perhaps somebody would be violating the GPL by distributing ndiswrapper and an appropriate driver on the same media, despite the "mere aggregation" clause in the GPL clearly stating that this isn't a problem?
Slashdot Mirror
Criminalizing the mere possession of something just because it could potentially be used in a crime is pretty stupid. Until you do something that actually harms someone, where's the crime? "Innocent until proven guilty" remember?
In Britain, at least, this kind of law has existed for a long time. There is a crime, for instance, of "going equipped to commit burglary"; that is, carrying tools that might be useful in breaking into a house and behaving in a way that makes the police suspicious that you might intend to do it. I bet all the locksmiths got really nervous when that one was passed, and with good reason. They're relying on the police and the courts to be sensible with it. I'd rather them than me.
Oh. Looks like I'm next.
Once again we must rely on the Lords to stop the knee-jerk stupidity of the Commons foisting more draconian laws upon us. Let's hope they continue to do their job.
I have this recurring fear that Blair's last act as PM will be to force through a new Parliament Act that renders them completely powerless.
I hope I'm being paranoid. I really do.
This is more sensationalist shit like the story about the RIPA. The law isn't very effective because the police can't force you to hand over keys that are used only to ensure the integrity of messages.
Well, frankly you're arguing against a strawman here. The problem with the RIPA has nothing to do with message authentication codes, hell it isn't even that it allows the police to demand your encryption key (I don't have a problem with this). The problems with it are:
1. It does not require an order made under it to be issued by an appropriate authority. The authority to make orders extends essentially to any police officer in pursuit of his duty. It should require judicial oversight (e.g. only a magistrate or judge could issue the order).
2. The secrecy requirements on orders are potentially problematic. They never expire, so if you are subject to one you cannot tell anybody about it, ever... other than your lawyer.
3. It shifts the burden of proof. If it can be proved that you once had the key, your only defence is to prove that you no longer have it. How this is likely to be shown I don't know.
I wrote an essay in 2003 and you can read it here.
Your analysis misses the point of what the law is for -- it isn't targeted at breaking SSH connections or similar systems where the key is not stored permanently. The law's drafters knew very well that they couldn't attack these systems without making them illegal, and I suspect didn't want the consequences of criminalising HTTPS. The main target is getting keys for access to encrypted hard disks and e-mails, which with current technology are very much covered. The law achieves what it was originally intended to achieve.
The short and long of it is that it is very tough indeed to prove beyond reasonable doubt that someone that you put the software there.
Huh? I'm not sure what you're talking about. This law criminalises providing tools to a 3rd party that are either designed to be used in a crime under the CMA, or where the transferer believes (knowing UK law this will be interpreted as 'a reasonable person in the same situation would have believed', as of course an individual's state of mind is nearly impossible to prove beyond reasonable doubt) that it is likely to be used in such a crime.
Believe me I know, I was a witness in a Child Porn case. The defence won because when we found the content we didn't follow CPS guidelines in the data recovery method.
Laws on handling of evidence exist for very good reasons: to make it harder for anyone to plant or falsify evidence against a suspect. The only evidence required here is evidence that the supply took place. This could be found from (e.g.) web server access logs, ISP logs, or police monitoring the activities of a downloader who is already a suspect, among other possible sources.
As an aside, you mention that you did data recovery in the case you talked about -- it's worth noting that downloading child porn to a computer and immediately deleting it would not (provably) constitute an offence in itself, as I understand the law. You must intentionally do it, in the full knowledge of what is contained. If the suspect deleted it, this could be seen as evidence that the suspect did not know the contents of the files he downloaded and did the reasonable thing on discovering them -- immediately delete them. Without knowing the details of your case, I surmise that this is probably why the CPS wouldn't use recovered files; they couldn't be certain they had been kept for any length of time.
I guess if you're making stuff that you believe is -likely- to be used to break the law, you have a certain level of responsibility to try and make sure it doesn't. For example, I've refused on an occasion to write software for someone because of how it was going to be used (in this case, it was for managing unsolicited mailouts aka spam).
... to assist in the commission of ... an offence under section 1 or 3" and "believing that it is likely to be so used" (in fact, we damn well knew for certain that it would be used that way), or do we sit on it?
Let's take another case. This one is also real. Back in the 90s, I was involved with a project called NASM, a free assembler for Intel processors. Back in the early days, we had a rather nasty bug in the preprocessor that caused it to segfault if you tried to use a certain feature in a certain way (I forget the details, but it was hard to work around if you wanted that feature). The bug was reported, and we fixed it. However, it was clear from the way that it was reported that the reporter wanted it fixed because he needed that particular feature for a toolkit for virus writers.
So: do we fix the bug, and release software that is "adapt[ed]
Well, we sat on it for a while. But in the end, there were other users who needed that bug fixed. So the virus writers got their toolkit.
But if this law had been in place then, we'd have had to seriously consider whether we were committing a criminal offence that could earn us 2 years inside. And by my interpretation, we would have been.
I guess a written constitution does have some utility.
... er... "clarify" that act, but it doesn't matter -- it seems that whatever our parliament does, the European Convention on Human Rights is, as per our treaties with the EU, placed above everything else.
1. I don't think it would protect you from this. While I'm not familiar with it in-depth, none of the aspects of it that I'm aware of would prevent the criminalisation of the supply of a tool in the knowledge that it was likely to be used to commit a criminal offence. In fact, the language here is almost identical to the anti-circumvention language of the DMCA, which is widely believed to be constitutionally fine.
2. Much of the British constitution is written; it just isn't written in a single document like the US constitution. See the summary here that describes what parts of it are written. Particularly the Human Rights Act 1998.
Although now it seems our illustrious leader wants to
Of course, as you cant prove there is no encrypted information on your computer, they basically have a carte blanche to lock up anyone they feel like for no reason at all.
That's not quite how it works. They have to have "reasonable grounds" to believe that you have an encryption key -- finding the encrypted data is the most commonly cited grounds. You can then rely on the defence that you don't have the key... but have to give reasonable evidence to suggest to a court that you don't.
They already have this ability. It's called the Regulation of Investigatory Powers Act [wikipedia.org] and it was passed in 2000. RIP, don't ya just love it...?
Yes and no. Yes, the RIPA was passed in 2000, but it (or at least Part III, the part that relates to encryption) is apparently not yet in force (the act states that it will come into force as & when the home secretary so orders, which he has yet to do). They are considering bringing it into force now.
At least, that's my understanding based on TFA, which isn't particularly well written, and having read the RIPA a few times back when it was enacted.
It really depends on how you see the binary driver. It is possible to view it as data that is acted on by the GPL portion, whose purpose is to serve as a link loader. That binary driver is *not* linked to the module (not in the traditional sense of the word, anyway; it is treated by the linker as a blob of data, not code). I'm not saying that this is how a court *would* interpret it, but it is certainly how a court *might* interpret it. And, lord knows, nVidia have lawyers.
The license fee isn't for the MPEG2 decoder
MPEGLA seem to think you're wrong. Here is a list of sample claims that they believe cover MPEG2 applications. Some clearly apply to decoding (like "Halting input of data when decoder buffer fills", US Pat 5,291,486 claim 12 -- I'm not kidding, either. Halting input of data when decoder buffer fills? What else are we going to do, overrun it?). Others might or might not, they describe MPEG related data structures, and it isn't clear whether only creating the structures or also interpreting them might be covered. Although it seems I was wrong to describe it as a $5 fee, it's actually only $2.50. I'd guess that CSS probably forms the other $2.50.
Have you ever tried to find a competent web developer to outsource to? Didn't think so. It's *hard*.
The issue here is not linux, but the fact that the manufacturer didn't supply drivers for your card.
Well, yeah. But the point is, and the point made way upthread that I was defending here: almost all card manufacturers provide drivers for Windows, and very few provide drivers for Linux and unless and until that disparity is sorted out, the experience of installing hardware on a Linux machine cannot be as good as the experience of installing hardware on a Windows machine. The kernel cannot ship with open-source drivers for every piece of hardware a user might install. It's impossible to keep up with new technology, not to mention the problems of inadequately documented hardware.
And until the Linux kernel supports a stable driver ABI, with a simple and standardised way of installing new drivers from a manufacturer-supplied CD, it's a lot of effort for a manufacturer to go to. They don't want to ship source code (even if they don't have trade secret or licensing issues in doing so, they don't want the support nightmare it would produce), but they don't want to have to ship a binary for every little variation that's possible in your kernel either. It simply isn't worth it for a minority of customers. Let somebody else have those customers, they'll say.
As a HTML/CSS developer you are not doing your job if you are not working to standards. Simple as that.
Actually, as an HTML/CSS developer I wouldn't be doing my job if I didn't produce a solution that does what the client wants within the budget that I told the client would be possible. If I can produce something that complies with the relevant recommendations (note: not standards, the W3C doesn't produce standards) at the same time as meeting those constraints then that's so-much-the-better. However when problems arise that can't be solved without breaking one of those two more important constraints the solution is to violate the recommendation every time. Yes I produce web sites that use <nobr> tags when necessary, and I produce web sites with HTML and CSS that uses proprietary extensions to achieve things that can't be satisfactarily achieved without them. I produce sites that render as the client wants in IE. I test in a few other browsers to make sure it works at-least acceptably in those. I follow "standards" when possible. I don't slavishly adhere to them at the cost of my clients' interests. To do so, I feel, would be unprofessional. And if you disagree, keep that disagreement to yourself. You'll never convince me otherwise, or any of the others like me. And we're the vast majority of developers.
Bad HTML/CSS is the equivlent of really bad, messy perl/php/actionscript2/c code. I wouldn't for a second think about employing someone who was any less than perfect at standards.
Not adhering to standards doesn't mean that I don't understand the standards, and doesn't mean I can't use them when applicable. However, if I'm putting together a client site with a 3rd-party ecommerce application, I'm not going to pick that app's code apart in order to fix the bug that causes it to omit </option> tags in some circumstances. Sorry, not unless the client is willing to pay for it. And I highly doubt you'll find one that is, if you explain to them exactly how it benefits them.
Can you give us a list of 3rd party modules are uncompliant?
3 A%2F%2Fwww.premiumtyresonline.co.uk%2Facatalog%2Fs hop.html). I'm sure there are others, but I don't remember them right now. I find that *most* web applications generate URLs in links that contain unescaped ampersands. This works with all browsers, but is *not* valid HTML (at least according to the HMTL4 spec).
A PHP-based content manager my company used to work with, I don't recall its name unfortunately. Actinic catalog (validate their demonstration site here: http://validator.w3.org/check?verbose=1&uri=http%
I have found meeting web standards, developing with CSS rather than tables and writing (hopefully) semantic HTML has made my development process far far more efficient and no slower than the table-based layouts and non-standards compliancy days of old.
Perhaps you could help me out here. I'm not a CSS expert by any means, but I currently have a requirement to implement a site that has three vertical columns, the leftmost and rightmost of which should be the smallest possible size to fit their variable content into and the central one should expand to fill the available space. I'd love to know how I can do this without a table, but I couldn't figure it out, and all the CSS layout tutorials I've been able to find will only do columns of predetermined width. Having wasted two hours on this fairly simple requirement now, I'm about to go back to using a table like I normally would.
Aaargh! You imply that developing a website using web standards takes longer. False! It _does_ require that you exercise more care.
Sorry. If you're doing something more complicated than building a 10-page static site, or even something with a little PHP-driven database, then it will take longer. It'll limit your choice of available third-party modules, and you'll have to evaluate each one you consider for its standards compliance. You'll have to hire more competent developers when you outsource. You may have to redesign legacy code that's already on the site (I've just finished doing this for a text-html autoformatter that was in use on a number of sites my company maintains, and which produced the most horribly non-standard html you can imagine rendering correctly -- two days' work, and if I hadn't been able to justify it in terms of being able to extend the range of formatting options it supports, I'd never have got the finance to do it).
If WAI is an issue, you'll have to examine the text that has been supplied by people other than yourself, going through it and putting expansions of abbreviations and acronyms in place for screen readers using ABBR and ACRONYM tags, for example.
And developing a CSS-based layout that fits the specification the graphic designer has handed to you, rather than a deprecated table-based one, is often quite tricky.
No, for anything beyond trivial requirements, meeting web standards can be time consuming. Sorry.
Peer to Peer financing has been around for decades. It is called a Credit Union.
That's a good start, but I'd look more at the shared-ownership mortgage for a model -- this is where a broker puts a house buyer in touch with an investor who's willing to finance (usually) half of the cost of the house, in exchange for the ability to collect rent from him on half its value for some period of time afterwards. There are some brokers who will arrange this kind of scheme with individual investors, matching investors and house buyers in the same kind of way these sites do.
Existing Credit unions are in fact quite different than these new P2P efforts; credit unions generally:
1. require membership (member of a trade union, church, etc),
2. are geograpically regional, and
3. don't require or enable any relationship between the lender and the borrower. (the credit union institution is the middleman.)
Perhaps in the US, but the UK equivalent (the Building Society) generally has none of these restrictions (although most started out as regional societies, they won't generally refuse someone credit on the basis of their address, and many operate nationally).
Absolutely, transcode & mencoder (once you learn the command line options) are the best video conversion software out there.
I'd add ffmpeg to that list. I've found it second-to-none for quickly knocking up VOB files for DVD authoring. Quality isn't perfect, but good enough for reencoding Internet-sourced XViDs, and much faster than most of the alternatives.
So good, in fact, that I've installed it on my Windows machines too.
The issue is not that they don't work, but that you still have to install drivers for them. The point being that in Linux you still have to install drivers for many hardware packages that are out there.
The issue isn't installing drivers. I've never met a Windows user who was willing to buy & install new hardware but has trouble logging in as administrator, inserting the disc that came with the hardware and following the onscreen instructions.
However, _I_ dread having to install new hardware on one of my Linux machines. Why? The following is about representative of my experience with new hardware installations.
I needed to connect a Linux machine to a wireless network that had been set up by my housemate. The network's fairly standard: 802.11g with a Belkin access point. My local computer shop offered a fairly standard PCI 802.11g card, also manufactured by Belkin.
First step I had to take that a Windows user wouldn't: I looked up the model on a hardware compatibility list to ensure that it was compatible with the available Linux drivers. The list said it was based on a Broadcom chipset that was known to work with the 'ndiswrapper' driver.
I bought the card and installed it in my machine. I restarted the machine and tried to follow the instructions that I'd found on the web site for installing the driver. I loaded the driver disc that came with it.
Second step I had to take that a Windows user wouldn't: The instructions didn't work. The instructions relied on the driver executable file being located in a specific file on the CD, but the file had moved. Into the inside of a Windows-only self-extracting compressed archive. I took the disc to another machine that ran Windows and extracted the archive, copied the required file (which had a different name to the one I was expecting) onto a USB disk and moved it over to the Linux machine.
I tried to install the driver with ndiswrapper. The driver loaded. I enumerated the available networks, and the one I wanted was listed. I entered the network key and connected to it.
Third step I had to perform that a Windows user wouldn't: Nothing happened. I tried again. Still nothing. I rebooted and tried again. Still nothing. I downloaded an updated version of ndiswrapper. It depended on a more recent kernel than I had, so I upgraded my kernel. I recompiled both and tried again. Still nothing. I investigate in more detail and discover that the board I have is different from the one originally described -- it has a different chipset to the one expected, and this chipset doesn't work with Linux yet (a native driver is in development, but isn't ready for use yet).
At this point, I give up on getting the device to work, install it in a Windows machine and use network bridging to connect the Linux machine via a cable to that one. My other alternative was to take the card back to the shop, try to convince them to take it back despite the fact that it has been used and has no faults, and buy a more expensive one that would work.
I don't think this is an out-of-the ordinary experience, given how many times I've had similar ones.
Distros will not be able to come equipped with the ability to play all the patent-encumbered media formats,
There's no reason a $20 commercial distribution couldn't come with a "non-redistributable" disc that includes these in closed-source form.
And when new linux users complain of drivers not being installed automatically, they're probably thinking of their new ATI or Nvidia card that have proprietary, GPL unfriendly drivers.
Interesting. My last SuSE install automatically installed the ATI drivers for me. It did have to download them from the Internet because they weren't on the disc it came on, but the install program knew exactly where to get them from. Are you sure you're not using a particularly unfriendly distribution?
Unfortunately, that doesn't apply to the bits required to play DVDs for some reason
It's because of the ~$5 license fees that are required for the patents on decoding MPEG2 video.
Yes, and the source of the kernel module is distributed under the terms of the GPL. I don't see any violation here. It happens that part of the source for it is a lump of binary data that it manipulates by causing it to be executed, but that's fine as that data is *not* derivitive of the kernel, and you won't find a court of law that will say otherwise, which is the key issue here.
Copyright licenses (like the GPL) only apply when copying is taking place. The binary driver does not copy anything from the kernel, so the GPL doesn't apply to its distribution.
"E.g. if glibc was GPL it means you couldn't write closed source binary only software. Therefore the glibc package is LGPL which allows this."
Just correcting a minor misapprehension: glibc is *not* LGPL; it is "GPL with the libc exception", which is GPL modified by an extra grant of rights that allows you to (this is my paraphrasing, because I don't have the text in front of me) link to the library and redistribute under any terms you wish as long as what you distribute does not fulfil substantially the same purpose as the original library; i.e. you can't use it as the basis to write another C library, but just about any other use is fair game.
You misunderstand a basic element of copyright law, which is this: there must be copying taking place for any licence (which the GPL is) to be relevant.
In this case, there is no copying:
1. Linus et al write the Linux kernel, and design interfaces that allow it to dynamically load modules. They license this under the GPL.
2. nVidia develop software that manages their video cards which has an interface defined by nVidia to allow it to integrate with operating system kernels that support this interface. No copying has taken place, and this software can be licensed under whatever terms nVidia wish.
3. nVidia write a compatibility layer that uses the interfaces designed by Linus et al in step 1 to provide the interface they designed themselves in step 2. This may legally-speaking be a derivitive work of the work produced in step 1, at which point it may only be distributed under a license agreed to by the authors of step 1 (i.e., it can only be distributed under the GPL). Or it may not, it's kind of hard to tell. Relevant case law includes the decision that the fact that BSD Unix copied interface definitions from System V Unix doesn't mean that BSD Unix is a derivitive of System V. The waters are rather muddy and a court case could go either way in my non-expert opinion. It may also be a derivitive of the code produced in step 2, but that's ok because that was written by nVidia who will automatically grant permission to use this under the GPL.
4. The code produced in step 1 is licensed under the GPL, so distributors are free to distribute it as they wish, as long as they do so under the terms of the GPL and either provide source code or an offer to provide source code at a later date.
5. The code produced in step 2 is licensed by nVidia for free redistribution in binary form, so distributors can distribute it however they like.
6. The code produced in step 3 is licensed by nVidia under the GPL, so can be distributed under the same terms as step 4.
7. The GPL states that "mere aggregation on a storage medium" does not bring code under its scope, so there is no problem with distributing all 3 together.
You can see that at no point has any license condition been violated. It's pretty important, however, that step 2 takes place either before step 3 or by a totally independent group of developers. Otherwise step 2 could be argued to have copied from step 3. The step 2 developers also should not know the details of the Linux kernel interfaces, so that it can be argued that step 2 cannot possibly be a derivitive of step 1 (i.e. it should be a clean room implementation). As long as nVidia et al have followed this procedure, there is absolutely no legal issue with distributing their code. And if they haven't, it is nVidia who are violating the GPL, not Kororaa.
IMO, the "shim" is irrelvant from a legal perspective. It only exists for engineering purposes because there is no standard module ABI.
You're wrong. The shim is very important legally speaking. The shim itself is a derivitive of the linux kernal, therefore legally speaking it must be distributed under the GPL. However, parts of it are not derivitive of the kernel -- these are the parts that were designed entirely independently from the kernel. If the ABI that it supports is one of these parts (it need not be for engineering reasons, but for legal reasons the companies that have produced these *should* have ensured that it was by having it designed by somebody with no knowledge of linux kernel internals) then anything implemented using that ABI is *not* derivitive of the Linux kernel and need not be distributed under the GPL.
This is absolutely basic copyright law, and anyone who yells "but the GPL says..." or "but Linus says..." are missing the point. It doesn't matter what either of these are saying, because all that matters is whether what nVidia et al have done is *unauthorised copying* under copyright law as it currently stands. And that hinges only on the question of whether the ABIs they have produced are derivitive of linux kernel internals.
To put it another way, it is possible to develop a "shim" of precisely the same nature as the ones we're discussing that would enable you to load binary drivers with some preexisting ABI. This has, in fact, been done more than once: captivefs is a shim that lets you use Microsoft's NTFS driver, and ndiswrapper is a shim that lets you use drivers written to Microsoft's NDIS network driver ABI. Does the existence of these layers mean that all of these drivers, developed with no intention of running them under Linux at all, are suddenly GPL violations? Or are captivefs and ndiswrapper's shims GPL violations despite the fact that they distribute source code under the GPL as required? Or perhaps somebody would be violating the GPL by distributing ndiswrapper and an appropriate driver on the same media, despite the "mere aggregation" clause in the GPL clearly stating that this isn't a problem?
Erm... "yes, it is."
Note to self: proofread post before posting.