Release of complete crypto source for Mozilla based on the PSM/NSS software and architecture depends not only on expiration of the RSA patent but also on replacing all the proprietary source code licensed from RSA Security and other third parties. That's the goal, but there's enough integration and other work involved that it's not going to happen overnight. But I do expect to see it happen; exactly how and when it happens remains to be seen.
It would be extremely cool to see some built-in PGP for the email/news client. Or at least hooks to use an external PGP/GPG.
Based on what people have posted to the netscape.public.mozilla.crypto newsgroup, I would not be surprised to see Mozilla plugins for both commercial PGP (from NAI) and for Gnu Privacy Guard. However it's premature to speculate on exactly when these might be available.
To clarify this a little more: the security library for Netscape Communicator (which will also be in the iPlanet PSM binaries that will work with Mozilla) incorporates proprietary code from RSA Security, and some of that code implements the RSA public key algorithm, on which RSA Security has a patent in the U.S.
Once the RSA patent expires then other people in the U.S. may write and release code implementing the RSA algorithm without requiring a patent license from RSA. However the code supplied by RSA Security will still be proprietary. What the expiration of the patent will allow is creation of an alternative RSA implementation which is open source and can be freely used with the Mozilla source base.
I believe the patent on the RSA algorithm expires this autumn.
September 20, 2000 (which actually is in the summer, but just barely). And yes, patents normally are for 17 years.
... when will the new export regulations take effect, so you don't have to be blessed by a major corporation to ship?
You don't need to be a major corporation to export crypto software. Under the new regulations released in January, anyone in the U.S. can export open source crypto software with minimal restrictions (basically a requirement to notify the US government of the URL of your download site).
If you use the gratis-but-closed-source PSM daemon, Mozilla will have SSL.
Just to be clear: The source code has already been released for most of the Personal Security Manager and Network Security Services software that will provide SSL support for Mozilla. The only important parts of the Netscape version of PSM that are closed-source are the encryption libraries licensed from RSA Security. Over time I expect those libraries will be replaced (by someone if not by Netscape) with open source encryption libraries, so that Mozilla will have a complete open source SSL implementation unencumbered by patent or other restrictions.
First, the new export regulations do not limit the encryption strength of open source encryption source code exported from the U.S. under the new section 740.13(e) of the regulations. As a U.S. developer you can host such source code on your web site, etc., no matter what key length it implements.
Second, the new encryption regulations also appear to allow export of full-strength ("128-bit") encryption binaries, although with somewhat more hassle and restrictions than with open source encryption source code. (Note that binaries built from open source get no special break in the regulations vs. binaries built from proprietary code.) The relevant sections in the regulations are 740.17(a)(2) and (a)(3), and 742.15(b)(2).
To clarify this: First, the code being released is being created by a separate group of developers from the main Mozilla developers at AOL/Netscape; it's from the security engineering team that creates the security/crypto infrastructure for the Sun/Netscape Alliance server products as well as for Netscape Communicator. Second, the security stuff is not tightly embedded in present Mozilla like it was in Mozilla Classic and Netscape Communicator 4.x; it's more like an add-on architecture through a defined set of general-purpose APIs in main Mozilla.
So it's not like the security/crypto work is taking lots of developers away from other Mozilla work.
Re:what "with" means, various comments
on
Under The Radar
·
· Score: 2
If, as Jamie suggests, the Netscape chapters are just a rewrite of Frank Hecker's writings, then a credit is almost required.
I don't have a copy of the book handy, but I believe that I was in fact credited for the substantial chunks of material than Wendy Goldman Rohm quoted from my paper. Unfortunately, if I remember correctly the way she quoted me gives a misleading impression to the reader, because the paper she's quoting is the public paper that I wrote after the Communicator source release, not the original paper I wrote for internal consumption at Netscape. Thus, for example, the book quotes me as discussing choices between various licenses, business models, etc., and (to my mind at least) gives the impression that this stuff went into Netscape's decision to release source. However that material was written after the Mozilla source release, based on both the Mozilla license discussions and some of the opensource.org material.
The complete and authoritative history of the Communicator source code release has not yet been written. In my opinion the best sources so far are the last chapter of Josh Quittner's book Speeding the Net, which covers the period up to the January 1998 source code announcement, and the chapter in Open Sources, which covers the period between the January announcement and the actual release of the code at the end of March.
Is it illegal for a US citizen to develop and freely distribute a Tcl/TK front-end to a non-US-developed command-line crypto package? I don't think so. If you know otherwise, please refer to the legal source.
I guess you're referring to the "crypto-specific API" case, where your application invokes encryption functions through some sort of "crypto-specific" interface, and thus may be considered export-controlled even though it contains no crypto code. The restrictions on this are really enforced on a case by case basis, as the regulations don't really cover every question about what is a crypto-specific interface and what is not. However for my best guesses on the matter see question 5 of the Mozilla Crypto FAQ. I include references to the relevant sections of the Export Administration Regulations, but unfortunately the links in the FAQ are no longer working; check the GPO's online version of the EAR.
Re:Is bug finding & reporting worth my while?
on
Mozilla M9 Released
·
· Score: 1
It seems that many testers would need some form of good feedback which would make them believe they weren't wasting their time. Like lists of feature that need testing and which have been tested and which have how many bug reports already filed on them, etc.
There's not a complete and all-inclusive list to use as a guide to testing, but you might want to check out the Bugathon page, which offers some good guidance on areas where Mozilla testing is needed.
I am not officially part of mozilla.org, and no one in mozilla.org or AOL/Netscape asked me to write this article, whether it be for "damage control" or any other purpose. However I did think it was a good idea to have an independent look on what was up with the Mozilla project, particular as I think Jamie's opinion is not necessarily representative of the true current state of the project. (As to whose opinion is really more in line with reality, don't ask Jamie or me; ask the Mozilla developers themselves, especially those not employed by AOL.)
In some areas I think Jamie is absolutely right (like it being a bad thing not to have a working release yet), in other areas I think he is in effect objecting to technical decisions that were made for what other people consider good and sufficient reasons (like dumping Mozilla Classic for NGLayout), and in other areas I think he had unrealistic expectations (like speed and size of developer contributions to Mozilla).
But in any case, if I really had wanted to try and put a "happy face" on the Mozilla project then I could have skipped writing a large chunk of the article.
kzinti writes: I thought Cathedral and the Bazaar was the paper that led te Netscape's release of the Mozilla source...is there another paper I don't know about?
The short answer is yes; as is often the case, reality is more complicated than the sound-bite. To be as brief as I can without distorting history: Over the years several people at Netscape floated the idea of releasing source code for Navigator/Communicator; some did so in postings to internal newsgroups (like Jamie Zawinski), and some did so in private lobbying to management (like Eric Hahn, formerly Netscape's CTO). Prompted by two such newsgroup postings by Jamie and Eric Krock (now Gecko product manager), in the fall of 1997 I wrote a 30-page internal paper lobbying for release of source by explaining the business value for doing so; I also addressed various objections to releasing source, either showing how they were not really problems or describing how any problems could be handled. I sent that paper to Marc Andreessen, who in turn circulated it to other senior managers at Netscape. This paper was IMO one, but by no means the only, factor in the decision by Netscape management in January 1998 to release source. (For example, it was also important that Netscape decided to make Communicator binaries totally free at the same time; this removed a major objection to freeing the source code.)
Eric Raymond and "The Cathedral and the Bazaar" came into the picture as follows: I was finishing up my paper, and was working on a section addressing the problem of coordinating development between Netscape and the net. (A major objection I thought would arise was how this could work successfully, or even if it would work at all.) I asked Jamie for advice, he gave me some, and then also pointed me to Eric's paper; I thought it addressed this particular problem quite nicely, and included a reference to "C&B" and a page or so summarizing its conclusions. Some of the senior managers (like Eric Hahn) liked "C&B" just as much as I did, in large part because of the implication that Netscape could potentially successfully leverage the work of lots of non-Netscape developers, even to the point of their driving the future direction of the product; Eric and others in turn promoted "C&B" within Netscape.
Once the decision to release source code was made, Netscape management then decided to bring in Eric and other people (Richard Stallman, Bruce Perens, etc.) for advice. However the decision itself was a purely internal decision, in the sense that neither Eric or anyone else outside Netscape (to my knowledge) actually lobbied Netscape management on the source code issue; "outside" input was restricted to that provided by papers like "C&B", the GNU Manifesto, etc., and examples of free software businesses like Cygnus Solutions, Red Hat, and so on. (The Slashdot discussions about Netscape releasing source came in right before the Netscape decision was announced, but I don't know if they were actually a factor or not, because I don't know if the internal decision had actually been made by then.)
Incidentally, my original paper is not on the net, but I did a public paper "Setting Up Shop: The Business of Open Source Software" which incorporates huge chunks of my internal paper. In particular, the sections "Making the Business Case" and "Issues and Tactics" are close to what I wrote originally. However the licensing and business models sections of "Setting Up Shop" are new.
Aaron Renn comments about me: He's not ideologically committed to free software...
To be more specific about this, I am not ideologically committed to free software in the sense that Stallman and others are. However I do acknowledge that that point of view is worthy of respect and understanding; if "open source" is going to be successful I don't believe for a minute that you can just ignore the political and moral issues behind the reasons that many people develop free software, marginalizing those beliefs (and by implication, those who hold them) as "naive" or "no longer needed".
After all, political fervor is one major reason why free software/open source is where it is today in terms of a broad-based movement (as opposed to just a media phenomenon). And if a commercial company wishes to do collaborative development with the rest of the world, I can't see any point in pissing off and disrespecting a significant portion of your potential base of helpers, i.e., those who believe in the vision behind the GPL and free software in general.
Yes, you are absolutely correct that I did not highlight this properly. I am well aware of this being a problem, and it is implicit in a lot of what I wrote, but in the process of writing I stupidly forgot to address it directly.
For what it's worth, I think we'll get much closer to having "something working" as we proceed through the set of milestone releases coming up over the next few months.
It might be a good idea to review things as they stand today, as well as a little bit of history. Some points to remember:
First, the Mozilla effort goes on: AOL is still funding development, non-AOL developers are active as well, the project is continuing to release "milestone" releases which you can try out, and this will culminate later this year in beta releases of Communicator 5.0 and then a final release, all based on the open Mozilla source code. This has been the case all along, and remains the case.
Next, in the Mozilla project there was a fundamental trade-off: build and release a product based on the existing in-progress 5.0 code base ("Mozilla Classic") or rearchitect the product to make it more standards compliant (i.e., use the new layout code being developed), more extensible, more open (e.g., use something other than Motif), and so on. In particular, many people complained vociferously that Mozilla/5.0 needed to have 100% standards compliance for HTML 4.0, CSS1, etc. Thus the decision was made (way back in October 1998) to rearchitect the product, use the new layout engine, use GTK+ instead of Motif, etc.
Most people on/. and elsewhere seemed to agree with that decision at the time, and would presumably still agree with it. However from Jamie's point of view it presumably would have been a better plan to go ahead and ship as early as possible even given the downsides. (Also, Jamie saw no reason to ditch Motif for GTK.) That's something about which reasonable people can disagree, but I don't buy the assertion that by taking the extra time to make a better product the Mozilla project has therefore "failed".
"[OSS's] mission is to commodotize those services which can best benefit from commodization." That's actually a very good way of putting it.
I would only add that many if not all business products and services combine a commodity component and a vendor-specific added-value component. OSS can potentially fill the niche of providing those commodity components for a wide range of business products and services, with smart businesses still able to figure out ways to provide added value in a manner that is both profitable and consistent with the nature of OSS.
Despite being quoted in the article, I don't agree with all its conclusions and actually agree with your contention that Nikki Goth Itoi left some stuff out that she should have mentioned. But it would have been nice if you had given some concrete examples.
I'll give one of mine: I think she neglected the potential possibility of companies that offer services based on open-source software, where those services are not just technical support and integration related to the software itself. A hypothetical example would be a online game company that made the client game software open-source and built a business around the community itself, e.g., based on subscriptions, advertising, whatever.
If you read this less superficially, it's clear that Luddite Industries is an elaborate gag. (See for example the comments about the "Wooden Auto Company".) A quick check of whois reveals that the domain name is owned by Prophet Communications, a subsidiary of the industrial design firm frog design.
Slashdot Mirror
Release of complete crypto source for Mozilla based on the PSM/NSS software and architecture depends not only on expiration of the RSA patent but also on replacing all the proprietary source code licensed from RSA Security and other third parties. That's the goal, but there's enough integration and other work involved that it's not going to happen overnight. But I do expect to see it happen; exactly how and when it happens remains to be seen.
Based on what people have posted to the netscape.public.mozilla.crypto newsgroup, I would not be surprised to see Mozilla plugins for both commercial PGP (from NAI) and for Gnu Privacy Guard. However it's premature to speculate on exactly when these might be available.
To clarify this a little more: the security library for Netscape Communicator (which will also be in the iPlanet PSM binaries that will work with Mozilla) incorporates proprietary code from RSA Security, and some of that code implements the RSA public key algorithm, on which RSA Security has a patent in the U.S.
Once the RSA patent expires then other people in the U.S. may write and release code implementing the RSA algorithm without requiring a patent license from RSA. However the code supplied by RSA Security will still be proprietary. What the expiration of the patent will allow is creation of an alternative RSA implementation which is open source and can be freely used with the Mozilla source base.
I believe the patent on the RSA algorithm expires this autumn.
September 20, 2000 (which actually is in the summer, but just barely). And yes, patents normally are for 17 years.
You don't need to be a major corporation to export crypto software. Under the new regulations released in January, anyone in the U.S. can export open source crypto software with minimal restrictions (basically a requirement to notify the US government of the URL of your download site).
If you use the gratis-but-closed-source PSM daemon, Mozilla will have SSL.
Just to be clear: The source code has already been released for most of the Personal Security Manager and Network Security Services software that will provide SSL support for Mozilla. The only important parts of the Netscape version of PSM that are closed-source are the encryption libraries licensed from RSA Security. Over time I expect those libraries will be replaced (by someone if not by Netscape) with open source encryption libraries, so that Mozilla will have a complete open source SSL implementation unencumbered by patent or other restrictions.
Second, the new encryption regulations also appear to allow export of full-strength ("128-bit") encryption binaries, although with somewhat more hassle and restrictions than with open source encryption source code. (Note that binaries built from open source get no special break in the regulations vs. binaries built from proprietary code.) The relevant sections in the regulations are 740.17(a)(2) and (a)(3), and 742.15(b)(2).
So it's not like the security/crypto work is taking lots of developers away from other Mozilla work.
If, as Jamie suggests, the Netscape chapters are just a rewrite of Frank Hecker's writings, then a credit is almost required.
I don't have a copy of the book handy, but I believe that I was in fact credited for the substantial chunks of material than Wendy Goldman Rohm quoted from my paper. Unfortunately, if I remember correctly the way she quoted me gives a misleading impression to the reader, because the paper she's quoting is the public paper that I wrote after the Communicator source release, not the original paper I wrote for internal consumption at Netscape. Thus, for example, the book quotes me as discussing choices between various licenses, business models, etc., and (to my mind at least) gives the impression that this stuff went into Netscape's decision to release source. However that material was written after the Mozilla source release, based on both the Mozilla license discussions and some of the opensource.org material.
The complete and authoritative history of the Communicator source code release has not yet been written. In my opinion the best sources so far are the last chapter of Josh Quittner's book Speeding the Net, which covers the period up to the January 1998 source code announcement, and the chapter in Open Sources, which covers the period between the January announcement and the actual release of the code at the end of March.
I guess you're referring to the "crypto-specific API" case, where your application invokes encryption functions through some sort of "crypto-specific" interface, and thus may be considered export-controlled even though it contains no crypto code. The restrictions on this are really enforced on a case by case basis, as the regulations don't really cover every question about what is a crypto-specific interface and what is not. However for my best guesses on the matter see question 5 of the Mozilla Crypto FAQ. I include references to the relevant sections of the Export Administration Regulations, but unfortunately the links in the FAQ are no longer working; check the GPO's online version of the EAR.
It seems that many testers would need some form of good feedback which would make them believe they weren't wasting their time. Like lists of feature that need testing and which have been tested and which have how many bug reports already filed on them, etc.
There's not a complete and all-inclusive list to use as a guide to testing, but you might want to check out the Bugathon page, which offers some good guidance on areas where Mozilla testing is needed.
In some areas I think Jamie is absolutely right (like it being a bad thing not to have a working release yet), in other areas I think he is in effect objecting to technical decisions that were made for what other people consider good and sufficient reasons (like dumping Mozilla Classic for NGLayout), and in other areas I think he had unrealistic expectations (like speed and size of developer contributions to Mozilla).
But in any case, if I really had wanted to try and put a "happy face" on the Mozilla project then I could have skipped writing a large chunk of the article.
The short answer is yes; as is often the case, reality is more complicated than the sound-bite. To be as brief as I can without distorting history: Over the years several people at Netscape floated the idea of releasing source code for Navigator/Communicator; some did so in postings to internal newsgroups (like Jamie Zawinski), and some did so in private lobbying to management (like Eric Hahn, formerly Netscape's CTO). Prompted by two such newsgroup postings by Jamie and Eric Krock (now Gecko product manager), in the fall of 1997 I wrote a 30-page internal paper lobbying for release of source by explaining the business value for doing so; I also addressed various objections to releasing source, either showing how they were not really problems or describing how any problems could be handled. I sent that paper to Marc Andreessen, who in turn circulated it to other senior managers at Netscape. This paper was IMO one, but by no means the only, factor in the decision by Netscape management in January 1998 to release source. (For example, it was also important that Netscape decided to make Communicator binaries totally free at the same time; this removed a major objection to freeing the source code.)
Eric Raymond and "The Cathedral and the Bazaar" came into the picture as follows: I was finishing up my paper, and was working on a section addressing the problem of coordinating development between Netscape and the net. (A major objection I thought would arise was how this could work successfully, or even if it would work at all.) I asked Jamie for advice, he gave me some, and then also pointed me to Eric's paper; I thought it addressed this particular problem quite nicely, and included a reference to "C&B" and a page or so summarizing its conclusions. Some of the senior managers (like Eric Hahn) liked "C&B" just as much as I did, in large part because of the implication that Netscape could potentially successfully leverage the work of lots of non-Netscape developers, even to the point of their driving the future direction of the product; Eric and others in turn promoted "C&B" within Netscape.
Once the decision to release source code was made, Netscape management then decided to bring in Eric and other people (Richard Stallman, Bruce Perens, etc.) for advice. However the decision itself was a purely internal decision, in the sense that neither Eric or anyone else outside Netscape (to my knowledge) actually lobbied Netscape management on the source code issue; "outside" input was restricted to that provided by papers like "C&B", the GNU Manifesto, etc., and examples of free software businesses like Cygnus Solutions, Red Hat, and so on. (The Slashdot discussions about Netscape releasing source came in right before the Netscape decision was announced, but I don't know if they were actually a factor or not, because I don't know if the internal decision had actually been made by then.)
Incidentally, my original paper is not on the net, but I did a public paper "Setting Up Shop: The Business of Open Source Software" which incorporates huge chunks of my internal paper. In particular, the sections "Making the Business Case" and "Issues and Tactics" are close to what I wrote originally. However the licensing and business models sections of "Setting Up Shop" are new.
To be more specific about this, I am not ideologically committed to free software in the sense that Stallman and others are. However I do acknowledge that that point of view is worthy of respect and understanding; if "open source" is going to be successful I don't believe for a minute that you can just ignore the political and moral issues behind the reasons that many people develop free software, marginalizing those beliefs (and by implication, those who hold them) as "naive" or "no longer needed".
After all, political fervor is one major reason why free software/open source is where it is today in terms of a broad-based movement (as opposed to just a media phenomenon). And if a commercial company wishes to do collaborative development with the rest of the world, I can't see any point in pissing off and disrespecting a significant portion of your potential base of helpers, i.e., those who believe in the vision behind the GPL and free software in general.
For what it's worth, I think we'll get much closer to having "something working" as we proceed through the set of milestone releases coming up over the next few months.
First, the Mozilla effort goes on: AOL is still funding development, non-AOL developers are active as well, the project is continuing to release "milestone" releases which you can try out, and this will culminate later this year in beta releases of Communicator 5.0 and then a final release, all based on the open Mozilla source code. This has been the case all along, and remains the case.
Next, in the Mozilla project there was a fundamental trade-off: build and release a product based on the existing in-progress 5.0 code base ("Mozilla Classic") or rearchitect the product to make it more standards compliant (i.e., use the new layout code being developed), more extensible, more open (e.g., use something other than Motif), and so on. In particular, many people complained vociferously that Mozilla/5.0 needed to have 100% standards compliance for HTML 4.0, CSS1, etc. Thus the decision was made (way back in October 1998) to rearchitect the product, use the new layout engine, use GTK+ instead of Motif, etc.
Most people on /. and elsewhere seemed to agree with that decision at the time, and would presumably still agree with it. However from Jamie's point of view it presumably would have been a better plan to go ahead and ship as early as possible even given the downsides. (Also, Jamie saw no reason to ditch Motif for GTK.) That's something about which reasonable people can disagree, but I don't buy the assertion that by taking the extra time to make a better product the Mozilla project has therefore "failed".
I would only add that many if not all business products and services combine a commodity component and a vendor-specific added-value component. OSS can potentially fill the niche of providing those commodity components for a wide range of business products and services, with smart businesses still able to figure out ways to provide added value in a manner that is both profitable and consistent with the nature of OSS.
I'll give one of mine: I think she neglected the potential possibility of companies that offer services based on open-source software, where those services are not just technical support and integration related to the software itself. A hypothetical example would be a online game company that made the client game software open-source and built a business around the community itself, e.g., based on subscriptions, advertising, whatever.
If you read this less superficially, it's clear that Luddite Industries is an elaborate gag. (See for example the comments about the "Wooden Auto Company".) A quick check of whois reveals that the domain name is owned by Prophet Communications, a subsidiary of the industrial design firm frog design.