64
submitted 5 months ago* (last edited 5 months ago) by alphacyberranger@sh.itjust.works to c/programming@programming.dev

How do people find out or know whether your repo which is having MIT or apache or AGPL license is being used by a corpo and profiting from it and not making the code open source or paying license fees?

top 19 comments
sorted by: hot top controversial new old
[-] Knossos@lemmy.world 70 points 5 months ago

You don't.

Unless it is publicised or an obvious bug exists in your code and you see the consequences of it in their system.

[-] ptz@dubvee.org 43 points 5 months ago

My takeaway from that is that I should start putting canary bugs in my code 😆

[-] mox@lemmy.sdf.org 15 points 5 months ago

It's a time-honored tradition among dictionary publishers.

[-] ptz@dubvee.org 11 points 5 months ago

I think cartographers also used to put fake things on their maps to detect unauthorized copies.

[-] Ebber 8 points 5 months ago

There are cases where fake places became real since people moved there afterwards

[-] refalo@programming.dev 7 points 5 months ago

Doesn't really matter if you're not positioned to be able to defend your license in court.

[-] Knossos@lemmy.world 4 points 5 months ago

Some people really do :D

[-] Perhyte@lemmy.world 48 points 5 months ago

For MIT, why do you care? That's perfectly fine and explicitly allowed by the license. Same for Apache, but with a few extra requirements (like keeping a list of changes in the source code and preserving licensing information etc.).

As for how I know big corporations are using my code: the fact that a prominent project (publicly used by several tech giants) took a dependency on one of my tiny (permissively licensed) library packages is probably a clue.

[-] Ogeon@programming.dev 11 points 5 months ago

That's definitely part of "the deal" with MIT and Apache. The other end of it is that they shouldn't really expect to get anything more than what the authors are willing to give.

[-] 555_1@lemmy.world 10 points 5 months ago

So what you’re saying is you could take down an entire company by introducing a bug?

[-] emptyother@programming.dev 12 points 5 months ago

Or YOU could hack the company by stressing him about bugs and offer your help to fix them.

[-] Perhyte@lemmy.world 3 points 5 months ago

I don't think so, no.

Leaving aside the fact that I don't want to do that:

They've quite sensibly vendored my library, so I'd have to hope they pull in updates without checking the code changes: since it's such a tiny library (excluding tests but including fairly extensive comments, it's less than 100 lines of quite readable code) I don't think it'd be easy to get it past their code review system if I tried to sneak in enough code to take down entire companies.

Also, my GitHub account is tied to my real-world identity, so I'd probably be in a lot of trouble if I somehow succeeded.

[-] 555_1@lemmy.world 3 points 5 months ago

If it’s less than 100 lines, why on earth don’t they just put that in their own code?

[-] AnarchistArtificer@slrpnk.net 1 points 5 months ago

"vendored my library"

I'm unfamiliar with this phrase, are you able to explain what it means (or point me towards an explanation)? Is it relating to forking?

[-] maynarkh@feddit.nl 3 points 5 months ago

It means, at least in the golang world, that they keep a copy of your source for themselves and use it for builds. They don't pull from the public repo every time they build their stuff, so malicious code could only get in with new versions, but they check for that.

[-] Perhyte@lemmy.world 1 points 5 months ago

They've checked in my code in their own repository, using an automated tool that keeps track of its origin so they can still check for updates. (The build tool knows to check this directory before trying to pull in dependencies from elsewhere)

One benefit to them is that their build won't break if I decide to delete that specific repository (see also: the left-pad incident) or do silly things with version tags (deleting versions, or re-tagging a different commit with the same version number, that sort of thing).

But more relevantly for this thread, it also means that if I release a new version and they upgrade to it, the PR on their repository won't just be incrementing a version number in go.mod and adding an unreadable hash to go.sum: the diff will show all the changes I've made since the version they previously used.

[-] refalo@programming.dev 3 points 5 months ago

keeping a list of changes in the source code

Source?

[-] Perhyte@lemmy.world 4 points 5 months ago

I may have slightly misremembered the license text (subsection 4c):

You must cause any modified files to carry prominent notices stating that You changed the files;

So I guess technically you only need to indicate that you have changed the files, not what you've changed in them. I suppose that's less burdensome because it only needs to be done once per file at most.

[-] catch22@programming.dev 6 points 5 months ago* (last edited 5 months ago)

For MIT/Apache it doesn't matter. That's always a problem with those free to use licenses you have a "good idea" who's using it, but you never really can tell. It also creates a shit load of wasted improvements every time a company uses it, moth balls the project, but never pushes code upstream because why do that? \s So you sit back and hope that someone in the company feels a big enough moral drive or obligation to contribute their improvements up stream. But, how can you tell definitively? You can sometimes see it in the job descriptions they are hiring for, also I have had companies reach out out me personally for help. Many open source projects also will reach out and ask, and if they get the ok, will put it in the project description in order to encourage others companies to do the same. So why to companies bother? The funny thing about open source is that it lets people who like solving tough problems (the best type of engineers) know where the tough problems are being definitively solved, because here's the code, and here's the author from xyz company contributing and showing the rest of the world how it's done. Often this will bring in engineers who are at the top of their game to these companies.

this post was submitted on 22 Jun 2024
64 points (94.4% liked)

Programming

17314 readers
379 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 1 year ago
MODERATORS