I'm curious about whether the product name "Postwoman" violates Postman's trademark and whether Postwoman will be getting a C&D letter soon, demanding that the name be changed.
Normally companies don't get to claim broad trademark protection for prefixes -- Facebook has been shut down when trying to broadly enforce its trademark against anything prefixed with "Face" -- but "Postwoman" is close enough and is marketed as a competing product in the same place.
Update: It seems the author is also worried about this. On her blog post announcing the service, someone raised the concern, and she acknowledged that it's a problem: https://dev.to/liyasthomas/comment/ee8m
It's like one of those marketing things - at some point or another Postman will need to decide what to do here. If they go after them, postwoman will get tons of "free" publicity and probably get the PR win, even if it means renaming to "Post Woman" (with a space) or declaring they will fight it in court.
If Postman decides NOT to pursue it, some users may simply be turned off to the fact that they decided to invade the space of Postman with a similar name. I and probably others would probably have respected a different name altogether.
If Uber got a competitor called Ubor people would probably also be annoyed.
EFF is debunked this myth many many many times I wish people would stop spreading it, as it just an excuse for Over Aggressive enforcement that companies that DESIRE to do it use to divert the bad PR, "We had no choice" sounds alot better than "We want to crush any competition"
> Second, Canonical is not “required” to enforce its mark in every instance or risk losing it. The circumstances under which a company could actually lose a trademark—such as abandonment and genericide—are quite limited. […] Courts also set a very high bar to show abandonment (usually years of total non-use). Importantly, failure to enforce a mark against every potential infringer does not show abandonment.
> The evidence in this case shows that Metalock Corp. has and is continuing to take reasonable steps to maintain its rights in the mark, to use that mark, to license its use, to advertise it and to prosecute infringers. The owner of a mark is not required to constantly monitor every nook and cranny of the entire nation and to fire both barrels of his shotgun instantly upon spotting a possible infringer. Lawyers and lawsuits come high and a financial decision must be made in every case as to whether the gain of prosecution is worth the candle. These defendants have not proved that because of the lack of efforts by plaintiffs in "policing" use of the mark, that METALOCK has become so diluted by widespread use by others that it has lost its distinctiveness.
My interpretation is that companies do indeed have to prosecute a high enough fraction of infringements to protect their trademark, but they don’t necessarily have to prosecute a given infringement. So, for example, Postman could keep their trademark if they left “Postwoman” alone, as long as they later sued “Post Man” for infringement.
Refusing or failing to pursue action against a violation of a trademark can cause a trademark to be considered abandoned and therefore invalid. It is a genuine legal concern. This is supposed to prevent individuals and companies from “sitting” on a trademark without the intention of using it.
So you are saying that you think that "Postman" declining to pursue legal action against "Postwoman" might lead to a court deciding that "Postman" is a generic mark - do I have that correct?
Can you point to a case even vaguely close to this fact pattern?
>So you are saying that you think that "Postman" declining to pursue legal action against "Postwoman" might lead to a court deciding that "Postman" is a generic mark
Per this posting from a law firm [1], as your question is stated with the inclusion of "might" the answer is yes. Apparently it can go one of three ways: abandoning, not impacting/abandoning, or diminishing. Two of these results are bad for the trademark holder.
I'd assume a C&D letter would be sufficient to get a proper result or at least should be the first move in these matters, but I'm not a lawyer nor play one on TV or online.
You don't necessarily need to sue competitors for being misleading, but you do generally have to show you are trying to defend your trademarks and a lawsuit is a nice expensive papertrail.
I assert that literally zero of these cases are even close to this one in terms of the degree of abandonment represented by failure to take action against Postwoman.
Can you specify a single one that you think is similar?
You could have made a simple search and found more confirmation than I could possibly provide. Even the USPTO has top-level search results to that effect.
Trademarks have to be defended or else you can indeed lose it. That's a fact. Copyrights on the other hand are not the same. You may be confusing the two and lumping them all together under "IP" but there are many legal differences between different types of IP.
I am very familiar, and have formally studied, trademark genericization. Your patronizing comment is not helpful.
Can you point to a mark that you think was genercized in a similar fashion to what you project happening if Postman does not pursue legal action against Postwoman?
Not a lawyer, but in this particular case it appears they reaffirmed the lower court stating the vendor couldn't sell products with trademarked Greek organization lettering (though he could make up ones using the Greek alphabet as demonstrations) and that they could continue to sell their "double raised crest backing" paddle which the group was requesting they be banned from doing.
So the trademark was protected it would appear. Even though the infringing company makes a good case (laches) for selling said products without regard from the fraternities/sororities for decades (in fact, they were selling to these organizations, so they were generally aware of the company's existence and practices).
>>>Quite simply, the view that a trademark holder must trawl the internet and respond to every unauthorized use (or even every infringing use) is a myth. It’s great for lawyers, but irritating and expensive for everyone else. And when done clumsily or maliciously, it chills free expression.
Trademarks are protected to prevent fraud and impersonation of other companies. So we don't want to accidentally mistake a e.g. gougle product as a google one. That was the very legal intention of trademark laws.
In the case of postwoman, it's kind of hard to imagine anyone would mistake it for postman. So it's unlikely postman would win a lawsuit against it.
IANAL but the basic sniff test is could "Postwoman" be confused with "Postman?" I think the answer is yes. With the author calling it an alternative to "Postman," you have the author acknowledging Postman is a strong trademark. And it's not like it's the only one available fitting the "{HTTP-METHOD}{MAN|WOMAN}" construct-- you could rename it "HeadWoman" and probably be okay.
Zero chance of that being a primary issue when you're dealing with a directly competing product.
If they allow their trademark to go unprotected from an extremely blatant hit like this, their trademark might as well be worthless. Having a competing product in the market using an intentionally similar name, is a large value debasement for the Postman brand & offering (not to mention the $58m in venture capital that is betting on the value of those things).
Is Postwoman from the Postman company? They're similar products? Are they competing products from the same company? The sound you hear is millions of dollars in venture capital being flushed down the toilet.
No serious company is going to hold back on a legal response just because you staple woman/women/her/she to their existing trademarks and seek to compete head-on with their products or services.
Trademark laws are about consumer protection which is why companies must enforce their trademark or they risk losing it. In this case, I initially thought Postwoman was a spinoff of Postman built by the same team (not sure why they would do this but I guess representation is all the rage nowadays). If a consumer could mistake the product as a different one then it's grounds for trademark violation.
Disclamer: I am not a lawyer but I have at least a high level understanding of trademark law.
Huh .. Postman is MPL-2.0 is seems, but it is also a commercial operation (and even non-commercial organizations often hold and protect trademarks like Mozilla). It's not a joke or broken project, so it wouldn't be protected under parody. I too am curious if Postman will go after this project to defend their trademark.
> the author stripped down Chromium for the UI in order to get something much lighter than an Electron app.
If an organization did this, I'd be all for it. An individual? I'd bet this is going to slow down updates to Chromium significantly, and eventually lead to either security issues or maintenance fatigue resulting in closure of the project.
I'm not saying it's 100% going to happen like that, but that's on the wrong side of my risk tolerance line for adding a tool to my everyday suite.
It’s essentially an API testing tool. It is mostly used to poke endpoints on a development server and sometimes to learn the output patterns of a public API, what security concerns are there in stripping the UI?
It's less about the actual changes made and more that one person is maintaining a branch that diverges (significantly?) from upstream, on a project that is fast-paced and constantly under attack. If I'm using this tool to run tests on the network, and I'm several patches of Chromium behind, that makes me vulnerable.
That tradeoff can be worth it, but all I'm getting out of it here is reduced application footprint? I'd rather use the bloated tools or wait for someone with deeper pockets to make a less bloated tool. Or a similarly small project that writes it natively.
I haven't exactly dug into the codebase, but "stripped down Chromium for the UI" could very well mean CEF, which is widely-used by a lot of things (commercial and otherwise) and directly supported by Google. However, whether that's more lightweight than Electron is debatable.
If that concerns you, though (or if the author really did outright fork Chromium), it looks like it runs in an ordinary browser, too (e.g. via postwoman.io or localhost:3000).
The main differences are that Paw is a native Mac app, paid, and closed source.
Insomnia is open source, cross-platform, and free to use (although there is a paid plan).
Some of Insomnia's biggest differentiators are it's GraphQL query editor (autocomplete, linting, etc) and it's ability to be customized via plugins and themes.
It looks like Postwoman is is more of a simple utility right now. Perhaps it will grow to something more full-featured in the future but that seems to be the main differentiator right now. Insomnia, for example, supports environment variables, a GraphQL IDE, plugins, and many different authentication formats.
As the creator of Insomnia, I love seeing new projects like this and am really excited to see what Postwoman grows into. It looks awesome, is open source, and there's always room for more developer tools! :)
I always wonder why some many developers work with Postman (or Postwoman), and so without any automation whatsoever. Example: Requesting some JSON payload and extracting some generated id from it looks like a clumsy point-and-click adventure. With curl, you can use any appropriate program to extract output, say jq:
curl acme.org/my/resource | jq -r '.id'
I see how some project manager doing a presentation of a bleeding-edge feature might profit from Postman, but as a developer?
I guess I don't do enough interesting queries to need a dedicated GUI client. I usually rely on httpie over plain curl or postman. I'd never even heard of insomnia.
For one, the GUI allows you to store your various HTTP actions and replay them, and while you can get that in your shell it takes a bit more work to set it up/present it/reuse it.
I've used it often for ad-hoc requests, where there's authentication/OAuth tokens required, JSON payloads that would be a pain to put into the shell.
Obviously it doesn't negate the need for testing or replace tests, but not every ad-hoc investigation needs to be wrapped in a test.
Maybe I'm missing it, but I'm not seeing the full response headers, just "cache-control" and "content-type". Being able to see the full response headers would make this a much more useful tool for debugging APIs.
If Postwoman doesn't tickle your fancy, I'd take a look at https://github.com/pashky/restclient.el. (I believe there's a vim equivalent, too.) You can save requests in a simple .http file, and check them into your codebase. Makes collaboration very simple.
I'm encouraged by the GraphQL support with docs, except there appears to be no way to provide headers (such as Authorization), which means I can't even fetch my schema.
Does anybody else take a project a _lot_ less seriously when all of their documentation and commit messages are plastered with emojis? I feel like I can't create a cohesive narrative in my mind when every sentence ends with a unicorn or a rainbow or a volcano.
When emoji use follows a strict convention (something like https://gitmoji.carloscuesta.me/), it can make it easier to scan a list of commits and get a rough idea of where the development focus is (i.e., hardening vs. feature development).
I've seen this convention before. I personally find it more useful to tag commit messages with [fix], [docs], etc. It makes it more easily searchable, which is IMO what you really want. You can:
Using emojis feels a bit cliquey, in-groupy. It's an extra barrier to a new developer wanting to get familiar with the project or contribute a quick fix. And you know people are going to get emojis mixed up because different associatons come to mind for different people, so project committers are going to have to be diligent about noticing and correcting mistakes. For me, the effect is the opposite of the casual and inviting atmosphere I think they're intended to create.
My first smartphone was a Galaxy S2, and I frequently used an emoji that looked like a character giving a sly winking-type gesture.
It took me several years to realize that this was actually the eye-rolling emoji, and every other system's implantation clearly showed this. Some of the more strange responses I received started to make sense.
Why not just use "[rotating_light] Lint" as the commit message? Or even better: "[lint] Make changes recommended by foo lint\n\nThis is the foo command used: ..."
That is far too much vocabulary to use effectively. A single-word designation would be much easier to discern and easier to translate. A word can be translated in a way that is meaningful but the “obvious” associations of the emojis may not make any sense in the context of a different language. Replacing language with inscrutable symbolism is bad design.
I've been using the same branching strategy for about 5 years, and it has worked really well. I suspect it's fairly common, although everywhere I've worked we've switched to this from something with less structure. Essentially the branch naming pattern looks like:
[ticket-type]/#TICKET-[ticket-description]
In practice it might look like:
bug/APP-123-prevent-auth-redirect-loop
It makes it so you can easily automate ticket statuses with commits and merges, grep for types of issues without needing to type/remember an emoji, and you don't need to worry about emojis rendering differently on different platforms. The text will always be the same.
The emoji thing is fine if it's for fun - we should all enjoy ourselves and our work a little more - but I'm hard pressed to see the practicality of it.
The first thing that comes to mind is that it takes up less space and is thus easier to scan. Also, people with visual impairments may have an easier time scanning based on color/shape rather than reading each individual line.
Also, it's just as easy to grep for ':bug:' than 'bug', or rather, it's more specific to do so. Likewise, people suggesting [bug] have to worry about whether their shell or grep is going to interpret the square brackets (they will).
git log | grep '[bug]' - does not do what you want
git log | grep [bug] - fails in ZSH; works as above in bash
git log | grep bug - matches lots of things, not just the tag
git log | grep ^bug - Doesn't work because 'git log' puts spaces in front of commit lines
git log | grep :bug: - Does exactly what you expect it to and nothing else.
That's the practicality that I see, personally.
> you don't need to worry about emojis rendering differently on different platforms
You don't really need to worry about that anyway, as long as you're generally on the same one or two platforms. A user on Ubuntu will always see the same bug, even if :bug: gives them a different bug illustration than an iOS user sees. In the git commits, it's represented as the tag (:bug:) and not the literal emoji.
Lastly, I fail to see anything that has to do with branching strategy with regards to emoji. This is purely commit messages and (in this case) the readme. Your branching strategy doesn't tell us anything about individual commits.
No, emojis are incredibly expressive and enrich all forms of writing. I'm excited to see this style of communication penetrate more spaces :slightly-smiling-face:.
Edit: The emoji I added to the above message was stripped by HN's submission system.
It's an intentional design decision as far as I know (there was a phase where it did support them, and people didn't like it, and I think the block isn't perfect, so some emoji are still possible)
Long before you and I were born, people typically only communicated orally. The alphabet wasn't really designed for spontanous communication. Countless emails were misinterpreted before the smiley appeared. But I do agree they are not strictly necessary for a "README" ...
They're an advancement in emotional communication on mobile devices.
I agree that there are contexts where emoji may be inappropriate (definitely Github, I'd disagree about HN, because I think this place needs to lighten up) but they do clearly have utility for a lot of people.
> but when you start letting short/irreverent/low value content through and you end up with reddit
Many brilliant minds throughout history were also possessed of a keen sense of humor and a playful attitude which many HN users would consider infantile and puerile in modern culture. The implied inverse relationship between humor and "quality" of either intellectual or technical merit doesn't really exist, it's a cultural affectation, a taboo born out of the fear that humor breeds normality and normality brings the Eternal September effect.
However, HN doesn't often attach the same stigma to hostility or banality as it does humor. As a result, hostility and banality tend to flourish and become a means of virtue signalling because they aren't considered to be inherently toxic, merely bad form. Maybe dang wouldn't have to spend so much time talking users down from ledges if the culture here didn't require people to take everything so damn seriously.
And people have been complaining that HN is turning into Reddit since the beginning. There's plenty of content on Reddit of equal or greater quality than on HN, and plenty of HN users who also post on Reddit and elsewhere, and plenty of low value, low effort content here. Having that content also be humorless doesn't really add value.
People talk about it all the time, or rather, they complain about it all the time. It's so common and tedious that there used to be a rule in the guidelines telling people to knock it off, calling it a "semi-noob delusion."
I personally think that first part of the readme made good use of them and kinda helped me navigate the different sections, but they're very distracting in the commit messages, H1s and the description.
Not every line needs an emoji at the beginning or end, and IMO rarely does it need both.
Emojis in text IMO are like jokes in movies. The funnest movies have them, they're placed well and they're effective. Other movies have so many of them they just pull you from the story and then you just can't relate.
I personally dislike prettifying of text interfaces with forced conventions/icons/*mojis. Text interface is well, should be text. There are well defined conventions and tools built around these conventions.
Tag with [tag], use consistent spacing etc. and, make it easy on the eyes.
Same with glorified .bashrc files used to create graphic-git command prompts.
There is no difference between a glyph that displays a letter and a glyph that displays an image, it's an arbitrary matter of the encoding between code points and a font. And as emoji are already part of Unicode, they're just as much "text" as ASCII.
That's technically correct but, when working with console and text processing stuff emojis and other multi-byte characters complicate the things sometimes.
My native language also requires unicode characters to type correctly, and they create the same problems hence, I also prefer avoiding these characters.
These are my preferences, I cannot (and should not) stop the progress. However for me, simplicity and practicality is much better than fanciness.
I'd not fight over this stuff if I was contributing to a project which embraces these concepts and play along without any fuss or objection but, I won't use these in my own projects.
I know I don't. It's one thing to sprinkle some fun here and there, but I have seen many projects (JS mostly) with so many unicorn emojis everywhere, and a huge logo in it's GitHub readme. It's not that the library name is self explanatory either.Mocha, Jasmine, Karma.. do they _really_ sound like testing frameworks?
The whole issue is further amplified by the fact that the imagery isn't even remotely related to the actual content. Even the current latest commits list on the repo homepage has commits ":rotating_light: Lint" and ":zap: Lint".
Does changing : rotating_light: to :rotating_light: (removing a space) require rewriting history in git? does it mean people who have cloned the repo will need to (yuck) force pull?
Author here: Sorry if my usage of emojis made you uncomfortable. I don't think using emojis would soften the seriousness of a project There's lot of projects that uses Gitmoji and it's all v.appreciated too. Don't make someone feel lesser when you don't like it. I like to keep a signature on everything I do, whether its commit messages or anything else.
Can you define "Plastered"? From what I can see, of the most recent 35 commits, there exist seven emoji, plus one that would have been but was a typo. Also, none of them are unicorns or rainbows or volcanoes.
I'm wondering if you're referring to a different project that you've seen and were just reminded of it, or if you're exaggerating because you saw something you didn't like.
Also, using visual indicators is nothing new; Jenkins uses thunderstorms and suns to denote build status, and marketing pages are often full of images, icons, and iconography.
The reality is, the younger generation communicates differently than the older generation, and different subcultures communicate differently from each other. Maybe you take someone less seriously because of the way they communicate, but that's on you, not on them.
The problem with emojis is that they render inconsistently in different mediums and there are better ways to communicate the same intent, especially to users less familiar with emoji usage. For a project like this I think its alright, it adds spunk to a already spunky project (I define spunky as gung-ho competing with a funded and mature project because you think you can do a better job - which I support). I disagree with their usage in the h1 tags and a few other places because I think it looks bad, but its not my project and not a massive deal regardless.
All said I don't like the name because it puts Postman in a tough situation, keep the gender pronoun if you want just don't make it near identical to them.
Personally they've has helped with the automated messages my team's software pushes into project management system because they visually represent what type of message was pushed.
Seems like it's doing the same thing here, I kind of hope to see more of it!
Personally doesn't bother me. It definitely gives a more playful theme which I think is a good thing instead of trying to read a wall of just text documentation.
The short answer is the modern word woman has a separate etymological root than the word man. And the word man has had linguistic changes recently that mask those origins. Woman as well actually.
Man originally meant human really, and woman used to be Wifman (somewhat literally female human). Wife is a holdover from this prior to Middle english usage of the term.
Old english used wer and wif as man/woman respectively, and as you can guess Werewolf derives from the old ussage of man.
In short, its complicated and woman isn't a derivative of man. Its much more interesting than that. You can't look at the modern spelling of words to derive much on how we got to this point. You'll make a ton of categorical errors that way, especially in English given man used to just be the human race. Our modern take of man anywhere as needing to be replaced with woman depending on gender is slightly amusing once you know the etymology of the term in that regard.
Ditto "man" and "he" being used when the sex of the person in question isn't known, or as a poetic stand-in for "human"—the usual complaint about that is that it implies maleness is "normal" at the expense of women but it could just as easily be seen as erasing what's distinctive about maleness, at its expense and in favor of women, who get their own dedicated words that aren't multi-purposed and also used to refer to men in some cases. Just a matter of perspective who's harmed by it (if you take anyone as being harmed).
Normally companies don't get to claim broad trademark protection for prefixes -- Facebook has been shut down when trying to broadly enforce its trademark against anything prefixed with "Face" -- but "Postwoman" is close enough and is marketed as a competing product in the same place.
Update: It seems the author is also worried about this. On her blog post announcing the service, someone raised the concern, and she acknowledged that it's a problem: https://dev.to/liyasthomas/comment/ee8m