Why proprietary software?

General Othernet Discussions FAQ
1

If Outernet is all about freedom and openness, I’m curious why the reception software is proprietary. Did you consider existing open source multicast file transfer software and find it lacking?

1 Like
2

The main reason is getting off the ground fast. Of course, the fact that it’s closed-source is, indeed, a bug, so it needs to be fixed, but we prioritized reaching the tech preview stage over having it all open-source. We’re currently eyeballing OpenCaster as a potential alternative in near future, but no time frame for that yet.

3

It seems like either

  • This is fixed before the first lantern ships & it ships with FOSS
  • Its fixed later, no way to update the first shipments to use the new protocol and they become useless bricks
  • There is some way of doing a OTA software update that isnt really insecure and open to abuse.

Are those the possiblities? or did I miss any?

4

Another possiblity is that the current software might eventually become open-source, but I cannot comment further on that. Also, in the second scenario you mentioned, software on Lanter will most likely be updatable, so there’s no reason for Lantern to become useless bricks.

5

Hi Branko

Thanks for your reply.

Do you mean up-datable Over The Air (OTA) so the device automatically updates it’s own firmware?

This is possible I guess, but it seems like it would need to be carefully thought through to stop some repressive govt sending a signal to all lanterns in their area to brick themselves.

It would be really good to see a software/ hardware roadmap for the Outernet project, based on the assumption you meet your Kickstarter goal.

6

Yes.

Yeah, there will be something in future.

7

I really think a roadmap would help before the end of the crowdfunding. I know there is lot’s of scepticism about crowdfunded hardware projects due to their high failure rate. A roadmap showing it’d really been thought through would give more people the confidence to invest.

8

We’ve had a very very long thread about this topic already, so I’m not going into details again. Look in the FAQ section, and you’ll find it pinned.

I’ll just say that capable people are working on the Lantern design. When they feel comfortable publishing something, they will, I’m sure. I hope you understand.

9

so i have looked at the faq section and i didn’t see anything about this.

for me, proprietary software is a blocker. do we have any guarantees that this will be open sourced eventually?

free software is not just a “feature”, it’s a way of working out a project. getting the community involved early in the project is essential to getting a good free software project going, and I am very skeptical of “we will free it one day” claims.

it certainly looks bad on a project that claims to be about freedom of knowledge - how can it be so if the inner workings of the project are not free? from what I understand the hardware isn’t free either - how then can we fix those machines once they are out in the field? how do we replicate them?

those are essential questions to this project if it doesn’t want to fall in the usual techno-colonialism trap.

thank you for reconsidering this approach.

1 Like
10

I think essentially they are planning to use one of this companies products:

The low level software for these devices is written by this company and there is no hardware like this that operates with open source.

So it would be a case of having to design & manufacture an entirely new software defined radio & demodulator, which would make the whole project unviable

I could be wrong on that though…

11

there are quite a few free software defined radio, for example the gnuradio toolkit, and there are certainly at least some devices supported by gnuradio and others… the whole point of SDR is to have stuff in software, and therefore open, in my mind… not sure why having SDR forces closed source.

13

Hi Branko

You mention OpenCaster. I assume this would be used to transfer the high data stream over DVB-S by converting the data files to Mpeg? The linked image on this thread seems to support that theory: We Moved!

So I assume that for the 2Mb / 10Mb broadcast it’s not going to be Mpeg video? More likely to use a audio carrier?

Would the Amateur Multicast Protocol be of interest for the Audio version (assuming this is how it’s going to work) Protocol
http://www.w1hkj.com/downloads/flamp/Amp-2.V3.0.Specification.html

The software
http://www.w1hkj.com/flamp2.1-help/index.html

14

Ok, so to you and everyone else that keeps talking about freedom in software world. I totally udnerstand what you are saying. Many of the user-facing software I write is released under GPL and I think that’s the ideal way to develop software. It’s a high-priority target for us as well. But it’s not the most important thing either.

It’s very simple. You don’t get funded for using open-source software. You get funded for having a working solution. So that’s our priority. If you need to get funded in order to pay the bills, you play by the rules and prioritize things so that you get paid. That’s one of the conditions for the actual broadcast to remain free. Having free software and no broadcast is worse than having non-free software and free broadcast.

There’s a couple of ways you can help solve this problem:

  • Find open-source alternatives that actually work today (and preferably demonstrate that it does work)
  • Write open-source alternatives that actually work today
  • Throw cash at us, so we don’t have to worry about investors
  • Fork the project and run it whatever way you feel is ideal
  • Anything else?

