841–850 of 1001 posts
Earlier quoted context omitted.
No license stops someone from spinning off an OSS project into their closed-sourced enterprise offering. It's just sad that most corps see nothing wrong with this
GPL definitely does.
Earlier quoted context omitted.
It still boggles my mind that people don't understand this. The FUD and misinformation that's been spreading about the GPL and the FSF the last decade almost seems like an intentional campaign brought on by exactly those who benefit from you using a "permissive" license the most.
The key is that "permissive" is passive voice. It's more permissive for corporations in that they are allowed to use it to tie their customers even tighter to them. Compare this with "restrictive" (for corporations) AKA "copyleft" which ensures that users' freedom is maintained, by restricting how corporations can limit them. It's very akin to the paradox of tolerance.
If you want them to contribute back changes, use a license that makes them contribute back changes, like GPL. Don’t ever “default to” a license.
This is not the first or last time this has happened. Microsoft does it intentionally and when they get caught they then give a fake apology and pretend it was a mistake. These mistakes keep happening and the pattern is always the same, MS teams engaging with a developer to learn all about their business idea and then they steal it: https://keivan.io/the-day-appget-died/
Earlier quoted context omitted.
The author didn't seem to request payment in monetary form but expected some kind of contributions back which would have helped both sides. It would probably be difficult to include some guarantees about upstream contributions into the license but interesting takeaway.
Doesn't that bring us right back to GPL family licenses?
Earlier quoted context omitted.
> And I want others to be able to remix what I make as needed. The more limitations added on a license, the less open it is. It's unintuitive, but permissive licenses are not the best way to acheive this. GPL's "limitations" are designed to maintain the right and abilty to remix code for the end user . So if say Microsoft forks your library and its fork becomes more popular, they can't make it proprietary after captu…
> So if say Microsoft forks your library and its fork becomes more popular, they can't make it proprietary after capturing the market and effectively stop people from remixing what you made. Neither can they stop people from such remixing if the project used a permissive license. The GP's project will still be there, still freely available for anyone to use however they see fit. Nobody is stopped from using it in any…
Hi Philip, I'm Lachlan from the Cloud Native Ecosystem team at Microsoft. Our team works in the cloud native open-source community with a goal of being great open-source collaborators in these projects and communities, and I’m sorry that this happened. We appreciate your leadership and collaboration on Spegel and see your project solving a real challenge for the cloud native community. I wanted to thank you for your…
Now that you got caught you are fixing it and writing fancy PR fluff. An org the size of MS should have clear policies and processes of how to handle open source forks like this. Unless we assume “bad faith” here. This is a pretty bad look. I wonder how many other projects are not attributed correctly. Are you checking up on them also or just waiting for the next HN post? That said, the author of Spegel should have u…
Earlier quoted context omitted.
To provide changes upstream, the maintainer must accept the change. Most opensource licenses are that you are required to publish your changes. But not upstream. As you wrote, there is no license that forces any "pull requests". The MIT license is the "easiest" license because there are no responsibility for the maintainer..
> Most opensource licenses are that you are required to publish your changes This isn't true either. You can privately fork AGPLv3 software without violating the license. You only have to provide the source (on demand!) to people who you provide the software to in executable form (where "executable form" includes network based access to the services executing the software in the case of the AGPL).
Meet for a week. Bring in one of their grey beards. Learn all our deets in anticipation of acquisition. Then silence...according to my understanding, not being privy to executive level discussions.
A bit later, release their own take on the problem area ... tragic.
It was very bad for us.
Earlier quoted context omitted.
[flagged]
Why you think that LLM-generated legal advise is worth posting on forum for humans?