Computer History Museum Makes Eudora Email Client Source Code Available(globenewswire.com) |
Computer History Museum Makes Eudora Email Client Source Code Available(globenewswire.com) |
- From the "Windows Eudora Architecture.pdf" in the distribution
> 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.
So it's not a standards issue at all.
http://web.archive.org/web/19980212160741/http://www.email-c...
edit: fix link
-Why they took me off phone support
Even on my own OSS projects I tend not to do that anymore.
The Linux kernel still retains much of its fucks and shits, and apparently has gained a whole lot of crap: https://www.vidarholen.net/contents/wordcount/
something like "// this is fucked" is pretty darn common, even in corporate code. It gets stripped by minifiers anyhow
void AnalScan( void );
Fun idea. We liked to try to make it look like the produce section at Fiesta.
Always assume that one day, the world will see your code.
Maybe you should stop writing code that you’re embarrassed to let other people see. Your coworkers will thank you.
> The source code we are distributing is what we received from Qualcomm, with only the following changes:
> * addition of the CHM copyright notice and the BSD license
> * sanitization of “bad words”, mostly in comments, as requested by Qualcomm
[0]: http://www.computerhistory.org/_static/atchm/the-eudora-emai...
"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."
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.
Edit: CHM has a survey for past/current Eudora users: https://www.surveymonkey.com/r/eudora-poll1
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.
after checking email fails the second time,
Server SSL Certificate Rejected pops up
click on Yes
click on Tools then Options then Checking mail
click on Last SSL Info
click on Certificate Information Manager
under Server Certificates, keep expanding until you reach the bottom one
click on it then click on Add to trusted
click on File then Check Mail
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.
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?
https://github.com/avar/rhqben/blob/master/Eudora_M_source/V...
On one hand, a user base wants the old product with minimal twists and they are known to balk at anything more than that.
On the other, project survival likely depends on getting new users on board, in which case an old design and UI are probably going to be detriments.
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.
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...
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.
At the very least, none of the original new mail images, sound, etc (all PCT, SND resources). I miss hacking Eudora with ResEdit.
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 :)
In your case I wouldn't change a thing.
Clan Cumming (or Comyn): https://en.wikipedia.org/wiki/Clan_Cumming
Clan Graham: https://en.wikipedia.org/wiki/Clan_Graham
Wiktionary seems to believe in a Middle Dutch "*rōt (in placenames)" referring to the color red.
https://en.wiktionary.org/wiki/Reconstruction:Proto-Germanic...
https://www.washingtonpost.com/news/morning-mix/wp/2018/05/2...
I woke to my phone ringing quickly followed by this exchange of messages: https://imgur.com/a/7aLLw22
> 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.
[0]: http://www.computerhistory.org/_static/atchm/the-eudora-emai...
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.
I didn't accept it. I'll try to get them to remove those terms, that appeals to me more than agreeing to legal terms I don't intend to abide by.
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.
Your reading makes excellent sense though, since a lot of the houses here are made of red brick.
Maybe he did not want to be limited in his choices of brick colors :)
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.
We have ugly words for ugly feelings ideas places things. Putting them in there is no crime.
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.
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.
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 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.
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.
Hehe, I have one of those, too. But unfortunately it is an external drive, and none of the computers I own have a parallel port...
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.
Where it is not the right tool for the job, use the tool that is instead (IMAP presumably in this case).
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.
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?
For example, no searching.
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.
The lack of a remote manipulation interface has always been a problem, however.
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?
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?
So maybe I'll be replying "Why did you send me an empty message?"
And maybe some email list software will have the same problem.
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.
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.
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.
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."
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.
The big deal here is users do not get copies of content, instead notifications content is, or may be available.
And that's then. What about searching mail archives? You know just that sort of thing being just a little broken is not an accident.
Or it changes.
"You told me to fuck off"
"Prove it"
Message says hugs and kisses.
That's gonna happen. Count on it, with lame screenshot battles being "proof."