Just saying “you need to open-source your software” is not telling us anything we don’t already know, and it’s not helping in making that a reality.

Many were skeptical we’d broadcast at all, and we do broadcast.

Yes. It turned out the cost of actually running an OC-based system would be higher compared to what we currently use. I don’t know the exact numbers, but that’s what I’ve been told anyway.

Frankly, I don’t think OC’s that important, though. It’s server-side software. Even if you had it up and running, you’d still need metric shtton of $$ to do anything useful with it (which is broadcast data). What’s more important is the client software. I’ve found something called RedButton or something along those lines, but it was a bit dated, and it’s not compatible with our broadcast. It is compatible with OpenCaster, but ufortunately, we don’t use it.

Yes, that’s correct. Truth is, I’m not directly involved in thart part of the stack, so I can’t really say what software would be used, though.

15

Thanks Branko

Find open-source alternatives that actually work today (and preferably demonstrate that it does work)

The problem is there is no specification to know what these software’s should achieve. I agree that the priority should be the client side devices & the protocols. Server side stuff can be worked out later, assuming the protocol is open. Are the main challenges something like this

High Bandwidth Pillar/ village/ (dish) software

  • Convert data to Mpeg at uplink station: Opencaster?
  • Multicast data over satellite/ at uplink station Opencaster?
  • Convert Mpeg to data (client side) Opencaster?
  • Client side firmware/ OS Raspian? Android?
  • Client side library manager FOSS by outernet

Low bandwidth (lantern)

16

We don’t try to adhere to specs if there’s a better solution. So there needs to be a data carousel (based on some standard like DSM-CC?) software with encoder, and a matching client for the receiver end (Librarian is not that). Since I’m not the one operating it, I can’t tell you much more. The carousel software should ideally support bandwidth management so it can give more bits to priority channels (e.g., for emitting news and other real-time-ish information faster). And it needs to be low-cost.

As mentioned, we abandoned OpenCaster because the estimated cost of running it was high. Personally, I’m not an expert in that field, so a proper demo of a low-cost OpenCaster-based setup would be highly appreciated (or at least some theory on how you could set it up).

17

@sam_uk Do you have much experience with OpenCaster in a production environment? The current proprietary server and client software (the layer below Librarian) has been production tested for many years. It reliably conducts OTA updates and has all of the content prioritization that we have previously spoken about.

I don’t think there is anything wrong with OpenCaster at all. The Italian engineers behind the product are very sharp. In terms of cost, yes, it’s open source, so it’s technically free. But what about support and ongoing product development? And the ability to execute and iterate quickly?

Regarding the use of one of the open source SDR applications: GNU Radio with the RTL2832U can in no way compare to the performance of a purpose-built demodulator. We tried to make this path work.

There are many considerations to remember: power consumption, ongoing support, product development, reduction in costs over time. It’s all part of the equation.

18

Hi Syed

No experience of Opencaster. To be honest I’m mostly interested in the Lantern spec, rather than the pillar. Do you think Flamp is likely for the Lantern?

It reliably conducts OTA updates and has all of the content prioritization that we have previously spoken about.

According to this:

Opencaster does OTA, Prioritisation etc too.

But what about support and ongoing product development? And the ability to execute and iterate quickly?

For basic support there is the forum: Avalpa Community • Index page

Or the company provides support/ development: http://www.avalpa.com/faq/25-free-software/17-q-if-your-software-free-how-can-you-do-some-business

Have you contacted them?

19

Hey @sam_uk Both Lantern and Pillar use/will use a lot of similar software.

What is Flamp?

I’m very aware of Avalpa’s work and have read all of their papers. Very smart guys; we’ve been in touch. But saying that support is available in a forum is not a way that we want to build a service that will be constantly used all over the globe. That being said, Andrea and Lorenzo are more than willing to provide direct support–for market rates of senior software engineers.

I’m not sure if you’ve read through the OpenCaster manual, but it’s pretty dense. The authors even state that it’s complicated and hard and that you’re better off paying Avalpa to support the product. So how is that all that different from a proprietary application? I met a computer science professor at Northwestern who once told me that his department required all of his work to be open source, but that he easily obfuscated the code in such a matter that he was the only person in the world who knew what any of it meant.

I’m having a hard time understand what the obsession with open sourcing every single bit in the stack is? We never claimed to be building the next Ubuntu/Canonical. We just want people to have access to information and education. What’s more important than a philosophical belief that everything should be free and open is the security of a proven product, good chemistry with the team, and rapid product development.

And just because the source is not open does not mean that Outernet is restricted from accessing it.

2 Likes