3 ms·

These concerns apply to viral licenses like the GPL, not permissive such as MIT. Also, they only apply if you modify or distribute the software, which does not

These concerns apply to viral licenses like the GPL, not permissive such as MIT. Also, they only apply if you modify or distribute the software, which does not include running `cargo add lady-deirdre`. This is pointed out in the README and again in the EULA: > However, if you want to create an extension for my crate, you can develop a separate crate that uses my crate's public APIs through Cargo. In this case, you don't have to assign me your work, and you can distribute your project under any permissive license, such as the MIT license. > For the purposes of this Agreement, third-party works that remain separable from the Work, that use the application programming interfaces (APIs) of the Work only, and that do not copy, distribute, display, or sell the Work or any part of the Work to third parties in source or compiled form, shall not be considered "Derivative Work." I am not a lawyer so I reached out to one about this particular repository. She says you'd be fine using the MIT license for your code. (I'd still talk to your own lawyer first if you're uncomfortable.) > Be sure to pin the cargo version of your proprietary-by-inclusion otherwise-MIT not-open-source project to the current version If you don't want to call MIT-licensed code open-source, that's an interesting argument, but not one I view it's fair to accuse the developer of lying over.

prmph 2y ago
I agree with samatman. In what way can a work that has a proprietary work bundled in be called open source? It is different if the the work has a _peer_ dependency on the proprietary work. As it is, I seriously doubt that anyone wanting a quicker way to implement a language will use this; why would I want to hamper adoption of my language by hobbling it with such a license?
samatman 2y ago
You're reading the virality backward. As I said, the MIT licensed part of the code remains MIT licensed. But the project is not an open source project. There's lots of MIT licensed code in proprietary software, it's one of the things that the license allows. Similarly, a GPL licensed project can always include any amount of MIT, because one of the things you can do with MIT code is relicense it as GPL: the original license still applies, but the whole project is now GPL. But a project which cannot even compile without a proprietary library is a proprietary project. Not an open-source one. macOS is a proprietary operating system with many open source components. A language using Lady Diedre would be no different.

prmph 2y ago

I agree with samatman. In what way can a work that has a proprietary work bundled in be called open source? It is different if the the work has a _peer_ dependency on the proprietary work. As it is, I seriously doubt that anyone wanting a quicker way to implement a language will use this; why would I want to hamper adoption of my language by hobbling it with such a license?

samatman 2y ago

You're reading the virality backward. As I said, the MIT licensed part of the code remains MIT licensed. But the project is not an open source project. There's lots of MIT licensed code in proprietary software, it's one of the things that the license allows. Similarly, a GPL licensed project can always include any amount of MIT, because one of the things you can do with MIT code is relicense it as GPL: the original license still applies, but the whole project is now GPL. But a project which cannot even compile without a proprietary library is a proprietary project. Not an open-source one. macOS is a proprietary operating system with many open source components. A language using Lady Diedre would be no different.