How can I copy code from ReactOS to mingw-w64?

[Biswapriyo Nath]

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-3m…

[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?

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(a)reactos.org>
- Thomas Faber <thomas.faber(a)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

[LIU Hao]

在 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-…
[2] 
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/COPYING.MinGW-…



-- 
Best regards,
LIU Hao

[Thomas Faber]

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

[LIU Hao]

在 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.


-- 
Best regards,
LIU Hao

[Thomas Faber]

Change is made:
https://github.com/reactos/reactos/commit/be336316295278be728ea81156f77e24e…

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.
>  
>

[LIU Hao]

在 2022/3/16 10:58, Thomas Faber 写道:
>   Change is made:
>  https://github.com/reactos/reactos/commit/be336316295278be728ea81156f77e24e…
>  
>  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.


-- 
Best regards,
LIU Hao

[LIU Hao]

在 2022/3/16 10:58, Thomas Faber 写道:
>   Change is made:
>  https://github.com/reactos/reactos/commit/be336316295278be728ea81156f77e24e…
>  
>  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



-- 
Best regards,
LIU Hao

[Thomas Faber]

Hi again,

On 2022-03-17 00:00, LIU Hao wrote:
>   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[...]`? 
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.


>   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? 
I think this is a bug and we should indeed be calling the nothrow operator.


Best,
Thomas

[LIU Hao]

在 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.



-- 
Best regards,
LIU Hao