I want to copy two functions ConvertStringToBSTR and ConvertBSTRToString to mingw-w64 to create a comsupp library. But there is something about license which prevents the addition. How can I copy the code without any issue? Please see this[1] thread in mingw-w64 mailing list.
[1]: https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/CALK-3mL...
Hello mingw-w64 fellows,
I want to copy two functions ConvertStringToBSTR and ConvertBSTRToString to mingw-w64 to create a comsupp library. But there is something about license which prevents the addition. How can I copy the code without any issue?
What license would be acceptable to you? MIT? BSD? Or does it even need to be CC0?
We have a history of cooperating and relicensing code when it makes sense. In this case, a quick look into the git history of commsupp.cpp (with the --follow option) reveals that the copyright of this file is exclusively held by:
- Hermès Bélusca-Maïto hermes.belusca-maito@reactos.org - Thomas Faber thomas.faber@reactos.org
Even though commsupp.cpp is almost a decade old, both developers are still active in the ReactOS Project. If you say what license suits you, we could open a PR to publicly relicense commsupp.cpp and ask Hermès and Thomas for approval.
Best regards,
Colin Finck
在 2022-03-13 18:35, Colin Finck 写道:
Hello mingw-w64 fellows,
I want to copy two functions ConvertStringToBSTR and ConvertBSTRToString to mingw-w64 to create a comsupp library. But there is something about license which prevents the addition. How can I copy the code without any issue?
What license would be acceptable to you? MIT? BSD? Or does it even need to be CC0?
This comsupp thing isn't going to be part of the runtime, because it isn't linked into executables unless it is referenced by user code. However the runtime license applies anyway [1].
The runtime part is licensed under the Zope License [2], so I suspect it is an option. Some source files, such as 'scardssp_i.c', have explicit notices like 'This file has no copyright assigned and is placed in the Public Domain.' so CC0 should be OK too, if Zope isn't an option for you.
[1] https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/COPYING.MinGW-w... [2] https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/COPYING.MinGW-w...
Hi,
On 2022-03-13 09:34, LIU Hao wrote:
在 2022-03-13 18:35, Colin Finck 写道:
I want to copy two functions ConvertStringToBSTR and ConvertBSTRToString to mingw-w64 to create a comsupp library. But there is something about license which prevents the addition. How can I copy the code without any issue?
What license would be acceptable to you? MIT? BSD? Or does it even need to be CC0?
The runtime part is licensed under the Zope License [2], so I suspect it is an option. Some source files, such as 'scardssp_i.c', have explicit notices like 'This file has no copyright assigned and is placed in the Public Domain.' so CC0 should be OK too, if Zope isn't an option for you.
Not thrilled about a relatively obscure license like Zope, but it sounds like it's BSD + extra restrictions; I'd be fine with BSD. Do you think that would work for you?
Hermès seems to feel similarly, but if BSD is not good enough, we could probably agree on CC0.
Best, Thomas
在 2022/3/15 10:30, Thomas Faber 写道:
Not thrilled about a relatively obscure license like Zope, but it sounds like it's BSD + extra restrictions; I'd be fine with BSD. Do you think that would work for you?
Hermès seems to feel similarly, but if BSD is not good enough, we could probably agree on CC0.
BSD is okay. We shall also include a chapter, both in the source file and in COPYING.MinGW-w64.txt.
Change is made: https://github.com/reactos/reactos/commit/be336316295278be728ea81156f77e24e7...
Let us know if there's anything else we can help with.
Best, Thomas
On 2022-03-15 01:12, LIU Hao wrote:
在 2022/3/15 10:30, Thomas Faber 写道:
Not thrilled about a relatively obscure license like Zope, but it sounds like it's BSD + extra restrictions; I'd be fine with BSD. Do you think that would work for you?
Hermès seems to feel similarly, but if BSD is not good enough, we could probably agree on CC0.
BSD is okay. We shall also include a chapter, both in the source file and in COPYING.MinGW-w64.txt.
在 2022/3/16 10:58, Thomas Faber 写道:
Change is made: https://github.com/reactos/reactos/commit/be336316295278be728ea81156f77e24e7...
Let us know if there's anything else we can help with.
Thank you. We can take this one.
Biswapriyo, please update the patch accordingly, including the copyright notice from the updated source file. There need be a section in COPYING.MinGW-w64.txt too.
在 2022/3/16 10:58, Thomas Faber 写道:
Change is made: https://github.com/reactos/reactos/commit/be336316295278be728ea81156f77e24e7...
Let us know if there's anything else we can help with.
While examining the `ConvertBSTRToString()` function, I noticed some issues in it. (I am not sure whether this is a correct place to ask, but I decide not to cross post.)
1) According to MS docs [1], `ConvertBSTRToString()` returns a string that the user must delete via `delete[]`, so why is the returned buffer allocated via `::operator new()`, instead of `new char[...]`?
2) `::operator new()` throws an exception on failure and never returns a null pointer. This makes the null check about its return value unnecessary. Is it supposed to be `::new(::std::nothrow) char[...]`? Or do we ignore such circumstances?
[1] https://docs.microsoft.com/en-us/cpp/cpp/convertbstrtostring?view=msvc-170
Hi again,
On 2022-03-17 00:00, LIU Hao wrote:
- According to MS docs [1], `ConvertBSTRToString()` returns a string
that the user must delete via `delete[]`, so why is the returned buffer allocated via `::operator new()`, instead of `new char[...]`?
I think this only makes a difference in terms of how constructors/destructors are called, so shouldn't matter for an array of chars. I'm not sure whether there's any particular advantage here to calling the operator directly rather than the more obvious new[]. So it could make sense to change it.
- `::operator new()` throws an exception on failure and never returns
a null pointer. This makes the null check about its return value unnecessary. Is it supposed to be `::new(::std::nothrow) char[...]`? Or do we ignore such circumstances?
I think this is a bug and we should indeed be calling the nothrow operator.
Best, Thomas
在 2022-04-09 22:23, Thomas Faber 写道:
I think this only makes a difference in terms of how constructors/destructors are called, so shouldn't matter for an array of chars. I'm not sure whether there's any particular advantage here to calling the operator directly rather than the more obvious new[]. So it could make sense to change it.
Thanks for the feedback.
It's just that `delete[]`'d memory should have been allocated by `new[]`, and `free()`'d memory should have been alllocated by `{m,c,re}alloc()` etc. It may work by accident, but is nevertheless undefined behavior.
It is still uncertain that whether we should incorporate this piece of C++ code into mingw-w64 headers as inline functions, or as a separate library. Anyway your work shall be appreciated.
-
Biswapriyo Nath -
Colin Finck -
LIU Hao -
Thomas Faber