> This work is proprietary software with source-available code.
> To copy, use, distribute, and contribute to this work, you must agree to the terms and conditions of the General License Agreement.
It's pretty clear on the rights granted:
> Please be aware that my work is proprietary software, intended for solo development. For this reason, the agreement requires you to automatically assign me the changes you make to my project's source code.
> 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.
These quotes are all pulled from the readme, and the last edit was 5 hours before your comment. Where's the lie?
Making that section of the FAQ honest would look like this:
> Can I use Lady Diedre in an Open Source project?
> No. Lady Diedre is not available via an open source license.
> Can I use it in a noncommercial publicly-available project?
> For now. The EULA clearly reserves my right to change the terms at any time, so if that risk is acceptable to you, you have my temporary permission to do so, subject to revocation at any time and without notice.
I don't think that's true or nothing compiled using MSVC could ever be open source. For example: Rust.
> For now. The EULA clearly reserves my right to change the terms at any time, so if that risk is acceptable to you, you have my temporary permission to do so, subject to revocation at any time and without notice.
Terms can be changed at any time, but you do not have to accept them. From the EULA:
> You are not obligated to accept any new terms or amendments. In such a case, this Agreement will continue to govern your use of the Work you have already accessed under the original terms. However, if you do not accept the new terms or amendments, you will not be permitted to use any new versions, updates, upgrades, or modifications to the Work.
It is true. Rust does not require MSVC in order to compile. Also, linking to proprietary code, and compiling code using a proprietary binary, are completely different things. A distribution of Rust which contained a proprietary library would not be open source, but that's entirely allowed, because Rust's license isn't viral.
As it happens, the linkable portion of MSVC is Apache 2.0:
https://devblogs.microsoft.com/cppblog/open-sourcing-msvcs-s....
This is so that open-source software which requires MSVC framework remains open source.
Please see this classic thread for more details:
https://gitlab.com/gnu-clisp/clisp/-/blob/master/doc/Why-CLI...
I'm not opposed to proprietary software, and as long as people clearly understand what they're getting into, they should make their own choices about using Lady Diedre. But the FAQ is dishonest, and I have a problem with that.
> You are not obligated to accept any new terms or amendments. In such a case, this Agreement will continue to govern your use of the Work you have already accessed under the original terms. However, if you do not accept the new terms or amendments, you will not be permitted to use any new versions, updates, upgrades, or modifications to the Work.
Great. Be sure to pin the cargo version of your proprietary-by-inclusion otherwise-MIT not-open-source project to the current version, because otherwise you might link an update without checking the EULA, and now you can be sued over it.
> 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.
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.
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?
That doesn't make any sense. There's plenty of open-source Windows/Mac apps, but they don't give you access to Windows/Mac OS itself.
To understand the argument, consider the difference between a runtime dependency and a peer dependency in Node.js.