Have you considered the effect of the social and legal stigma associated with the state's position on those substances?
Yes I have. But no, while it might have an effect, this effect can't be very big, since even you claim that "Nearly 40% of people will admit in a closed study to using marijuana on a regular basis", it can't be that big.
The fact is: most people I've come across that smoke mariuhana on a regular or semiregular basis: (a) isn't someone I would characterize as "smart" or "clever", (b) tends to focus a lot of their attention to it (as opposed to more productive things, like work, studies, or family).
This leaves us with two options: (a) Marihuana makes you stupid, or (b) Marihuana attracts stupid people. I don't know which one is most important, but I guess they both contribute to the picture.
My guess is that you tend to hang out around a lot of (dope-smoking or not) losers. Thus not seeing how much more intelligent us normal people behave.
Seriously, if we define intelligence, as the mental ability to achieve the goals you have (such as inventing a new scientific theory, earning a shitload of money, becoming a dictator in some banana-republic, scoring a lot of babes, maintain a happy circle of family and friends, or write some great software), then "stoners" seems to have a long way to go, before reaching anything I would call intelligent.
In fact, most drugs, not just cannabis, seems to reduce this ability. With perhaps a few exceptions. Caffeine seems to have positive effects for at least some people. Cocaine seems to have a short-time positive effect (but often ends badly after a few years). Nicotine seems to have a small detrimental effect, although most people seems to get by anyway.
Actually, the paper is pretty much an urban legend itself, as it makes very unrealistic assumptions. It assumes that using ~10 times as much memory as you really need is without cost. It isn't. First, cache is important, and if you use a lot of memory, you will lose, due to memory being slow. Secondly, RAM is expensive, and in the 32-bit world, address-spaces are limited.
The paper is raising some important theoretical points, but there's a reason no language implementation is using it's ideas. The assumptions made in the paper may have made sense in 1987, when everybody assumed we would soon have large amounts of RAM, and nobody expected that the large amounts of RAM we would get would be so slow that PC's would need 3-level cache-hierarchies.
Appel is certainly a very clever guy, but anyone quoting this paper today, is either a troll, or simply uninformed.
Just compare C++ Corba to Java Corba. In C++ Corba...
The C++ Corba bindings are incredibly obtuse. The "smart" pointers there are incredibly "unsmart", and the semantics of memory management is rather strange.
Upcasts are (conceptually?) new objects, meaning that you can free a CORBA_Object_ptr object, even if you have another *_ptr to a *::_narrow()'d version of it. In fact, you should, as that is the only way to guarantee the CORBA_Object ever gets freed! To keep some level of performance, while maintaining this obtuse semantics, even objects with plain pointers have to be reference-counter. Furthermore, when you (conceptually) deep copy an object with *::_duplicate(), in reality all you are doing is increasing a reference count. Thus, you will have to worry about reference counting whether you use CORBAs smart pointers or not! A further complication comes with out-parameters, which means that in addition to *_ptr, you will also need *_out for function out-arguments. All to keep the reference-counting (before we add smart pointers (the *_var types)) "sane".
True enough, using the *_var types make CORBA look almost sane, but they are optional (for performance reasons), and this complicates the CORBA C++ binding a lot. Actually, I'm yet to be convinced that the *_var types actually work sane enough, or get a clear explanation of when they work, because everything in the C++ binding remains nonintuitive. With typical implementations of smart pointers, such as e.g. boost::shared_ptr, new objects will have a reference count of zero, untill they are managed by a smart pointer, and when the reference count decreases to zero, the object will be free'd. Given the obtuse semantics described above, this is not possible with CORBA, as each new object will have a reference count of 1
Ok, maybe this explanation was as obtuse as the CORBA C++ bindings themselves, but it serves to illustrate my point. It would not be particularly hard to create a C++ CORBA binding that was as easy to use as Java's. It just happens that the CORBA C++ binding was designed by a committe that worried more about performance, multithreading, pre-standard-C++-compatibility, and the NIH-syndrome, than something clean and useful. IMHO, they should have left the micro-optimize-the-hell-out-of-it to the C binding, and left a clean C++ binding, but they didn't. Of course, all of this is in hindsight, at the time the bindings were created, I'm sure all the decisions made perfect sense!
Biometric scanners, PGP encryption, What's next? While undoubtedly fancy, I don't think they make your data that much more secure. While it probably makes it a bit more difficult to access you data, as soon as your data is stolen, it is stolen, and unless you get it back fast, the blackhats will have all the time in the world to try to access it. And chances are, they will. Also, these security solutions are brittle. In case something bad happens, you might not be able to access your data yourself!
No, if you want to secure your data, you do it by using physical security. Lock your laptop in a briefcase that takes some time to break into. Add some sort of signalling device in case it gets stolen (it already exists for cars, so why not laptops? In any case, it doesn't need to be much harder than putting a cellphone in there, they can be traced...).
And follow the same procedures as, say, the cash transportation people. Your locked briefcase will be transported inside a locked safe in your car. The safe could be of the kind that needs two keys, one that's your personal key, and one that's either your companions personal key, or that is distributed to your customers and someone at your main office.
When the car is parked, it is either in a secure garage, you have a guard (i.e. the receptionist at your customer location) watching it, or you bring your laptop with you (in the locked briefcase). When travelling with your laptop, make sure you are not alone (i.e have the customer meet you at the parking lot, or bring some company). Be on constant alert for suspicious people. If someone is loitering at the parking lot, don't go there untill they are gone, and make sure to tell your customer why. Always park with the rear end towards a hindrance, in case you need to escape quickly. Make a deal with a security company to provide you with assistance in case anything happens, or if you have to enter an area that you feel is "risky".
If you follow these procedures (you have to weight cost against benefit here, but the most basic procedures: screening parking lots, a locked briefcase, a locked safe, a cellphone, and some caution, is very cheap), my guess is that unless your data is some sort of government top secret stuff, most insurance companies would be happy. But if it really is that valuable, you can increase your security with more guards, and one or more extra cars that will follow your car around and screen any areas you are entering before you are leaving your car...
I also think www.com, www.net, and www.org is cool (not the sites, but the domainname). And all the other silly domains, like net.com, com.org.net, yes.no, goatse.cx, slashdot.org, and so on...
I remember thinking that the GUI (i.e. Mosaic) was sort of nice, and the html was sort of interesting, but it wasn't clear to me that it was anything more than a friendly user interface to FTP and Gopher. Turns out, I was wrong.
It never occurred to me that hotels might have a record of every time you opened your door.
Knowing who entered the door, and with which card is obviously of great importance to the hotel. More importantly than knowing when you entered your room, they want to know when hotel employees entered your room. It's definitely in the hotels interest to investigate illoyal employees as fast as possible.
I agree 100%. The only sane solution is to have read-only disposable cards containing a random or serial number, and having each card reader communicate with a central computer. Storing stuff on the card seems expensive and counterproductive.
There are lots of off-the-shelf products of this type, so I can't imagine a solution with higher costs of purchase, higher costs of operation, as well as higher security risks, would have much of a chance in the marketplace.
A more believable risk would be that someone could enter your room simply by swiping enough of these cards, because the manufacturer limited the number of cards to, say, 1000 different cards. This would be cheaper both for the manufacturer and the buyer, so it has a higher likelihood of occuring.
I've wondered about this myself. I guess you have to ask a nazi tracker administrator about it.
Luckily, most nazis are administering small trackers, where they only block consistent leechers, and only manually. In that case, it isn't a big deal anyway, and you get a chance to explain yourself if you disagree with the decision.
Well it seems that this could completely demolish the protocol. If everyone used this and then set their upload to the minimum (what, 1kbps?) it would take forever and a day to get files from Bittorrent.
No, it wouldn't. The only thing this has any effects on, are tracker stats.
Bittorrent clients upload to who uploads most to them. And then they add a certain amount of randomness so that they get to try different peers. They don't care about the stats from the tracker, and neither should they, as they can be easily forged anyway (just change a line in your favourite bittorrent client and recompile).
If the bittorrent protocol was so brittle as to care about easily forged information, it would never have worked as open source software anyway.
So why do people care about trackers stats? Well, some people like to publish them (e.g. to make leechers ashamed). Some are nazis, and want to block leechers from their trackers. And some go beyond nazis, and want to block multi-tracker clients, etc, because it disturbs their tracker stats. This "vulnerability" is only a vulnerability to the two last groups...
The real questions are:
- why these tecniques never gained importance (the first studies are from S.Unger in 1969)?
Probably because at all points through history the chip companies had other, cheaper techniques to get their next generation of chips out of the door, without getting down in costly research that had to make them redesign everything...
- what about the EDA industry?
Probably because they reasoned their customers went with the previous answer...
It should all be taken up pretty quickly by openoffice 25.0.
There are however some limits. Assuming we need at least a few atoms per bit with nanoscale technology, counting in zettabytes would probably be the near the limit for portable devices. I don't bother making a distinction between primary and secondary storage here, because nobody knows what the future will bring.
Then again, atoms can be excited into several states, and the future might bring storage devices working with this, or even subatomic particles, or various kinds of exotic matter. In that case, it's hard to come up with an educated guess.
Do you know if they had fuel to put in those buses?
This can be bought at gas stations. Not that hard, really... Even if there was a fuel shortage, we are talking about the government. They can expropriate the entire fuel station, if necessary. And they can use supplies from the military.
Electricity to power the fuel pumps?
Oh, please. First, they had advance warning. Secondly, even if the city didn't have emergency generators themselves, don't tell me they couldn't find the resources to buy them or lease them from some company when the shit happened. In fact, I think most companies would be more than happy lending out both generators and qualified personell to handle them for free.
People to drive the buses?
Who drives the buses regularly? Don't tell me they can't be used, because I can't even imagine a bus-driver not willing to work >12-hour days, if it meant saving lots of peoples lives. Even if the bus-drivers were all occupied elsewhere, I'm sure someone could drive the fucking buses. There are lots of bus-drivers around, just ask the fucking motorist service. And if you can't find any fucking bus-drivers, just use a fucking truck-driver. Give them a temporary license, if necessary.
Perhaps the answer is a bit more involved.
Most likely, but it's very hard to find anyone else to blame than "the people in charge".
You see, there is a form of written communication that predates the computer, and is very secure once you've taken care of the physical security. It is also portable, easy to carry, does not require electricity, or any form of advanced machinery. It will survive in temperatures from far below human tolerance, to +70 celcius. It can be damaged by exposure to water, but because of it's flexible form, can easily be stored in an airtight container. This miracle medium is called: PAPER!
You write the passwords you need on a piece of paper. If there are lots of passwords to be remembered, an electronic device called a "printer "can transfer the passwords from a computer at your office building to the paper.
The paper is carried by the admin to whatever clients he need to go to. Once at the client, he fetches this piece of paper, and use his eyes to retrieve the passwords he need. The passwords are typed manually by the admin into the clients computer.
As your admin finishes his job, the paper containing the passwords can be easily destroyed. A device specifically made for this, called a "paper shredder" exists in many offices, and your admin is likely to find one at the clients office.
If a client does not have a paper shredder, the admin may choose to use the fallback solution of tearing apart the paper with his hands, followed by flushing it down the toilet. Another solution is to ignite the paper with a device called a "lighter", something that can usually be found at the back entrance of the clients building (just ask one of the smokers there).
What would stop a malicious user putting a wrapper around really_cool_internal_function() called myprog_plugin_api_hack_internal_function()?
You are right. Since the program itself is GPL, they can create a fork, and modify it all they want. Hmmm... this is tricky to get right. Even if you explicitly list the allowed functions in the license, there is nothing preventing them from changing one of them (that they don't need), to do something else.
I think the only solution to this problem is to only use the exception on the "official" release. Any derived works will be GPL only. I'm not really sure if the GPL allows that. But you can always dual-license, one of the licenses being GPL, and the other being one that allows plugins, but no modifications.
Now, if lightning should strike you, and you are suddenly unable to release further official versions, all later releases will be GPL only. This may or may not be what you want. If it's not what you want, arrange whatever you want to happen with a law-firm as part of your will.
The obvious choice is to lock everything down as much as possible. And then add stuff to the API by request. The "allowed" parts of the API can easily be described with one sentence, e.g: "Only the functions and global names having names starting with 'myprog_plugin_api_' are allowed to use in plugins that are not released under the GPL".
Nope, it doesn't mean that. That would be the case if it was trademarked. When it's copyrighted, it means that you can't take the license text and redistribute and/or change it without the authors permission.
The copyright of the GPL does not allow you to make changes to it. Period. End of discussion.
Actually, you can't. The GPL specifically disallows adding limitations to the license. See paragraph 6 and 7. The only exception for this is paragraph 8.
You can, however, add a clause to give the recipient more rights.
But Linux would not have existed without GNU right? Yes I think it would
I doubt it would. According to those old usenet posts about linux' beginning, Linus started linux as a better minix, so he would be able to run GNU software.
That doesn't mean that we wouldn't have had something else today (FreeBSD being an obvious candidate). But linux would probably never have existed.
Ok, maybe I'm wrong. It's not unlikely that Linus would have come up with some other excuse to work on an OS kernel instead of what he was supposed to do at school. Or maybe someone else would have done it. But as the history stands now, Stallman is actually quite correct in saying that GNU was important for linux, both historically, and now.
Yeah, well, my favourite has always been GNU/Linux/BSD/xorg/Gnome/KDE (at least for desktop users). But then again, maybe it should be simplified to something pronouncable, such as KGnuBSDLinuXorGnome...
This software is licensed under the General Public License (GPL), version 2 (see below for the full text of this license). As a special exemption, software plugins using the documented plugin API for this software, will be allowed to be distributed and/or run-time linked with this software regardless of their license.
[Explain the plugin API, or where to find the "documented" parts of it]
Slashdot Mirror
Yes I have. But no, while it might have an effect, this effect can't be very big, since even you claim that "Nearly 40% of people will admit in a closed study to using marijuana on a regular basis", it can't be that big.
The fact is: most people I've come across that smoke mariuhana on a regular or semiregular basis: (a) isn't someone I would characterize as "smart" or "clever", (b) tends to focus a lot of their attention to it (as opposed to more productive things, like work, studies, or family).
This leaves us with two options: (a) Marihuana makes you stupid, or (b) Marihuana attracts stupid people. I don't know which one is most important, but I guess they both contribute to the picture.
Yeah, like smoking more dope...
Seriously, if we define intelligence, as the mental ability to achieve the goals you have (such as inventing a new scientific theory, earning a shitload of money, becoming a dictator in some banana-republic, scoring a lot of babes, maintain a happy circle of family and friends, or write some great software), then "stoners" seems to have a long way to go, before reaching anything I would call intelligent.
In fact, most drugs, not just cannabis, seems to reduce this ability. With perhaps a few exceptions. Caffeine seems to have positive effects for at least some people. Cocaine seems to have a short-time positive effect (but often ends badly after a few years). Nicotine seems to have a small detrimental effect, although most people seems to get by anyway.
The paper is raising some important theoretical points, but there's a reason no language implementation is using it's ideas. The assumptions made in the paper may have made sense in 1987, when everybody assumed we would soon have large amounts of RAM, and nobody expected that the large amounts of RAM we would get would be so slow that PC's would need 3-level cache-hierarchies.
Appel is certainly a very clever guy, but anyone quoting this paper today, is either a troll, or simply uninformed.
The C++ Corba bindings are incredibly obtuse. The "smart" pointers there are incredibly "unsmart", and the semantics of memory management is rather strange.
Upcasts are (conceptually?) new objects, meaning that you can free a CORBA_Object_ptr object, even if you have another *_ptr to a *::_narrow()'d version of it. In fact, you should, as that is the only way to guarantee the CORBA_Object ever gets freed! To keep some level of performance, while maintaining this obtuse semantics, even objects with plain pointers have to be reference-counter. Furthermore, when you (conceptually) deep copy an object with *::_duplicate(), in reality all you are doing is increasing a reference count. Thus, you will have to worry about reference counting whether you use CORBAs smart pointers or not! A further complication comes with out-parameters, which means that in addition to *_ptr, you will also need *_out for function out-arguments. All to keep the reference-counting (before we add smart pointers (the *_var types)) "sane".
True enough, using the *_var types make CORBA look almost sane, but they are optional (for performance reasons), and this complicates the CORBA C++ binding a lot. Actually, I'm yet to be convinced that the *_var types actually work sane enough, or get a clear explanation of when they work, because everything in the C++ binding remains nonintuitive. With typical implementations of smart pointers, such as e.g. boost::shared_ptr, new objects will have a reference count of zero, untill they are managed by a smart pointer, and when the reference count decreases to zero, the object will be free'd. Given the obtuse semantics described above, this is not possible with CORBA, as each new object will have a reference count of 1
Ok, maybe this explanation was as obtuse as the CORBA C++ bindings themselves, but it serves to illustrate my point. It would not be particularly hard to create a C++ CORBA binding that was as easy to use as Java's. It just happens that the CORBA C++ binding was designed by a committe that worried more about performance, multithreading, pre-standard-C++-compatibility, and the NIH-syndrome, than something clean and useful. IMHO, they should have left the micro-optimize-the-hell-out-of-it to the C binding, and left a clean C++ binding, but they didn't. Of course, all of this is in hindsight, at the time the bindings were created, I'm sure all the decisions made perfect sense!
No, if you want to secure your data, you do it by using physical security. Lock your laptop in a briefcase that takes some time to break into. Add some sort of signalling device in case it gets stolen (it already exists for cars, so why not laptops? In any case, it doesn't need to be much harder than putting a cellphone in there, they can be traced...).
And follow the same procedures as, say, the cash transportation people. Your locked briefcase will be transported inside a locked safe in your car. The safe could be of the kind that needs two keys, one that's your personal key, and one that's either your companions personal key, or that is distributed to your customers and someone at your main office.
When the car is parked, it is either in a secure garage, you have a guard (i.e. the receptionist at your customer location) watching it, or you bring your laptop with you (in the locked briefcase). When travelling with your laptop, make sure you are not alone (i.e have the customer meet you at the parking lot, or bring some company). Be on constant alert for suspicious people. If someone is loitering at the parking lot, don't go there untill they are gone, and make sure to tell your customer why. Always park with the rear end towards a hindrance, in case you need to escape quickly. Make a deal with a security company to provide you with assistance in case anything happens, or if you have to enter an area that you feel is "risky".
If you follow these procedures (you have to weight cost against benefit here, but the most basic procedures: screening parking lots, a locked briefcase, a locked safe, a cellphone, and some caution, is very cheap), my guess is that unless your data is some sort of government top secret stuff, most insurance companies would be happy. But if it really is that valuable, you can increase your security with more guards, and one or more extra cars that will follow your car around and screen any areas you are entering before you are leaving your car...
I know I do :-)
I also think www.com, www.net, and www.org is cool (not the sites, but the domainname). And all the other silly domains, like net.com, com.org.net, yes.no, goatse.cx, slashdot.org, and so on...
But then again, I could be a bit geeky here...
Please tell me where you were wrong ;-)
I would!
Knowing who entered the door, and with which card is obviously of great importance to the hotel. More importantly than knowing when you entered your room, they want to know when hotel employees entered your room. It's definitely in the hotels interest to investigate illoyal employees as fast as possible.
There are lots of off-the-shelf products of this type, so I can't imagine a solution with higher costs of purchase, higher costs of operation, as well as higher security risks, would have much of a chance in the marketplace.
A more believable risk would be that someone could enter your room simply by swiping enough of these cards, because the manufacturer limited the number of cards to, say, 1000 different cards. This would be cheaper both for the manufacturer and the buyer, so it has a higher likelihood of occuring.
Luckily, most nazis are administering small trackers, where they only block consistent leechers, and only manually. In that case, it isn't a big deal anyway, and you get a chance to explain yourself if you disagree with the decision.
The "beyond nazi" position is more debatable.
No, it wouldn't. The only thing this has any effects on, are tracker stats.
Bittorrent clients upload to who uploads most to them. And then they add a certain amount of randomness so that they get to try different peers. They don't care about the stats from the tracker, and neither should they, as they can be easily forged anyway (just change a line in your favourite bittorrent client and recompile).
If the bittorrent protocol was so brittle as to care about easily forged information, it would never have worked as open source software anyway.
So why do people care about trackers stats? Well, some people like to publish them (e.g. to make leechers ashamed). Some are nazis, and want to block leechers from their trackers. And some go beyond nazis, and want to block multi-tracker clients, etc, because it disturbs their tracker stats. This "vulnerability" is only a vulnerability to the two last groups...
- why these tecniques never gained importance (the first studies are from S.Unger in 1969)?
Probably because at all points through history the chip companies had other, cheaper techniques to get their next generation of chips out of the door, without getting down in costly research that had to make them redesign everything...
- what about the EDA industry?
Probably because they reasoned their customers went with the previous answer...
There are however some limits. Assuming we need at least a few atoms per bit with nanoscale technology, counting in zettabytes would probably be the near the limit for portable devices. I don't bother making a distinction between primary and secondary storage here, because nobody knows what the future will bring.
Then again, atoms can be excited into several states, and the future might bring storage devices working with this, or even subatomic particles, or various kinds of exotic matter. In that case, it's hard to come up with an educated guess.
This can be bought at gas stations. Not that hard, really... Even if there was a fuel shortage, we are talking about the government. They can expropriate the entire fuel station, if necessary. And they can use supplies from the military.
Electricity to power the fuel pumps?
Oh, please. First, they had advance warning. Secondly, even if the city didn't have emergency generators themselves, don't tell me they couldn't find the resources to buy them or lease them from some company when the shit happened. In fact, I think most companies would be more than happy lending out both generators and qualified personell to handle them for free.
People to drive the buses?
Who drives the buses regularly? Don't tell me they can't be used, because I can't even imagine a bus-driver not willing to work >12-hour days, if it meant saving lots of peoples lives. Even if the bus-drivers were all occupied elsewhere, I'm sure someone could drive the fucking buses. There are lots of bus-drivers around, just ask the fucking motorist service. And if you can't find any fucking bus-drivers, just use a fucking truck-driver. Give them a temporary license, if necessary.
Perhaps the answer is a bit more involved.
Most likely, but it's very hard to find anyone else to blame than "the people in charge".
You write the passwords you need on a piece of paper. If there are lots of passwords to be remembered, an electronic device called a "printer "can transfer the passwords from a computer at your office building to the paper.
The paper is carried by the admin to whatever clients he need to go to. Once at the client, he fetches this piece of paper, and use his eyes to retrieve the passwords he need. The passwords are typed manually by the admin into the clients computer.
As your admin finishes his job, the paper containing the passwords can be easily destroyed. A device specifically made for this, called a "paper shredder" exists in many offices, and your admin is likely to find one at the clients office.
If a client does not have a paper shredder, the admin may choose to use the fallback solution of tearing apart the paper with his hands, followed by flushing it down the toilet. Another solution is to ignite the paper with a device called a "lighter", something that can usually be found at the back entrance of the clients building (just ask one of the smokers there).
I hope this suggestion helps!
You are right. Since the program itself is GPL, they can create a fork, and modify it all they want. Hmmm... this is tricky to get right. Even if you explicitly list the allowed functions in the license, there is nothing preventing them from changing one of them (that they don't need), to do something else.
I think the only solution to this problem is to only use the exception on the "official" release. Any derived works will be GPL only. I'm not really sure if the GPL allows that. But you can always dual-license, one of the licenses being GPL, and the other being one that allows plugins, but no modifications.
Now, if lightning should strike you, and you are suddenly unable to release further official versions, all later releases will be GPL only. This may or may not be what you want. If it's not what you want, arrange whatever you want to happen with a law-firm as part of your will.
The obvious choice is to lock everything down as much as possible. And then add stuff to the API by request. The "allowed" parts of the API can easily be described with one sentence, e.g: "Only the functions and global names having names starting with 'myprog_plugin_api_' are allowed to use in plugins that are not released under the GPL".
Then we agree...
Nope, it doesn't mean that. That would be the case if it was trademarked. When it's copyrighted, it means that you can't take the license text and redistribute and/or change it without the authors permission.
The copyright of the GPL does not allow you to make changes to it. Period. End of discussion.
You can, however, add a clause to give the recipient more rights.
I doubt it would. According to those old usenet posts about linux' beginning, Linus started linux as a better minix, so he would be able to run GNU software.
That doesn't mean that we wouldn't have had something else today (FreeBSD being an obvious candidate). But linux would probably never have existed.
Ok, maybe I'm wrong. It's not unlikely that Linus would have come up with some other excuse to work on an OS kernel instead of what he was supposed to do at school. Or maybe someone else would have done it. But as the history stands now, Stallman is actually quite correct in saying that GNU was important for linux, both historically, and now.
Yeah, well, my favourite has always been GNU/Linux/BSD/xorg/Gnome/KDE (at least for desktop users). But then again, maybe it should be simplified to something pronouncable, such as KGnuBSDLinuXorGnome...
This software is licensed under the General Public License (GPL), version 2 (see below for the full text of this license). As a special exemption, software plugins using the documented plugin API for this software, will be allowed to be distributed and/or run-time linked with this software regardless of their license.
[Explain the plugin API, or where to find the "documented" parts of it]
[Full text of GPL]