Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Violations Are More Common Than You Think

For what I see in robotics, I can say that most products I see being shipped violate hundreds (thousands?) of licenses. Both permissive (which generally require attribution) and all kinds of copyleft.

Many IoT products use stuff like https://www.balena.io/os and essentially ship products that contain docker containers of all sorts. If you ship an Ubuntu container, you ship a ton of packages with it that have license requirements, right?

Nobody cares, nobody knows, nobody wanna know. That's the situation.



In general, Debian has been rather strict with what licenses it allows in its repositories.

The right to transfer copyrighted works may also open people to legal action from employers in some countries outside the US. i.e. the identical contract text can have two different meanings depending where it is signed.

I prefer to license most works as Apache 2.0, and this ensures people can do whatever they need to get the use-case solved in whatever legal obligation they are encumbered within.

Note, implicit personal copyright is always in effect... The original author(s) must explicitly state the work is public-domain/CC0, or you could be in violation.

From what I've seen over the years, there are a few groups of trouble makers:

1. Companies from countries that have zero software copyright/patent laws. So will cycle GPL works into the closed-source production pipeline in commercial settings. i.e. the culture views the US concept of owning ideas as absurd.

2. Folks that think linking against a LGPL shared object for compatibility reasons obligates developers divulge source-code. Note, there is source code released under several different licenses for legal compatibility reasons. i.e. the work may be fine with static linking under one version, and at the same time violate LGPL with the identical binary.

3. submarine attacks... malicious/foolish folks that distribute works they have zero legal right to re-license, re-publish, or possess. For Unity developers on US soil, the store is peppered with works still owned by Studios that can get you sued out of existence.

CC0 and Apache 2.0 are the safest options in my opinion, but one still must trust the authors aren't poisoning the chain of trust with copyright violations.

This is another reason why out-of-band package managers are dangerous to commercial entities. Microsoft will be in business for a long time yet... =3


> I prefer to license most works as Apache 2.0, and this ensures people can do whatever they need to get the use-case solved in whatever legal obligation they are encumbered within.

I prefer copyleft licenses, because they ensure that the end user has access to my code :-). I don't do release free work on the Internet to help companies make money out of my work; I want to protect the users.

The great, great thing about Linux being GPL is that Android manufacturers have to share their modified sources, which helps mainlining a lot of hardware.


> I prefer copyleft licenses, because they ensure that the end user has access to my code

Now that so much software (the majority?) is used over a network standard copyleft licenses (GPL etc) no longer ensure this. If you want that you need AGPL.


> If you want that you need AGPL.

Or EUPL :-).


Why the hell would I get so many downvotes for that? EUPL is an actual license that does behave like AGPL in that sense.


Some people on YC tend to be an emotional group, and have feelings about facts they can't otherwise reconcile.

When it comes to facts, never self-censor for other peoples comprehension/mental issues... it will make your life boring like Disney. =3


It's just a shame it's GPLv2, so they don't always have to let you actually install your modified kernel.



I am happy when people find a financial upside to my work... but also understand the $1m revenue limit clause Unreal engine used.

Lets be honest, after a year staring at the same code base... nobody cares what happens to source-code... lol =3


I take it from another angle: I don't care so much about what people do with my code. It's not that I don't want others to make money with it (not at all).

It's just that as a user, I'm always happier when I get access to the sources of the product I buy. So I release my code under a copyleft licence for the sake of the other users like me.

To push the idea to the extreme, imagine a world where all the open source software that was ever written was under the GPLv3? Maybe most software would be open source in one way or another (and GPLv3 gives you a way to update the software). So you could buy a smart TV, get access to its sources and to tools that would allow you to upgrade it. I think it would be pretty amazing.


Conservancy's lawsuit against Vizio is aiming to do for TVs what the lawsuit against Linksys did for routers (it resulted in OpenWRT).

https://sfconservancy.org/copyleft-compliance/vizio.html https://sfconservancy.org/copyleft-compliance/enforcement-st...


