3 ms·
As a general rule, any project that mixes proprietary software in an "open source" repo (like the cal.com example) is a potential landmine. You have to be extr
by TAForObvReasons 4y ago
As a general rule, any project that mixes proprietary software in an "open source" repo (like the cal.com example) is a potential landmine. You have to be extra careful if you try to re-implement a proprietary feature since cloning the repo necessarily pulls in the proprietary bits. It's better to treat the projects as if they are proprietary,
- ssddanbrown 4y agoAbsolutely. With that cal.com example it took me quite a while to check that (by my own interpretation) a fork/clone won't instantly be against their license terms since the legal-writing can be hard to fully interpret. In addition, this is not mentioned in the `License` section of the readme, you're required to dig down a layer.
- rathboma 4y agoAs an open source project maintainer [1] with a set of proprietary add-ons, I totally understand the project maintainer desire to have a single repository with a single version, single build system, and a single place for issues. I've considered doing the same thing, but it's all the legal complexity that stops me, doesn't seem worth it. [1]: https://github.com/beekeeper-studio/beekeeper-studio https://github.com/beekeeper-studio/beekeeper-studio
- ssddanbrown 4y agoFor sure, In my opinion I think this is totally fine as long as it's clearly specified in the likely first point of contact (Generally the readme on GitHub) & license file and as long as the other licenses aren't breached upon clone/download of the source alone, potentially acting as a license trap.