If you want them to spell out how they work for you, you'll have to play by their rules. If you don't like that, that's fine too. You don't have to know now their file formats work to use their product, and when it comes down to it you don't even have to use their product.
I don't think that the problem is really about understanding how these file formats work. The old.doc format has been reverse-engineered successfully (including features that were not documented by Microsoft) and most parts of the new Office XML format are trivial to understand.
The problem is that XML uses schemas for defining how the data is stored in the document (data types, structure, etc.) and for telling the parsers how the documents can be validated and processed. By not allowing free distribution of this information, Microsoft is making it very difficult for other tools to process the Office XML documents. All Office XML documents contain direct references (URIs) to this information. So regardless of whether the developers of the other tools understand the file formats or not, their tools cannot process the XML documents in the "right" way because the schemas are not available freely.
Also, notice the trend. Virtually everyone (Netscape, TrollTech, etc.) starts with their own crappy license, and eventually, switches to a dual-licensing model that includes GPL. Follow the lesson, and start off on the GPL side from the start.
Although I don't think that Sun could have licensed everything under the GPL because of the reasons mentioned in TFA (proprietary code from third parties), it is really a pity that they do not allow dual-licensing with the CDDL and GPL.
Unlike some GPL zealots here, I do like Sun and Solaris. My main workstation is a Sun Blade (my previous one was a Sun Ultra 60) and I am happy with it. However, I am disappointed that Sun has derived the CDDL from the MPL and has removed the note about dual licensing. It is possible for Sun to dual-license their code despite of the proprietary drivers that they use: the CDDL would apply when the code is linked in the Solaris kernel and the GPL or CDDL would apply when the code is used in other projects.
I can understand that Sun is afraid that dual-licensing would be one-way only: some code would be borrowed in other GPL projects and would not come back to Sun (or at least not to the Solaris kernel) because it could not be dual-licensed again. But if this is the only reason, then I think that it is short-sighted. Sun could certainly benefit from code that is GPL-only as long as it is outside the kernel. Also, some GPL code could even be contributed back to the Solaris kernel if the original authors agree to have it relicensed under the CDDL. Showing some goodwill with respect to the GPL might motivate some authors to dual-license their code. But by not being GPL-compatible, they are sending a message that will probably not encourage others to contribute to OpenSolaris. They may be able to build a small ecosystem around Solaris, but probably not as large as it could have been if they had been more GPL-friendly.
Actually, I doubt that the software could even be close to any Open Source definition. This would be incompatible with the following statement (from the ITworld.com article linked previously):
Details of how the system works are being kept secret, Hemler said. "We're intentionally coy about the technology that is used in this because we think it gives the good guys an advantage over the bad guys," he said. "Think of it as an assembly of commonly available Microsoft software, using techniques from Microsoft Research and best practices that the law enforcement community shared with us."
So they want to keep the system secret, and will not even mention how it works. Not really Open Source nor Free Software... It may not even be considered as freeware if it can only be distributed to a few law enforcement agencies.
The article from MSNBC mentioned in this story is very light on details. Thanks to Google News, here are some more useful articles about CETS, the Child Exploitation Tracking System:
These articles mention that CETS is based on MS SQL Server (for the database) and some bits of MS SharePoint (for the web portal). Also, the system uses.NET and web services (SOAP/XML) for exchanging data so it should be possible to integrate this with non-Microsoft systems (in theory).
What is not mentioned in any of the articles is whether the system is really open-source, as claimed in the headline of this Slashdot story and the related MSNBC article. The only statements that I found about this said that Microsoft Canada will "make [CETS] available free of charge to any law enforcement agency that wants to use it." But no mention of any Open Source license.
I agree that the problem is not a new one. However, think about the following scenario:
A malicious user registers a dozen domain names using various incorrect spellings based on the name of some bank (typosquatters).
For a while, all of these fake domains redirect to the real bank.
The Googlebot indexes all of them and eventually one of these sites replaces the official web site at the top of the Google results (according to the "duplicate removal" described in the article).
Once the malicious user sees that one of his sites has replaced the official one, he stops the redirection for all visitors but the Googlebot.
Result: most visitors will now get a fake site. The official site is gone from the Google rankings.
So although there is nothing new here, the fact that the fake site using a 302 redirection replaces the real site is a golden opportunity for all phishers...
I think that the solution suggested in the article (treating cross-domain 302 temporary redirections as normal links) could be a good workaround, even if this means that Google would not be following the HTTP standard defined by RFC 2616.
Until a few years ago, companies that had trademarks in France were supposed to register their domains under.tm.fr. Apparently, Kraft did register www.milka.tm.fr.
But since the rules have changed (around 2002, I think) the company has been trying to get the domain that had been registered by that lady in the meantime.
Côte d'Or is owned by Kraft as well. You can see it by looking around on http://www.cotedor.be/ or directly on http://www.kraftfoods.be/. Fortunately, they haven't changed the products in any significant way so they still taste good.
I would also also recommend trying Galler chocolate (not owned by Kraft Foods - yet).
From my point of view, copyright is good if it is limited, both in time and in scope.
If I write a book, an essay, a piece of software, or if I create some nice pictures or music, then I don't want to have my work copied by others unless I allow them to do so (the GPL or the Creative Commons licenses are ways to allow that under some conditions).
I think that it is reasonable to allow authors to protect their original works for a limited amount of time. Most authors expect some kind of tangible or intangible benefits when they publish their works. Copying without permission may deprive them from these benefits, so it is good to have some copyright laws protecting the authors.
However, these laws should allow fair use and should include a reasonable time limit. By "fair use", I mean having the right to make personal copies (including conversion to other formats - for example converting music or video to Ogg Vorbis or Theora) or to distribute short excerpts of the works. Note that "fair use" does not include distributing copies to your neighbors or to anybody else via the Internet.
As for the suppying the source, I never understood why people belive that they need to have a link available to the source online to comply with the GPL.
It does not have to be online. The GPL requires you to provide the source code to those who get the binaries from you (e.g., on the same CD or from the same web site) or to include a written offer to give the source code to any third part who requests it. This is stated in paragraph 3 of the GPL.
So the source code does not have to be available online, even if this is a convenient way for some companies to comply with the license. It can also be sent on CD-ROMs or floppy disks to those who request it. The online distribution happens to be cheaper in many cases, but this is not a requirement.
Hell if a company wanted to they could supply you the source in the form of a print out (or alphabit soup) and they would comply with the terms of the GPL license.
Wrong. In paragraph 3 b) of the GPL, you can see that it requires a "complete machine-readable copy of the corresponding source code [...] on a medium customarily used for software interchange". Furthermore, the same paragraph 3 adds: "The source code for a work means the preferred form of the work for making modifications to it.". So distributing the software in some obfuscated form would be a violation of the GPL.
This is false. Skype clients do check for updates, but they do not require the latest version to be installed.
Right. But if the updated client includes an updated protocol, then you will be forced to upgrade if you want to be able to talk to anybody who has upgraded. You could also be forced to upgrade if the registration mechanism is modified.
SIP is a crappy protocol that any person with an ounce of concern for security would look very long and hard at before using.
You are of course aware of the recommendation to use SIP over IPSec or TLS, right? So what are your security concerns, exactly?
In fact, I believe that the implementation of SIP in the mobile world (using the 3GPP standard IMS) makes it mandatory to use IPSec or TLS with SIP. SIP may not be perfect, but I think that the current best practices for its deployment are taking care of most of the issues.
I welcome Skype's technology. Hopefully it will drive innovation for standards based protocols.
I doubt that it will. They are using proprietary protocols and they made it clear that they do not intend to standardize. Not only that, but they also designed the Skype clients in such a way that they must check for updates and always run the latest version before being able to communicate with others. So they could change the protocols as soon as someone manages to reverse-engineer them.
Skype's technology is nice and works well. But if you value standards, open source and compatibility between multiple applications, then you should look at Skype with a more critical eye. You do not have to - it's your choice in the end.
Re:How about using MD5 and SHA-1 togeher
on
SHA-1 Broken
·
· Score: 1
sha1(md5($input)) is weaker than either sha1($input) or md5($input) alone. If one of them is broken, your digest is broken.
But append(sha1($input),md5($input)) is stronger than one of them alone. You would have to break both of them in order to fake a signed message.
It might confuse tinfoil hat types though, or some proxies, who refuse to send referrers because the Orbitz site would break.
Any web admin who has a clue knows that many visitors will not have a valid referer (usually because of a proxy, including some large corporate proxies). So blocking the requests that have no referer would have the unfortunate effect of blocking many legit visitors.
On the other hand, blocking all requests that do have a referer but for which the referer does not match the site itself or one of its affiliates is likely to work.
There are already a number of web sites doing that: they block you or redirect you to their home page if your requested a deep link and your request contains a referer and the referer does not match several variations of the site itself (including IP addresses) or one of its affiliates. This is even relatively easy to set up with Apache using mod_rewrite and some environment variables.
So if someone says that they are downloading Firefox, they can just get a certificate, say it's from the "Firefox Foundation" (a mythical yet believable organization) downloading a program called "Firefox Browser", and most people would click yes.
Right. This is one of the things that the article was complaining about. Unfortunately, there is no easy way to prevent that kind of scams: Verisign could check for obvious stuff such as "CLICK YES..." but it would be had for them or for anyone else to check for names that are similar to the names of companies or individuals all over the world.
This defeats the whole purpose of having certificates to prove the content is from who it claims to be, when you can just lie about it!
If you accept all certificates blindly, then yes. If you pay a bit more attention, then no. You should only trust the certificates for the level of security that they provide, not more.
Once you have determined that a certificate is good, you can choose to let your software remember that decision so that you do not have to check it again the next time you see it.
In particular, while software patents are one of those ideas that sounded promising but has been shown not to work well in practice, copyright has been quite the opposite.
I agree and I wish that more people had such a balanced point of view, both for software patents and copyright.
The problem (and the cause that is worth fighting for) is not that patents are universally bad or were a bad idea to start with. But in practice, software patents are doing more harm than good and have the potential to do even more harm (especially to open source software).
Regardless of what was the original intent or claimed intent of software patents, the result today is a big mess that harms most SMEs and individuals while it only provides limited benefits to a few big players and a few parasites (parasites are companies that live only on patents and have no real products). And even for the big players, the race for software patents looks more like the arms race during the cold war. In any case, this does not provide long-term benefits for the population or even for businesses, despite what the lobbyists paid by the big players or parasites would like the lawmakers to believe.
I also agree that copyright is useful and should be respected. I disagree with those who reject all kinds of "intellectual property" and use this as an excuse to make illegal copies of movies, music or software. Using the terms "intellectual property" is dangerous because this expression mixes several concepts, bad (software patents) or good (copyrights, trademarks).
Despite the often made but really pretty shallow arguments against copyright, it has proven to be a valuable tool in balancing modern economies where information is valuable.
I would like to add a minor correction: limited copyright has proven to be a valuable tool [...]. Limited copyright, both in scope (fair use) and in time (a few years, a few dozens at most) is indeed useful. Unlimited copyright does not encourage creativity and does not help society.
Eric Schrock, a developer for Sun, posits his opinions on why the GPL would not be a good fit for Sun.
Well, this is basically rehashing some well-known arguments that are often brought up in a GPL vs. BSD debate or Free Software vs. Open Source software.
In a nutshell, the GPL gives you some freedoms but only if you accept its rather strict conditions. GPL advocates claim that it is a good thing, while GPL opponents claim that it is a bad thing. The basic idea that differentiates the GPL from other licenses is that a piece of code licensed under the GPL should not be used to give an advantage to non-free software. This is why the GPLed code cannot be linked together with code that is not GPL-compatible. This is also why RMS encourages developers to release their library code under the GPL instead of LGPL, although many developers who are more "open" still release code under the LGPL (e.g., GLib and GTK+, etc.)
The analogy with Oracle having to release their whole code under the GPL is also frequently (ab)used. Nobody is forcing Oracle (or anybody else) to incorporate some pieces of GPLed code into their software. They can easily rewrite something similar on their own, if they need it. If the author of the interesting function wants to promote Free Software and does not want to give an advantage to proprietary software, then his/her wishes should be respected. This is what the GPL does.
If you take the point of view of Oracle and you want to add some functions to your proprietary code, then GPLed software is not better than other proprietary software because you cannot just take it and use it without conditions. But if you take the GPL zealot's point of view, then it makes sense that the GPLed gift comes with some strings attached.
It is just a matter of choice. The arguments from Eric Schrock could interesting if the only option for Sun had been to release the code under the GPL or the CDDL but not both. But there is also the option to dual-license and allow those who get the code to continue their development under the GPL, CDDL, or both. Then anybody, including Oracle as in his example, would have been able to pick the best combination for them. But since Sun did not give any dual-licensing permissions for their code, they are effectively preventing a larger number of free software developers from using their code. It makes sense for them, but some of the arguments brought up in the press release and other public statements are rather misleading.
So, it might be better to say the GPL is be incompatible with the CDDL. No fault in the design of the CDDL.
Fair enough. However, saying that the incompatibility is not the fault of the CDDL would be a bit generous...
The CDDL is derived from the MPL 1.1 from which the explicit dual-licensing statements have been removed. These statements (section 13 of the MPL) are used by Mozilla to allow their code to be licensed under the MPL or GPL, therefore making it GPL-compatible. There is no such provision in the CDDL.
It looks very much like the CDDL is incompatible with the GPL because its authors were not interested in making it compatible. They were fully aware of the consequences of their changes in the wording of the license and the FAQ acknowledges this indirectly.
I should add that even though section 13 has been removed, that does not prevent the author of a piece of software to release his/her code under the CDDL and GPL simulateneously. Authors can release their own work under as many licenses as they want. Dual-licensing is still possible, but not mentioned explicitely in the license. This has the disadvantage that any derivative works are likely to "forget" one of the licenses, unless all contributions are explicitely dual-licensed.
I will grant Sun the benefit of the doubt and assume that their lawyers did not think that section 13 was necessary and that it could cause more problems than it solves. Only paranoid people would think that it was removed in order to make it less likely that some work would be dual-licensed with the CDDL and GPL.
Anyway, this is not very important for the current discussion because:
The only code that has been released so far is licensed under the CDDL only (not GPL).
The code cannot be used in a GPLed program.
The code cannot even be linked with other modules licensed under the GPL (due to mutual incompatibilities in the licenses and GPL requirements that are not fulfilled by the CDDL).
The patent grant applies to the CDDL, not other Open Source licenses.
so, MPL itself is free, but GPL-incompatible, but explicitely allows for other licenses.
Correct.
btw, CDDL is based on MPL 1.1, so it might just be the same wrt "freedom" and "GPL compatibility"
Wrong, unfortunately.
As I wrote in another comment, Sun has removed Section 13 and Exhibit A from the MPL 1.1. These were the parts that allowed the license to be GPL-compatible. So the CDDL is not GPL-compatible. In addition, that cannot be fixed easily because the CDDL 1.0 does not allow the work to be re-licensed under a future version of the same license. So even if the CDDL 1.1 would allow the author of the software to decide that it could be GPL-compatible, that would not apply automatically to anything that has been released under the CDDL 1.0.
There is one thing that I forgot to mention in my previous comment: the CDDL is derived from the Mozilla Public Licence (MPL) 1.1 but at the end of the Detailed description of changes from the MPL, you find this:
Deleted Section 13 of the MPL because it was confusing and unnecessary.
Section 13 of the MPL, titled "Multiple Licensed Code", allows the code to be licensed under the MPL or an alternative license described in Exhibit A (also deleted from the CDDL). For Mozilla, section 13 allows any derived code to be licensed under the MPL or GPL. Sun has removed this section from the CDDL. You can see it at the end of the Redline diffs between MPL1.1 and CDDL (PDF file).
So any code released under the CDDL is definitely incompatible with the GPL. There is also no way to fix that (except if Sun re-released the code under a better license) because Sun has also removed the statements that allowed the code to be used under a "future version of this License" from section 3.1 and section 6 (now 4 in the CDDL).
"Any Covered Software that You distribute or otherwise make available in Executable form must also be made available in Source Code form and that Source Code form must be distributed only under the terms of this License. [...]"
In addition, section 3.4 adds:
"You may not offer or impose any terms on any Covered Software in Source Code form that alters or restricts the applicable version of this License or the recipients' rights hereunder.[...]
In other words, this license is incompatible with the GPL (probably on purpose). As a result, you cannot use any CDDL-licensed code in a GPL-licensed program and you cannot use any GPLed code in a CDDLed program. Both licenses are "viral" and they are mutually incompatible.
Maybe this program will mature in time and I wish the best to the development team.
Let's keep in mind that the original version of the GIMP was written in 1995 by two students before dozens of other developers started contributing to it. The first public version, 0.54, was released in 1996 and had features that were more or less comparable to those available now in Paint.NET. The support for layers was lacking, but it had decent plug-ins, undo and channel operations. It has come a long way since then...
Given enough time and/or contributors, I am sure that Paint.NET could become a very good program. But of course, I hope that the GIMP will always be better...
If you are interested, here is a link to a brief history of the early versions of the GIMP.
Also, if you have a look at some of the other comments posted here, you will see that several people describe Paint.NET as being very slow. So if the GIMP is slow on your system, there is a risk that Paint.NET could be even slower for some operations (such as painting with a large brush).
[...] that way I know that there isn't time/resources wasted loading worthless splash info
A few days ago, I measured the time taken by various operations occuring while the GIMP starts and I posted a summary of the results to the gimp-developer mailing list. Loading and displaying the splash screen takes 7% of the total startup time. These tests were done over NFS, which makes file loading a bit slower, but the percentage of the time spent loading the splash screen is about the same when everything is loaded from a local hard disk.
I think that spending only 7% of the time for the splash screen is reasonable, considering that it also helps you to see what takes time (e.g., loading the scripts and the tool settings). Anyway, there is the --no-splash option allowing you to skip the splash screen if you do not like it.
Slashdot Mirror
I don't think that the problem is really about understanding how these file formats work. The old .doc format has been reverse-engineered successfully (including features that were not documented by Microsoft) and most parts of the new Office XML format are trivial to understand.
The problem is that XML uses schemas for defining how the data is stored in the document (data types, structure, etc.) and for telling the parsers how the documents can be validated and processed. By not allowing free distribution of this information, Microsoft is making it very difficult for other tools to process the Office XML documents. All Office XML documents contain direct references (URIs) to this information. So regardless of whether the developers of the other tools understand the file formats or not, their tools cannot process the XML documents in the "right" way because the schemas are not available freely.
Although I don't think that Sun could have licensed everything under the GPL because of the reasons mentioned in TFA (proprietary code from third parties), it is really a pity that they do not allow dual-licensing with the CDDL and GPL.
Unlike some GPL zealots here, I do like Sun and Solaris. My main workstation is a Sun Blade (my previous one was a Sun Ultra 60) and I am happy with it. However, I am disappointed that Sun has derived the CDDL from the MPL and has removed the note about dual licensing. It is possible for Sun to dual-license their code despite of the proprietary drivers that they use: the CDDL would apply when the code is linked in the Solaris kernel and the GPL or CDDL would apply when the code is used in other projects.
I can understand that Sun is afraid that dual-licensing would be one-way only: some code would be borrowed in other GPL projects and would not come back to Sun (or at least not to the Solaris kernel) because it could not be dual-licensed again. But if this is the only reason, then I think that it is short-sighted. Sun could certainly benefit from code that is GPL-only as long as it is outside the kernel. Also, some GPL code could even be contributed back to the Solaris kernel if the original authors agree to have it relicensed under the CDDL. Showing some goodwill with respect to the GPL might motivate some authors to dual-license their code. But by not being GPL-compatible, they are sending a message that will probably not encourage others to contribute to OpenSolaris. They may be able to build a small ecosystem around Solaris, but probably not as large as it could have been if they had been more GPL-friendly.
Actually, I doubt that the software could even be close to any Open Source definition. This would be incompatible with the following statement (from the ITworld.com article linked previously):
So they want to keep the system secret, and will not even mention how it works. Not really Open Source nor Free Software... It may not even be considered as freeware if it can only be distributed to a few law enforcement agencies.
The article from MSNBC mentioned in this story is very light on details. Thanks to Google News, here are some more useful articles about CETS, the Child Exploitation Tracking System:
These articles mention that CETS is based on MS SQL Server (for the database) and some bits of MS SharePoint (for the web portal). Also, the system uses .NET and web services (SOAP/XML) for exchanging data so it should be possible to integrate this with non-Microsoft systems (in theory).
What is not mentioned in any of the articles is whether the system is really open-source, as claimed in the headline of this Slashdot story and the related MSNBC article. The only statements that I found about this said that Microsoft Canada will "make [CETS] available free of charge to any law enforcement agency that wants to use it." But no mention of any Open Source license.
I agree that the problem is not a new one. However, think about the following scenario:
Result: most visitors will now get a fake site. The official site is gone from the Google rankings.
So although there is nothing new here, the fact that the fake site using a 302 redirection replaces the real site is a golden opportunity for all phishers...
I think that the solution suggested in the article (treating cross-domain 302 temporary redirections as normal links) could be a good workaround, even if this means that Google would not be following the HTTP standard defined by RFC 2616.
I just realized that I missed an important one:
Until a few years ago, companies that had trademarks in France were supposed to register their domains under .tm.fr. Apparently, Kraft did register www.milka.tm.fr.
But since the rules have changed (around 2002, I think) the company has been trying to get the domain that had been registered by that lady in the meantime.
Côte d'Or is owned by Kraft as well. You can see it by looking around on http://www.cotedor.be/ or directly on http://www.kraftfoods.be/. Fortunately, they haven't changed the products in any significant way so they still taste good.
I would also also recommend trying Galler chocolate (not owned by Kraft Foods - yet).
In order to fill a gap in Europe?
Note that they don't have most of the nordic countries nor the new members of the EU. Hint: many of these domains are open for registration!
Most of these sites redirect to the corresponding Kraft Foods site for that country, or to the globak www.kraft.com.
From my point of view, copyright is good if it is limited, both in time and in scope.
If I write a book, an essay, a piece of software, or if I create some nice pictures or music, then I don't want to have my work copied by others unless I allow them to do so (the GPL or the Creative Commons licenses are ways to allow that under some conditions).
I think that it is reasonable to allow authors to protect their original works for a limited amount of time. Most authors expect some kind of tangible or intangible benefits when they publish their works. Copying without permission may deprive them from these benefits, so it is good to have some copyright laws protecting the authors.
However, these laws should allow fair use and should include a reasonable time limit. By "fair use", I mean having the right to make personal copies (including conversion to other formats - for example converting music or video to Ogg Vorbis or Theora) or to distribute short excerpts of the works. Note that "fair use" does not include distributing copies to your neighbors or to anybody else via the Internet.
It does not have to be online. The GPL requires you to provide the source code to those who get the binaries from you (e.g., on the same CD or from the same web site) or to include a written offer to give the source code to any third part who requests it. This is stated in paragraph 3 of the GPL.
So the source code does not have to be available online, even if this is a convenient way for some companies to comply with the license. It can also be sent on CD-ROMs or floppy disks to those who request it. The online distribution happens to be cheaper in many cases, but this is not a requirement.
Wrong. In paragraph 3 b) of the GPL, you can see that it requires a "complete machine-readable copy of the corresponding source code [...] on a medium customarily used for software interchange". Furthermore, the same paragraph 3 adds: "The source code for a work means the preferred form of the work for making modifications to it.". So distributing the software in some obfuscated form would be a violation of the GPL.
Right. But if the updated client includes an updated protocol, then you will be forced to upgrade if you want to be able to talk to anybody who has upgraded. You could also be forced to upgrade if the registration mechanism is modified.
You are of course aware of the recommendation to use SIP over IPSec or TLS, right? So what are your security concerns, exactly?
In fact, I believe that the implementation of SIP in the mobile world (using the 3GPP standard IMS) makes it mandatory to use IPSec or TLS with SIP. SIP may not be perfect, but I think that the current best practices for its deployment are taking care of most of the issues.
I doubt that it will. They are using proprietary protocols and they made it clear that they do not intend to standardize. Not only that, but they also designed the Skype clients in such a way that they must check for updates and always run the latest version before being able to communicate with others. So they could change the protocols as soon as someone manages to reverse-engineer them.
Skype's technology is nice and works well. But if you value standards, open source and compatibility between multiple applications, then you should look at Skype with a more critical eye. You do not have to - it's your choice in the end.
sha1(md5($input)) is weaker than either sha1($input) or md5($input) alone. If one of them is broken, your digest is broken.
But append(sha1($input),md5($input)) is stronger than one of them alone. You would have to break both of them in order to fake a signed message.
Any web admin who has a clue knows that many visitors will not have a valid referer (usually because of a proxy, including some large corporate proxies). So blocking the requests that have no referer would have the unfortunate effect of blocking many legit visitors.
On the other hand, blocking all requests that do have a referer but for which the referer does not match the site itself or one of its affiliates is likely to work.
There are already a number of web sites doing that: they block you or redirect you to their home page if your requested a deep link and your request contains a referer and the referer does not match several variations of the site itself (including IP addresses) or one of its affiliates. This is even relatively easy to set up with Apache using mod_rewrite and some environment variables.
Right. This is one of the things that the article was complaining about. Unfortunately, there is no easy way to prevent that kind of scams: Verisign could check for obvious stuff such as "CLICK YES..." but it would be had for them or for anyone else to check for names that are similar to the names of companies or individuals all over the world.
If you accept all certificates blindly, then yes. If you pay a bit more attention, then no. You should only trust the certificates for the level of security that they provide, not more.
Once you have determined that a certificate is good, you can choose to let your software remember that decision so that you do not have to check it again the next time you see it.
I agree and I wish that more people had such a balanced point of view, both for software patents and copyright.
The problem (and the cause that is worth fighting for) is not that patents are universally bad or were a bad idea to start with. But in practice, software patents are doing more harm than good and have the potential to do even more harm (especially to open source software).
Regardless of what was the original intent or claimed intent of software patents, the result today is a big mess that harms most SMEs and individuals while it only provides limited benefits to a few big players and a few parasites (parasites are companies that live only on patents and have no real products). And even for the big players, the race for software patents looks more like the arms race during the cold war. In any case, this does not provide long-term benefits for the population or even for businesses, despite what the lobbyists paid by the big players or parasites would like the lawmakers to believe.
I also agree that copyright is useful and should be respected. I disagree with those who reject all kinds of "intellectual property" and use this as an excuse to make illegal copies of movies, music or software. Using the terms "intellectual property" is dangerous because this expression mixes several concepts, bad (software patents) or good (copyrights, trademarks).
I would like to add a minor correction: limited copyright has proven to be a valuable tool [...]. Limited copyright, both in scope (fair use) and in time (a few years, a few dozens at most) is indeed useful. Unlimited copyright does not encourage creativity and does not help society.
Well, this is basically rehashing some well-known arguments that are often brought up in a GPL vs. BSD debate or Free Software vs. Open Source software.
In a nutshell, the GPL gives you some freedoms but only if you accept its rather strict conditions. GPL advocates claim that it is a good thing, while GPL opponents claim that it is a bad thing. The basic idea that differentiates the GPL from other licenses is that a piece of code licensed under the GPL should not be used to give an advantage to non-free software. This is why the GPLed code cannot be linked together with code that is not GPL-compatible. This is also why RMS encourages developers to release their library code under the GPL instead of LGPL, although many developers who are more "open" still release code under the LGPL (e.g., GLib and GTK+, etc.)
The analogy with Oracle having to release their whole code under the GPL is also frequently (ab)used. Nobody is forcing Oracle (or anybody else) to incorporate some pieces of GPLed code into their software. They can easily rewrite something similar on their own, if they need it. If the author of the interesting function wants to promote Free Software and does not want to give an advantage to proprietary software, then his/her wishes should be respected. This is what the GPL does.
If you take the point of view of Oracle and you want to add some functions to your proprietary code, then GPLed software is not better than other proprietary software because you cannot just take it and use it without conditions. But if you take the GPL zealot's point of view, then it makes sense that the GPLed gift comes with some strings attached.
It is just a matter of choice. The arguments from Eric Schrock could interesting if the only option for Sun had been to release the code under the GPL or the CDDL but not both. But there is also the option to dual-license and allow those who get the code to continue their development under the GPL, CDDL, or both. Then anybody, including Oracle as in his example, would have been able to pick the best combination for them. But since Sun did not give any dual-licensing permissions for their code, they are effectively preventing a larger number of free software developers from using their code. It makes sense for them, but some of the arguments brought up in the press release and other public statements are rather misleading.
Fair enough. However, saying that the incompatibility is not the fault of the CDDL would be a bit generous...
The CDDL is derived from the MPL 1.1 from which the explicit dual-licensing statements have been removed. These statements (section 13 of the MPL) are used by Mozilla to allow their code to be licensed under the MPL or GPL, therefore making it GPL-compatible. There is no such provision in the CDDL.
It looks very much like the CDDL is incompatible with the GPL because its authors were not interested in making it compatible. They were fully aware of the consequences of their changes in the wording of the license and the FAQ acknowledges this indirectly.
I should add that even though section 13 has been removed, that does not prevent the author of a piece of software to release his/her code under the CDDL and GPL simulateneously. Authors can release their own work under as many licenses as they want. Dual-licensing is still possible, but not mentioned explicitely in the license. This has the disadvantage that any derivative works are likely to "forget" one of the licenses, unless all contributions are explicitely dual-licensed.
I will grant Sun the benefit of the doubt and assume that their lawyers did not think that section 13 was necessary and that it could cause more problems than it solves. Only paranoid people would think that it was removed in order to make it less likely that some work would be dual-licensed with the CDDL and GPL.
Anyway, this is not very important for the current discussion because:
Correct.
Wrong, unfortunately.
As I wrote in another comment, Sun has removed Section 13 and Exhibit A from the MPL 1.1. These were the parts that allowed the license to be GPL-compatible. So the CDDL is not GPL-compatible. In addition, that cannot be fixed easily because the CDDL 1.0 does not allow the work to be re-licensed under a future version of the same license. So even if the CDDL 1.1 would allow the author of the software to decide that it could be GPL-compatible, that would not apply automatically to anything that has been released under the CDDL 1.0.
There is one thing that I forgot to mention in my previous comment: the CDDL is derived from the Mozilla Public Licence (MPL) 1.1 but at the end of the Detailed description of changes from the MPL, you find this:
Section 13 of the MPL, titled "Multiple Licensed Code", allows the code to be licensed under the MPL or an alternative license described in Exhibit A (also deleted from the CDDL). For Mozilla, section 13 allows any derived code to be licensed under the MPL or GPL. Sun has removed this section from the CDDL. You can see it at the end of the Redline diffs between MPL1.1 and CDDL (PDF file).
So any code released under the CDDL is definitely incompatible with the GPL. There is also no way to fix that (except if Sun re-released the code under a better license) because Sun has also removed the statements that allowed the code to be used under a "future version of this License" from section 3.1 and section 6 (now 4 in the CDDL).
Have a look at the CDDL. In section 3.1, it says:
In addition, section 3.4 adds:
In other words, this license is incompatible with the GPL (probably on purpose). As a result, you cannot use any CDDL-licensed code in a GPL-licensed program and you cannot use any GPLed code in a CDDLed program. Both licenses are "viral" and they are mutually incompatible.
So you cannot use any CDDLed code in Linux.
Let's keep in mind that the original version of the GIMP was written in 1995 by two students before dozens of other developers started contributing to it. The first public version, 0.54, was released in 1996 and had features that were more or less comparable to those available now in Paint.NET. The support for layers was lacking, but it had decent plug-ins, undo and channel operations. It has come a long way since then...
Given enough time and/or contributors, I am sure that Paint.NET could become a very good program. But of course, I hope that the GIMP will always be better...
If you are interested, here is a link to a brief history of the early versions of the GIMP.
Did you try a recent version of the GIMP (2.2.0) or did you try an older one such as 2.0.x or 1.2.x?
Also, if you have a look at some of the other comments posted here, you will see that several people describe Paint.NET as being very slow. So if the GIMP is slow on your system, there is a risk that Paint.NET could be even slower for some operations (such as painting with a large brush).
A few days ago, I measured the time taken by various operations occuring while the GIMP starts and I posted a summary of the results to the gimp-developer mailing list. Loading and displaying the splash screen takes 7% of the total startup time. These tests were done over NFS, which makes file loading a bit slower, but the percentage of the time spent loading the splash screen is about the same when everything is loaded from a local hard disk.
I think that spending only 7% of the time for the splash screen is reasonable, considering that it also helps you to see what takes time (e.g., loading the scripts and the tool settings). Anyway, there is the --no-splash option allowing you to skip the splash screen if you do not like it.