4 ms·

What I quoted is also from the README. You cannot use proprietary code in an open source project, and the README says you can. That is fundamentally dishonest.

What I quoted is also from the README. You cannot use proprietary code in an open source project, and the README says you can. That is fundamentally dishonest. The sum of MIT licensed code which requires linking to proprietary code to function is not an open source project. It is a proprietary project with an open-source part. You cannot use this in an open source project. Period. 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.

itishappy 2y ago
> The sum of MIT licensed code which requires linking to proprietary code to function is not an open source project. 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.
- samatman 2y ago
  > I don't think that's true or nothing compiled using MSVC could ever be open source. For example: Rust 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-stl/#:~:text=A%3A%20MSVC's%20STL%20is%20distributed,share%20code%20between%20our%20libraries 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-CLISP-is-under-GPL 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.
  - itishappy 2y ago
    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.
tazjin 2y ago
> You cannot use proprietary code in an open source project, and the README says you can. That is fundamentally dishonest. 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.
- prmph 2y ago
  You're misunderstanding the point made. Open source Windows and Mac apps do not _bundle_ Windows or Mac. To understand the argument, consider the difference between a runtime dependency and a peer dependency in Node.js.

itishappy 2y ago

> The sum of MIT licensed code which requires linking to proprietary code to function is not an open source project. 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.

samatman 2y ago
> I don't think that's true or nothing compiled using MSVC could ever be open source. For example: Rust 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-stl/#:~:text=A%3A%20MSVC's%20STL%20is%20distributed,share%20code%20between%20our%20libraries 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-CLISP-is-under-GPL 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.
- itishappy 2y ago
  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.

tazjin 2y ago

> You cannot use proprietary code in an open source project, and the README says you can. That is fundamentally dishonest. 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.

prmph 2y ago
You're misunderstanding the point made. Open source Windows and Mac apps do not _bundle_ Windows or Mac. To understand the argument, consider the difference between a runtime dependency and a peer dependency in Node.js.