I'm not as sure as you that it would work out that way.

Let's take your TV example. I bought my TV from the local store, or Amazon, or perhaps second hand from some random guy on ebay.

Naturally I connect the TV to my home wifi, use the built-in Netflix app etc.

Assume I'm like your aunt. I barely have the skills to plug it in, much less read the code.

In this scenario is it OK that every previous owner, distributer, retailer, had the ability to add to, or change, the code in the TV? Do you think a highly skilled person, such as yourself, can audit the code to see that nothing nefarious has been added?

Today I have "limited trust". I have to assume Samsung is gleaning at least some data from my TV. But I'm reasonably sure it doesn't have malware on it.

In your hypothetical future, can you be as sure?


Your optimism about how secure network-connected devices are against e.g. being added to a bot net in the status quo seems misplaced.

I agree with your concern not just for the future but for today. Something like TPMs could help attest that that example TV is running the software you think it is.

Of course, that would require manufacturers to care about security for their customers, which they currently don't. And the average person doesn't care enough, so the only way to change this is legislation/regulation.


Hmm you seem more optimistic about security than I am. In the current situation, most products don't get security updates ever.

With open source, you could end up with completely open source TV OSes (similare to OpenWRT for routers).


Very true, even cellphones get deprecated very quickly.

However... from the well worn car analogy at some point the warranty must expire.

In general, if software was designed correctly, it should have minimized the attack surfaces. Note if someone has physical access, than one must assume the stack is already insecure by intent or incompetence. =3


> In this scenario is it OK that every previous owner, distributer, retailer, had the ability to add to, or change, the code in the TV?

...yes? If you own something, you can modify it. That's certainly better than a world where the vendor can put in spyware and the user can't fix it.

> Today I have "limited trust". I have to assume Samsung is gleaning at least some data from my TV. But I'm reasonably sure it doesn't have malware on it.

And how would you distinguish their behavior to date from "malware"?

https://www.cnet.com/tech/services-and-software/samsungs-war...

https://www.techhive.com/article/2881944/samsungs-latest-sma...


If you don’t modify any of the source for the applications in those containers, then you have no changes to release. IANAL, but my understanding is that the GPL applies to a body of source code and not other things running alongside that source code. The distinctions are nuanced (Galoob v. Nintendo, etc.) but generally if you’re violating the GPL, you can kinda feel it.

Like, in Welte v. Sitecom, Sitecom didn’t just ship Welte’s work with their product (that would’ve been fine) they modified his work and failed to give source code access to their users (which is what the GPL demands).


> If you don’t modify any of the source for the applications in those containers, then you have no changes to release.

Pretty sure this is wrong. GPL says that if you distribute the binary, you must distribute the sources with it [1]. Modified or not. And not a vague link to the upstream project: the actual sources that were used to build the actual binary you ship.

Then pretty much all licences (permissive or copyleft) require some kind of attribution.

[1]: https://www.gnu.org/licenses/gpl-faq.html#UnchangedJustBinar...


Either the source itself, or a written offer to provide the source. But you're right that 'vaguely gesturing' at it doesn't seem to be permitted. Not to mention the license terms not being prominent in the binary (with hardly anyone outside of GNU actually putting a license command into their programs). This kind of stuff is why I'm not in the business of distributing free software.


And licenses are the easiest part. Scanning for occurrences of copyright notices deep down in the directory tree is usually more burdensome, because every singly file could contain a new copyright owner.

In theory, it could also contain a new license, but after your project has seen n license texts, it is increasingly rare to see the n+1th license text. Because there are far more people and combinations of people that license texts.


Not sure about balena, most Linux based embedded projects I worked on were based on Yocto and all the source is available either through OpenEmbedded or some vendor consortium (e.g. Linaro).

You only need to provide sources for the copyleft components you change and direct requests to the above entities for the rest.


Yocto does provide a way to track the sources. Balena (which just let's you ship docker containers from the Internet) doesn't.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: