"Eudora was specifically designed with the idea that standards are a key to successful adoption.
Indeed, the rapid acceptance of the Internet is largely due to the standardization process.
Published standards are what allow applications from multiple sources to cooperate with each
other. Without standards organizations would only be able to use their own applications
together, and not those from outside. Also, by allowing diversity of implementations you
achieve a much more robust software ecosystem."
- From the "Windows Eudora Architecture.pdf" in the distribution
This is beautiful. One of the "so obvious it's invisible" truths of the modern age, and I nearly forgot that Eudora and other pioneers of the age were making a somewhat risky choice to only support standard protocols and eschew the proprietary mailers. Most of them are now long dead yet POP3, IMAP, SNMP chug along. At the time, though, it wasn't so clear.
POP3 is only efficient if you download all mail to the client and immediately remove it from the server. But nobody does that, everyone leaves their mail on the server. Then everytime you synchronize the server has to go through all the mail it has to see what you don’t have, which is very inefficient if you have 10000 mails in your inbox, like most people have these days.
It’s optimized for a usecase that doesn’t exist anymore and it will work in the usecase that does exist while wasting a lot of resources. Truly the worst you can have. It’d be better if it didn’t work at all.
I don't think it is at all fair to call POP3 inefficient on this basis. It is fine if you use it in the way it is intended (and presumably optimised) for. It was designed as a delivery mechanism back when people didn't tend to have permanent connections and space on servers wasn't cheap. Users wanted mail locally for disconnected use and servers wanted rid of it once delivered onward.
Where it is not the right tool for the job, use the tool that is instead (IMAP presumably in this case).
It seems that something that doesn't meet your needs (but did match many people's requirements in the past and may still meet some people's needs now) exists is causing you some offence.
Have you been "burned" by problems with POP3 in some specific way that has made you feel this bitter towards it rather then using the right tool for a job it presumably isn't right for and moving on? Or are you being forced to use it in some circumstance?
> something nobody wants
You are not everybody. Just because you can't imagine a valid use case these days does not mean that one does not exist. While IMAP-with-local-caching can replace most use cases for POP3, does it replace all of them in an optimal manner?
> But nobody does that, everyone leaves their mail on the server.
Absolutely not. I have a personal e-mail address which is IMAP and a shared mailbox with my wife which is POP (I don't want my mail read if she reads it). Mail clients are configured to leave mail on the server for 1 month. It's not complicated.
I for one use pop3 and am really content with it. I cannot bear the idea of keeping my personal mails on a remote server. And that of having to use a web interface to configure splitting rules via a web interface, unable to easily version control and undestructibly and easily test.
You seem to have a personal (!) problem with POP3. Why is that? Are you forbidden to use IMAP because of it? Are you forced to implement a POP3 server?
Clearly you’ve never had to do tech support for people that inadvertently chose POP3 because in many systems it’s still the default selection, along with the default behavior of deleting mails from the server as you fetch them.
What do you mean the only copy of all my mail is in some bizarro mail client specific proprietary database? Why can’t I also read my mail on my phone? I dropped my laptop in the toilet and now my mail is gone. Isn’t it on the server? Why can’t I use folders? Don’t you have backups?
No, your mail is gone, because you used a protocol designed for the 90s. It’s a great idea if you have a mail account with 10mb quota and you download your mail to a fixed, reliable workstation and you don’t mind if you lose it all if the disk crashes, it doesn’t happen that often. Not hardly as often as laptops getting stolen, Windows breaking itself and phones going bust.
I’m not sure why I need to have personal problems with your pet protocol to have an opinion on it, especially on one that stinks as much as POP3. It’s obsolete.
> I’m not sure why I need to have personal problems with your pet protocol to have an opinion on it, especially on one that stinks as much as POP3. It’s obsolete.
Because you're trying to fight people that use it.
In another comment I write how I use it. Clearly you can lose mail with IMAP too. There is a reason we do backups. Also, people not knowing how to use it or you not liking to deal with these does not make a protocol obsolete.
I have an iMac, a MacBook Pro, an iPad, and an iPhone, and I want to be able to access my email from any of them. POP3 is simply not designed to handle that situation gracefully. If a POP3 client is set to download email and delete it from the server, then the messages get "stuck" on whatever client happened to download it first; if it's set to keep copies of the emails on the server, then it pretty much becomes IMAP. Except stupider, since POP3 doesn't treat "downloaded" and "read" as separate concepts.
While I suspect I'm relatively uncommon in having four devices that I want to be in sync, wanting two or three devices -- computer, phone, and possibly work computer -- to be in sync probably isn't very uncommon at all.
I use POP3 for fetching mail from my remote mail server, and I don't want to keep mail on it (my current pipeline is: mpop > procmail (clamav, spamassassin) > gnus (nnsplit & nnml)). This does not bar me from using IMAP locally to sync mail among my devices (which is a problem I haven't handled yet, mostly because has not really been necessary for me up until now). But because I don't use folders and spam checkers on the remote, and never keep mail there, using IMAP to communicate with it is unnecessary.
It's fine if it's used to simply pull down mail to a local spool. The inefficiency complaints usually stem from attempting to maintain mail on a remote server across multiple clients. POP3 does not implement a sufficiently rich protocol to make this possible without downloading the entire spool onto each client.
No, it's highly inefficient in the face of latency, because there essentially is no batch fetching primitive. Fetching messages over a high latency connection (e.g. to a server on the other side of Earth) takes forever if you have a lot of messages.
Not sure how message expiry is a standards compliance issue. SMTP, MIME and RFC822 et. al. don't say anything about where, how or if the message gets stored once transmitted.
> Not sure how message expiry is a standards compliance issue.
using market-influence to build massive scale expectation for a feature which can't actually be supported by the underlying protocol in an effort to 'embrace and extend' is exactly a standards compliance issue, and precisely what led to microsoft's internet explorer being labeled as an antitrust violation.
> Well, I think this works differently. The email just includes a link to a Google webpage with the email. It’s still just an email sitting in your inbox. It doesn’t remove itself automatically.
The email standard was built so that you can check your email with a client, and view the contents offline at your convenience, archive, back up, etc.
Google's email proposal kills this functionality.
When was the last time I used this, you may ask? On Saturday. I was in one of the slot canyons in Utah with zero signal, and, while taking a break, I wrote several emails in my Opera email client, in response to some messages I've procrastinated writing a response to.
The trickery is that the sender might think they're sending a message over email to the recipient, whereas they are sending the message to Google's servers over an internal protocol, and are sending a link to the message to the recipient over email.
How do you distinguish between this and, say, e-cards? Blue Mountain has been sending e-mail links to ephemeral content since at least the early 2000s.
I'm not missing anything. There's nothing wrong with placing links in emails. The link is good, presumably in and out of gmail, and is clearly a gmail feature, not an email feature. There's no problem here.
> The link is good, presumably in and out of gmail
The link is clearly not good out of Google ecosystem. You need to have a Google account to view it. Otherwise, there's nothing stopping the e-mail client (or even recipient's email server) from fetching the link upon receipt.
To be clear: Gmail want to be a UI for sending messages via a proprietary protocol which look like emails to the sender and receiver if they are Gmail users.
If your outgoing emails were silently converted into Snapchat messages (more features! why not! everyone's one Snapchat anyway!), would you be similarly unconcerned?
>and is clearly a gmail feature, not an email feature. There's no problem here.
That's precisely the problem: turning Email into Gmail.
Remember how IE added features to HTML which were IE features, not HTML features? Remember how it wasn't at all a problem?
But the email is readable, it has a link to a message online. It is not a change to the standard, since it's in the body, where you can write whatever you like. In fact, it's not even unprecedented, because Cisco has been offering this exact same type of system for years generally for PHI and other sensitive uses.
My bank send me a "Secure Cisco Message". That I think was In response to a web message support request. They didn't tell me in what form to accept the response.
It was a message with instructions to save the .html attachment to your hard drive and open it there. It included tons of obfuscated Javascript.
Without opening the message I replied back and told them "Nope. We're not going to communicate this way, this is irresponsible and dangerous."
Yep, they couldn't have made that message look more like phishing if they tried - including poor HTML formatting of the email body. This is how you really know that GPG has failed.
If it were just a URL, even an HTML-enabled client would show just the link. I assumed that it must be embedded content, which would be rendered as a normal-looking message.
Maybe it's both. But even so, I'd just see the link. And generally, I ignore blank messages containing links.
Also, it's not uncommon for email list software to strip HTML, and I doubt that it would decode the HTML before doing so.
In 1999-2001 when I was doing dialup tech support, running into a customer with Eudora was a dream compared to the nightmare of basically any other contemporary mail client around: Outlook and Outlook Express. EarthLink even made their own abomination of a mail client called Total Access, IIRC it could import and export Eudora dbs.
Or, if you lived in Eastern Europe, The Bat1[1] - and it is still actively supported!
I switched to Opera Mail because it was convenient to have the browser and email client in one software (which is also freeware), but that went with the Chropera move.
The Bat was quite nice! I used it for a while but finally switched to the Japanese client "Becky Mail", ugly but quite functional. I still have some backups in a zip drive I should restore...
Damn. The "bad" words have been sanitized. Seeing the programmers' frustrations as they appear in the comments enhances the experience when viewing old code like this.
It's funny how in most corporate/commercial code past 2005 or 2010, you'll rarely ever see profanity in comments. I've never put profanity, or even any jokes, in comments. I really try to keep my professional code professional.
Even on my own OSS projects I tend not to do that anymore.
Unfortunate that we (as a collective --- not something I personally believe in) seem to think that that is being "professional", and that it is somehow a reason to make everything as bland and soulless as possible, and that that is somehow better? I agree that a lot of code has lost its "character", so to speak.
It's an unfortunate loss for our conceptual heritage for the word 'professional' to have been mostly hijacked to mean something more like 'obedient', 'conformist', 'dull', 'bland', 'besuited' etc.
Once you don't have a word to express a concept, that concept can quite quickly fall out of circulation. Professionalism was a useful part of modern culture: it would be a shame for it to disappear from the lexicon. A horse that's bolted, I fear.
I don't cuss in my professional code because I work with a lot of programmers in another country, and I think it would just cause confusion. "What means 'shitpig' in the constructor?"
I wonder if that's due to the trend of not writing that many comments in your code to start with? Maybe all that has migrated to the version control commit logs?
Speaking of bad words, Eudora also used to have a rating system for emails you are about to send. Too many bad words? 3 red peppers. And it would ask you "Are you sure you want to send that?"
Fun idea. We liked to try to make it look like the produce section at Fiesta.
Late versions of Eudora added something they called ‘mood watch’, which could highlight potentially inflammatory words or phrases (including profanity) in email and warn you before sending. The developers added a hidden setting which would, when you opened a message, speak aloud precisely those words.
Oh, cool. I can finally fix the bug/feature that whenever someone replied to an email from me they got warned about profanity because of my last name :-)
Hehe, to be completely fair with you the first time I came across your name I thought you were pulling a very long prank. But you don't get to choose your name.
An architect in the Netherlands had 'Rothuizen' as his last name, which translates to 'Rotten houses', not the best name for an architect so he changed it to 'Rotshuizen', which translates as 'Houses built like rocks'. Much better :)
Do you suppose the original etymology of "Rothuizen" could have been an older Germanic name that might have been rendered as "Rodehuizen" in modern Dutch? (I'm thinking of modern German "rot" corresponding to modern Dutch "rood".)
Wiktionary seems to believe in a Middle Dutch "*rōt (in placenames)" referring to the color red.
That story is so embellished. There's no way a university-aged guy is "so humiliated" by the censored word that he "couldn't even eat it after that". Get real.
May I have an off topic question? I know I read in an article that Cloudbleed woke you up like 1:23AM but I can't find that article any more and I used that to tell my junior developers to write code they can understand when they are woken at 1:23AM as you were. So the question is -- is this true or did I dream up something?
I would love to read about this somewhere. I also share the grand-posters opinion that sharing these kinds of stories with less experienced developers is fantastic culture.
"The transfer agreement allows CHM to publish the code under the very liberal BSD open source license, which means that anyone can use it for either personal or commercial purposes."
I'm guessing they had to go through the code pretty carefully to make sure they could. I'm seeing embedded PNG, zlib, qt3 and other libraries buried down in there.
It's also interesting they have completely separate windows and mac code bases.
> it's also interesting they have completely separate windows and mac code bases.
At the time I don’t really think that was uncommon.
I mean, you barely had FOSS portable libraries to base the core functionality on, even before you started tackling platform specific issues.
There were different CPU architectures. Machines back then were completely different, with each type having it’s separate types of HW devices and connectors. Etc etc.
Literally nothing were common between PCs and Macs. I’m not surprised at all.
While I was in college, during the summer of 2001, I did an internship at Qualcomm. I was surprised to discover that they used Eudora as their internal Email client, despite not having seen it still in use elsewhere for many years.
Of course I found its UI frustrating enough (for reasons I barely remember now) that I wound up installing something else to use on my workstation.
I applaud Qualcomm for donating all trademarks and copyrights too, which means literally anyone can recompile it and still call it "Eudora".
Unfortunately Eudora is basically three completely different codebases (Windows, Mac, and a rebranded Thunderbird for Linux). I guess only the Windows one is likely to ever be revived.
It's a bit weird, just above they say "they decided not to simply grant a license, but to transfer ownership of the code, the Eudora trademarks, the copyrights, and the Eudora domain names to the Computer History Museum".
So it's the CHM who is barring people from using the name. The relevant clause must be this: "Neither the name of Computer History Museum nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission." Is this really "BSD license", if the name is off-limits? This looks like an extra clause to me. Honest question.
EDIT: also, that clause mentions the names of contributors, not of the actual software. So they would have to argue that Eudora is barred by "contributor Eudora Inc." -- does that company even exist anymore?
Trademark ≠ copyright. My reading is: (1) CHM now owns the code, and CHM is licensing it under a BSD license. (2) CHM now owns the trademarks, and is not licensing them.
You can protect the name and code differently. Firefox holds certain trademarks and only binaries they compile can be distributed with their branding.
You can have Firefox branding if you compile it yourself, but you can't distribute the binaries (Gentoo has a notice about this in the build process). This is why Debian created the IceWeasel package.
The museum might want to preserve the name associated with that piece of history, so Eudora always points to that final release. If the license for the code is BSD, people can of course publish their own ports with new names.
> Is this really "BSD license", if the name is off-limits? This looks like an extra clause to me.
There's actually a few licenses that are called the BSD license. In modern terms, BSD refers to the 3-clause BSD.
However, the 3-clause BSD was not the original form. It was introduced because the 4th clause was generally viewed as problematic. That 4th clause is:
> 4. Neither the name of the <organization> nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
This "weird" clause is actually the 4th clause of the 4-clause BSD. It's weird because it's extremely uncommon, but it is part of a major BSD license.
That clause is in the common 3-clause version. The dropped clause from 4 to 3 is the one that was originally #3,
3. All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the <organization>.
> The Windows version of Eudora is written in C++. The source tree consists of 8,651 files in 565 folders, taking up 458 MB. There are both production (“Eudora71”) and test (“Sandbox”) versions of the code.
> The Macintosh version of Eudora is an entirely different code base and is written in C. The source tree consists of 1,433 files in 47 folders, taking up 69.9 MB.
Back then you didn't have a lot of choice of what language to use, windows was MFC on visual studio and Mac was codewarrior(I think). The Mac and Windows versions were written by two separate teams even though we sat next to each other, and I can't think of any code shared between them, anything we could have shared would have been trivial to write from scratch. I have no explanation for the enormous size of the Mac version.
I'll be damned. Joshua Stephens for real? I know your name from the Eudora Extended Message Services API docs -- though that was long ago. There were like four names there. How much of that was your work :) ?
Very interesting. Were you implementing to a spec with the Windows version, or was it simply just 'make the Windows version do what the Mac version does'?
Me too, and it's the main reason my Mac runs Snow Leopard. Some day that'll fail, and I'll probably end up running Sheepshaver in a browser tab or something.
It is utterly strange that the museum claims "to publish the code under the very liberal BSD open source license" and then prompts the user to agree to all this stuff that contradicts the classic BSD license:
The Computer History Museum (the "Museum") is willing to license the Software to you only upon the condition that you accept all of the terms contained in this Agreement. By clicking on the "I accept" button below or by downloading, installing or using the Software, you have indicated that you understand this Agreement and accept all of its terms. If you do not accept all the terms of this Agreement, then the Museum is unwilling to license the Software to you.
1. Grant of License. Conditioned upon your compliance with the terms and conditions of this Agreement, the Museum grants you a non-exclusive and non-transferable license for a single user, solely for your individual, personal and non-commercial purposes, (a) to load and install the Software; (b) to compile, modify and create modifications or enhancements of the Software or any of its components ("Derivative Works"); and (c) to run the Software or Derivative Works on simulators or hardware. The Museum and its licensors reserve all rights in the Software not expressly granted to you in this Agreement.
2. Restrictions. Except as expressly specified in this Agreement, you may not: (a) transfer, sublicense, lease, lend, rent or otherwise distribute the Software or Derivative Works to any third party; or (b) make the functionality of the Software or Derivative Works available to multiple users through any means, including, but not limited to, by uploading the Software to a network or file-sharing service or through any hosting, application services provider, service bureau, software-as-a-service (SaaS) or any other type of services. You acknowledge and agree that portions of the Software, including, but not limited to, the source code and the specific design and structure of individual modules or programs, constitute or contain trade secrets of Museum and its licensors.
3. Ownership. The copy of the Software is licensed, not sold. The Museum and its licensors retain ownership of the copy of the Software itself, including all intellectual property rights therein. The Software is protected by United States copyright law and international treaties. You will not delete or in any manner alter the copyright, trademark, confidentiality and other proprietary rights notices or markings or limited or restricted rights legends appearing on the Software as delivered to you.
4. Term. The license granted under this Agreement remains in effect for a period of 75 years, unless earlier terminated in accordance with this Agreement. You may terminate the license at any time by destroying all copies of the Software in your possession or control. The license granted under this Agreement will automatically terminate, with or without notice from the Museum, if you breach any term of this Agreement. Upon termination, you must, at the Museum's option, either promptly destroy or return to the Museum all copies of the Software in your possession or control and certify in writing to the Museum that you have fully complied with the foregoing and that no copy of the Software remains in your possession or control. 2
5. Indemnification. You shall defend, indemnify and hold harmless the Museum and its licensors from and against any damages, liabilities, costs, expenses (including reasonable attorneys' fees), claims, demands, suits or proceedings (an "Action") to the extent such Action alleges that your modification or enhancement of the Software, or any portion thereof, infringes any third party copyright, patent, trademark, trade secret or any other proprietary right, provided that the Museum gives written notice of the Action to you. The Museum may opt to participate in the defense of an Action, provided that the Museum bears any legal fees and expenses and other costs of defense it incurs in so participating.
6. NO WARRANTIES. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND. THE MUSEUM AND ITS LICENSORS DISCLAIM ALL WARRANTIES AND CONDITIONS, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, ANY IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT, AND ANY WARRANTIES AND CONDITIONS ARISING OUT OF COURSE OF DEALING OR USAGE OF TRADE. NO ADVICE OR INFORMATION, WHETHER ORAL OR WRITTEN, OBTAINED FROM MUSEUM OR ELSEWHERE WILL CREATE ANY WARRANTY OR CONDITION NOT EXPRESSLY STATED IN THIS AGREEMENT.
7. Limitation of Liability. THE MUSEUM AND ITS LICENSORS' TOTAL LIABILITY TO YOU FROM ALL CAUSES OF ACTION AND UNDER ALL THEORIES OF LIABILITY WILL BE LIMITED TO $100. IN NO EVENT WILL THE MUSEUM OR ITS LICENSORS BE LIABLE TO YOU FOR ANY SPECIAL, INCIDENTAL, EXEMPLARY, PUNITIVE OR CONSEQUENTIAL DAMAGES (INCLUDING LOSS OF DATA, BUSINESS, PROFITS OR ABILITY TO EXECUTE) OR FOR THE COST OF PROCURING SUBSTITUTE PRODUCTS ARISING OUT OF OR IN CONNECTION WITH THIS AGREEMENT OR THE EXECUTION OR PERFORMANCE OF THE SOFTWARE, WHETHER SUCH LIABILITY ARISES FROM ANY CLAIM BASED UPON CONTRACT, WARRANTY, TORT (INCLUDING NEGLIGENCE), STRICT LIABILITY OR OTHERWISE, AND WHETHER OR NOT MUSEUM OR ITS LICENSORS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH LOSS OR DAMAGE. THE FOREGOING LIMITATIONS WILL SURVIVE AND APPLY EVEN IF ANY LIMITED REMEDY SPECIFIED IN THIS AGREEMENT IS FOUND TO HAVE FAILED OF ITS ESSENTIAL PURPOSE. Some jurisdictions do not allow the limitation or exclusion of liability for incidental or consequential damages, so the above limitation or exclusion may not apply to you.
8. U.S. Government End Users. The Software is a "commercial item" as that term is defined in FAR 2.101, consisting of "commercial computer software," as such term is used in FAR 12.212 and DFARS 227.7202. If the Software is being acquired by or on behalf of the U.S. Government, then, as provided in FAR 12.212 and DFARS 227.7202-1 through 227.7202-4, as applicable, the U.S. Government's rights in the Software will be only those specified in this Agreement.
9. Export Law. You agree to comply fully with all U.S. export laws and regulations to ensure that neither the Software nor any technical data related thereto nor any direct product thereof are exported or re-exported directly or indirectly in violation of, or used for any purposes prohibited by, such laws and regulations. 3
10. General. This Agreement will be governed by and construed in accordance with the laws of the State of California, without regard to or application of conflict of laws rules or principles. The United Nations Convention on Contracts for the International Sale of Goods will not apply. You may not assign or transfer this Agreement or any rights granted hereunder, by operation of law or otherwise, without the Museum's prior written consent, and any attempt by you to do so, without such consent, will be void. Except as expressly set forth in this Agreement, the exercise by either party of any of its remedies under this Agreement will be without prejudice to its other remedies under this Agreement or otherwise. All notices or approvals required or permitted under this Agreement will be in writing and delivered by confirmed facsimile transmission, by overnight delivery service, or by certified mail, and in each instance will be deemed given upon receipt. All notices or approvals will be sent to the addresses specified by either party to the other in accordance with this section. The failure by either party to enforce any provision of this Agreement will not constitute a waiver of future enforcement of that or any other provision. Any waiver, modification or amendment of any provision of this Agreement will be effective only if in writing and signed by authorized representatives of both parties. If any provision of this Agreement is held to be unenforceable or invalid, that provision will be enforced to the maximum extent possible, and the other provisions will remain in full force and effect. This Agreement is the complete and exclusive understanding and agreement between the parties regarding its subject matter, and supersedes all proposals, understandings or communications between the parties, oral or written, regarding its subject matter, unless you and Museum have executed a separate agreement.
11. Contact Information. If you have any questions regarding this Agreement, you may contact the Museum by mail at 1401 N. Shoreline Blvd., Mountain View, CA 94043, by telephone at 650.810.1010 or by facsimile at 650.810.1055.
IF YOU AGREE TO THE FOREGOING TERMS AND CONDITIONS AND DESIRE TO COMPLETE INSTALLATION OF THE SOFTWARE, PLEASE CLICK THE "I ACCEPT" BUTTON BELOW. OTHERWISE, PLEASE CLICK THE "I DO NOT ACCEPT" BUTTON AND THE INSTALLATION PROCESS WILL STOP.
That license means it's essentially dual licensed, and the more liberal license will trump it (BSD), you cannot publish something as BSD and then "downgrade it" afterwards.
The license you were forced to accept is probably just a generic license covering all software in the computer history museum for when the owners have _not_ provided a more liberal license.
It's possible they have responded to this, because I now have these terms come up:
Copyright (c) 2017, Computer History Museum. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted (subject to the limitations in the disclaimer below) provided that the following conditions are met:
Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
Neither the name of Computer History Museum nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
NO EXPRESS OR IMPLIED LICENSES TO ANY PARTY'S PATENT RIGHTS ARE GRANTED BY THIS LICENSE. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
I get what you mean I don't like accepting them either, but they don't actually have the right to apply them since it's licensed as BSD and not a derivative... but in which case you are correct to ask them to remove it.
This is meant to provide an archive for the code. A major attraction of using GitHub is to allow easy pull requests and issues. If you're not going to be using those features, it's mostly useless when you already have your own infrastructure for hosting data. Lastly, if you're using a version control system other than Git, GitHub is not going to work well.
You can set repos to be archived, i.e. read-only, on Github these days.
Besides, I find it a whole lot easier to just casually browse through code on Github rather than download 129 megs of eudora_w_source.zip, extract it somewhere and rifle through it...
This isn’t the first project the Computer History Museum has hosted. At this point, I’m sure the thinking is simply that they self-hosted the previous source code drops.
I can imagine additional reasons (e.g., no desire to tie the museum to a third party, even if that party looks like it will be around for a while; who knows what policies Github might adopt in the future or which groups of people they may manage to upset?). But to be honest, I doubt a lot of thought went into this decision, this time.
The Mac archive doesn't have any resource forks, which is likely going to prevent building a working copy. Trying to figure out who to email at the CHM about it.
- From the "Windows Eudora Architecture.pdf" in the distribution