Tbh, I don’t know why subscriptions get such a bad rap on HN. recurring revenue (ie subscription) is actually one of the best tool we have for ensuring the products/services we depend on don’t go under.
For example, “should continue working exactly like it did” sounds nice, but what happens when the company is out of business and your server’s kernel needs a kernel patch due to a security issue? Sure the server still works, but you probably shouldn’t be using it if you in fact want something that’s private/secure.
Because a lot of the times things don't need a subscription, but it's just a way for the company to squeeze more money out of you.
Some things you can't buy of course, like a streaming service, and I do pay for them. However, I will never 'rent' an online movie which I can only watch once or some such bullshit where the limitation is 0% technical and 100% someone wanting more money out of me.
Why not? I do it all the time for a simple economic reason: renting is $2.99 and buying is $14.99.
If I haven’t seen the movie yet and I don’t feel super strongly about it, I don’t feel like paying the full price. Of course if I end up loving the movie and want to buy it, I’ll end up having spent an extra $2.99 to rent something I now plan to own. But I can’t remember ever doing that. I rent. I watch. I move on.
Also I wouldn’t buy a movie that I can’t store in a physical format.
1. "Buying" is usually 15$ in my experience, not 3$.
2. Like said, the limitation is not technical, it's purely milking users.
3. I like to own stuff and sometimes play older games and watch older movies. Renting is just a non-starter for that, unless you want to overpay out the nose.
they say "buy and watch" but then say "pay per view service", then there are stupid watch time requirements and all that.
piracy is 1 click, just press play. then these idiots go and equate piracy as a heinous crime
And actually, I think that in many cases piracy happens because it's the easiest option, not because people wouldn't be willing to pay. But this is a bit off topic ;)
> You may obtain the complete corresponding source code from us for a period of three years after our last shipment of this product by sending a money order or check for $5 to: <snailmail address>
Without being illegal this is rather hostile. But then again they are selling subscriptions to open-source software so I expected something shady.
It’s perfectly ok to charge for GPL software.
Providing the source on a physical medium for a price is reasonable because no one should be forced to run a digital distribution setup and infrastructure just because they build software that derives from GPL pieces.
Their customers have a right to receive a copy of the source. But the company is not obliged to host an online accessible version of it.
Charging a small amount for a copy of the source is fine.
And I will go so far as to say that making demands about access to the source code in a manner beyond what the GPL requires, is actually hurting the adoption of GPL software, not helping it. Why should a company base their work on GPL licensed software if they are going to meet pushback even when they are complying with the letter of the GPL? They might just build something different all together, and with no open source at all. And where does that leave us? Definitely in a worse place.
My point is that we're not in 1997 anymore (date this GNU document was written), and thus I cannot believe that mailing disks is the easy way to do this. They are making this deliberately difficult, for both them and their users, by doing this over mail.
As for discouraging companies to deal with GPL, I am with you. I think this is a little bit different though, as they are not adding much value on top of the open-source code...
You still need to set up mirroring to keep it up-to-date, and janitor tags so that it matches whatever the customer actually received.
Much more importantly, you run the risk of a classic 'whoops I pushed an API key' blunder if your code gets auto-mirrored to a public repo.
Writing "if you're a human and you want the source code we'll give it to you" costs them about thirty seconds, satisfies the FSF, and carries zero risks.
Thousands of competent projects and millions of incompetent projects figured it out. This is not a reason to distribute source code digitally. Any use of this reasoning just makes the user seem stupid and unable to reduce the risk on this trivial problem.
> You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways...
Is "under the terms of this License" a clarifying clause that narrows down exactly which "Corresponding Source" we are talking about? That doesn't seem necessary given that "Corresponding Source" is already well defined. Alternatively, does it mean that you must convey the Corresponding Source and grant a GPLv3 license to the conveyees for that source? If so, it could be written more clearly.
If my second interpretation is correct, surely it doesn't matter much that the company has a slightly user-unfriendly policy to providing their source code - someone will just mirror the code on Github anyway.
The GPL definitely allows you this. What you are given is code that is as GPL as the one they originally got, which covers free distribution. This is the main mechanism that serves the purpose of the GPL.
Alternatively, maybe it's section 4
> You may convey verbatim copies of the Program's source code as you receive it, in any medium
Which is a bit strange, because it's granting you a licence on something (the source code) you haven't necessarily actually got yet, so normally this grant of license would live with the IP it actually applies to. But I understand why it's necessary for the GPL to work in a more complicated way than that, because its purpose is to be viral and to bind the recipient to granting the same license when he distributes modified versions.
On a lay reading, this could also be interpreted as "in the manner specified by this license". Whether that's how the courts would understand it is a question for a lawyer. It may hinge on what, specifically, was originally licensed under the GPL: the source code or the binary artifacts.
While true, this is misleading - if distributing under the "Written offer" term (rather than including the source code alongside the binaries), everyone has a right to receive a copy of the source.
a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)"
Speaking purely personally, despite not currently being in the business of physically-distributing GPL'd object code: put a copy of the corresponding source inside the product. Storage is sufficiently cheap nowadays that this isn't nearly as onerous as it used to be.
For bonus points, bootstrap the image then use it to build itself from its included sources for distribution.
In particular, section 6(b) of GPLv3:
> Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge.
We don't make the subscription optional at this time because the overwhelming majority of people on the Internet do not have a static IP address with a corresponding PTR record, which is required if you want to have deliverable email. There are other ways to handle domain registration, DNS and backups on your own, but we believe the subscription is a pretty great value for the convenience it provides.
Using email as an example, having to transfer email with drag'n'drop in something like Thunderbird is clunky, slow but works to a degree.
Having direct access to the mailbox directory on the filesystem would make it easier to transfer out/in (assuming you already have your emails in the same format).
These are honest questions because I have often thought about a similar project where a static IP is required and wondered if and how it could support itself.
This is how I view the internet. I pay for access, and this gives me access to, among other things, the web, and various "free services" offered on the web by so-called "tech" companies.^2 There is no obligation that I have to use them. I can choose what I think is useful and ignore the rest.
1. Previously we have seen the static IPv4 address marketed by ISPs in the US as a "business account". Personal use is not contemplated.
2. But the IP addresses we get from ISPs suck for things like running a smtpd. We need solutions to this problem besides "tech" company middlemen.
All data is accessible on local ports on the LAN, with or without the subscription service.
Considering R&D and manufacture, it looks to me like you're offering the box itself at cost or even below. Your obvious competitor is Synology, and they have an extensible storage space concept.
So I agree with you that the meat is probably in the Apps. You're offering an email solution as the killer subscription service using somewhat questionable marketing text. But again, that can be fixed. If you were to say "okay, we're planning on offering a range of subscription apps where the core concept is to provide a public-internet service endpoint and the resulting data gets funneled directly into your home box" then you're much clearer about the value you provide and customers would have an expectation that a) their app still works if the subscription expires (it just doesn't get any new data) and b) what they're paying for in the first place. Throw in an info graph that shows the data flow!
Of course, you might have to contend with open source implementations that offer the same endpoint services as a self-hosted option BUT you could even embrace that and make the protocols open because I suspect that the convenience of your all-in-one services would trump the complexity of self hosting in most cases.
Other services/apps you could offer along the same lines could be: federated social media, video downloading and conversion, video and audio chat, collaboration and office tools, home automation, and of course cloud backup (not the paltry 128GB currently folded into the subscription package, but a separate pay-as-you-go solution with "unlimited" storage).
One thing I definitely gather from that comment is that E-Mails wouldn't work, which appears to be the main selling point of the device.
If a customer doesn't want a subscription, they can still use the Helm on their local network and get access to all their data. Running without a subscription is not something we currently support because of a lot of variables that can prevent email from working consistently, creating a heavy support burden (which is costly) along with bad customer experiences. It's best for people wary of a subscription to go down the DIY path (and we end up with a lot of DIY switchers once they realize how much effort it is).
No problem. I see the technical difficulties with that and that you don’t want to support it. But is it possible?
If you want peoples’ (definitely mine) trust I’d suggest clearly decoupling the subscription from the device and communicating that it’s only for the E-Mail routing.
Otherwise it feels like renting a device with some extra initial cost, which is like 20% as good as actually owning something (If I’m already renting just take away the setup cost and make it 12$/mo).
There are much cheaper ways to send spam effectively than using a Helm so we haven't seen real issues around this.
The problem is that spammers will get into your customers' boxes and use them to spam.
there are plenty of ways to get around that particular problem (although a cloud server is one of the best). so why not provide the information and let the user decide rather then telling us all we need to use your subscription service.
Similar to how a home router/switch/NAS doesn't need anywhere near the same number of options and possible misconfigurations and code that isn't helping you at all.
(I'm skipping past all the issues with this particular unit by this particular company to the point that this is a good idea and I'd be nice to see a lot more options in this space along with less complexity...)
Given that your paying Helm to handle all the PITA aspects of home servers, it seems reasonable to me. This is coming from someone who runs their own home infra in proxmox.
My only concern is the lack of offline backups. You should be able to backup to an external hard drive, and decrypt these backups (e.g. for migration to a "real" server) completely offline, without depending on support.
Sounds mostly alright, although it seems you cannot buy it without the $99/yearly subscription, which makes me wary.
Sure, a static IP and domain registration is good, but it ought to be an optional addon.