On Monday 14 June 2010 01:00 Leandro Lucarella wrote:
> Benjamin Shropshire, el 13 de junio a las 13:30 me escribiste:
> > Brad Roberts wrote:
> > >The problem with incorporating fixes from other sources is the same as for source code, the license they're under.  DStress has never made that clear, though it's intention is very clear.
> > 
> > IIRC some big swaths of DStress are explicitly linked to bug numbers. Either derived from code in the bug to written explicitly to show a specific bug. I wonder if the author of DStress (is he still around?) would, at a minimum, place /them/ under some acceptable license (or even public domain).
> 
> The original author was Thomas K?hne, I think now it's maintained by Christian Kamm (Cc'ed). Maybe he knows how to contact Thomas to ask him for details about the license. And I guess Christian could tell a little more about LDC's test suite too.

Hi all,

I've tried to contact Thomas before moving dstress to a public repository but didn't get a reply. I had spoken to other people at the time, but no one seemed to be able to get in contact with him.

Dstress' license.txt says GPL v2.

LDC's mini tests are currently under the same license as LDC itself: BSD.

Christian

Brad Roberts, el 13 de junio a las 17:23 me escribiste:
> On 6/13/2010 1:30 PM, Benjamin Shropshire wrote:
> > Brad Roberts wrote:
> >> The problem with incorporating fixes from other sources is the same as
> >> for
> >> source code, the license they're under.  DStress has never made that
> >> clear,
> >> though it's intention is very clear.
> >> 
> > 
> > IIRC some big swaths of DStress are explicitly linked to bug numbers. Either derived from code in the bug to written explicitly to show a specific bug. I wonder if the author of DStress (is he still around?) would, at a minimum, place /them/ under some acceptable license (or even public domain).
> 
> Yes, many are either directly in bugzilla or linked from it.  Since dstress is gpl v2 (see other email on this thread)

What issues do you find in using some test cases with GPL license in a test suite?

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
El techo de mi cuarto lleno de planetas
Y mi mente es un planeta m?s
Donde vivo yo y nadie podr? entrar
Jam?s

On 6/14/2010 6:02 AM, Leandro Lucarella wrote:
> Brad Roberts, el 13 de junio a las 17:23 me escribiste:
>> On 6/13/2010 1:30 PM, Benjamin Shropshire wrote:
>>> Brad Roberts wrote:
>>>> The problem with incorporating fixes from other sources is the same as
>>>> for
>>>> source code, the license they're under.  DStress has never made that
>>>> clear,
>>>> though it's intention is very clear.
>>>> 
>>>
>>> IIRC some big swaths of DStress are explicitly linked to bug numbers. Either derived from code in the bug to written explicitly to show a specific bug. I wonder if the author of DStress (is he still around?) would, at a minimum, place /them/ under some acceptable license (or even public domain).
>>
>> Yes, many are either directly in bugzilla or linked from it.  Since dstress is gpl v2 (see other email on this thread)
> 
> What issues do you find in using some test cases with GPL license in a test suite?
> 

I really don't want to have tests under various licenses.  It's overly confusing.

Brad Roberts, el 14 de junio a las 10:16 me escribiste:
> On 6/14/2010 6:02 AM, Leandro Lucarella wrote:
> > Brad Roberts, el 13 de junio a las 17:23 me escribiste:
> >> On 6/13/2010 1:30 PM, Benjamin Shropshire wrote:
> >>> Brad Roberts wrote:
> >>>> The problem with incorporating fixes from other sources is the same as
> >>>> for
> >>>> source code, the license they're under.  DStress has never made that
> >>>> clear,
> >>>> though it's intention is very clear.
> >>>> 
> >>>
> >>> IIRC some big swaths of DStress are explicitly linked to bug numbers. Either derived from code in the bug to written explicitly to show a specific bug. I wonder if the author of DStress (is he still around?) would, at a minimum, place /them/ under some acceptable license (or even public domain).
> >>
> >> Yes, many are either directly in bugzilla or linked from it.  Since dstress is gpl v2 (see other email on this thread)
> > 
> > What issues do you find in using some test cases with GPL license in a test suite?
> > 
> 
> I really don't want to have tests under various licenses.  It's overly confusing.

Confusing how? For test cases there are no issues as with the standard library, which will be included in every (commercial) product compiled with DMD and *must* have a rally permissive license.

You just need to be able to use and modify the tests, that's it. I think
it's a shame to discard a *lot* of good tests, with a license that is
more than sufficient for what is required just because, well, it's
"confusing". I can't even see where can it be any confusion, maybe
a little more maintenance work, but really, a simple line in each
file with License: BSD/GPL/Boost/whatever is enough. Write one, don't
care again ever! =)

If you decide not to include test with a license different from Boost (or whatever you like), I hope it has a real good rationale behind and is not just some allergy to GPL or some reflex from the traumatic Phobos license change =P

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Yeah, I'm a great quitter. It's one of the few things I do well. I come from a
long line of quitters. My father was a quitter, my grandfather was a quitter...
I was raised to give up.
	-- George Constanza

On Mon, 14 Jun 2010, Leandro Lucarella wrote:

> Brad Roberts, el 14 de junio a las 10:16 me escribiste:
> > On 6/14/2010 6:02 AM, Leandro Lucarella wrote:
> > > Brad Roberts, el 13 de junio a las 17:23 me escribiste:
> > >> On 6/13/2010 1:30 PM, Benjamin Shropshire wrote:
> > >>> Brad Roberts wrote:
> > >>>> The problem with incorporating fixes from other sources is the same as
> > >>>> for
> > >>>> source code, the license they're under.  DStress has never made that
> > >>>> clear,
> > >>>> though it's intention is very clear.
> > >>>> 
> > >>>
> > >>> IIRC some big swaths of DStress are explicitly linked to bug numbers. Either derived from code in the bug to written explicitly to show a specific bug. I wonder if the author of DStress (is he still around?) would, at a minimum, place /them/ under some acceptable license (or even public domain).
> > >>
> > >> Yes, many are either directly in bugzilla or linked from it.  Since dstress is gpl v2 (see other email on this thread)
> > > 
> > > What issues do you find in using some test cases with GPL license in a test suite?
> > > 
> > 
> > I really don't want to have tests under various licenses.  It's overly confusing.
> 
> Confusing how? For test cases there are no issues as with the standard library, which will be included in every (commercial) product compiled with DMD and *must* have a rally permissive license.
> 
> You just need to be able to use and modify the tests, that's it. I think
> it's a shame to discard a *lot* of good tests, with a license that is
> more than sufficient for what is required just because, well, it's
> "confusing". I can't even see where can it be any confusion, maybe
> a little more maintenance work, but really, a simple line in each
> file with License: BSD/GPL/Boost/whatever is enough. Write one, don't
> care again ever! =)
> 
> If you decide not to include test with a license different from Boost (or whatever you like), I hope it has a real good rationale behind and is not just some allergy to GPL or some reflex from the traumatic Phobos license change =P

The test style for dmd is many tests per file.  To merge in dstress tests with a different license would by that nature result in different blocks of code within the same file falling under different licenses?  No, not going to happen.

So, that leaves the option of drawing a license barrier between files. That's certainly better, but also is far from ideal, imho.

All that said, there's a last reason that's not been discussed in this thread yet which is redundancy between the suites.  It'd be stupid to just squish them together and celebrate.  MANY of the tests are redundant. Determining which are and which aren't.. sigh.

Obviously any test that fails in dstress (or the ldc suite) against current dmd isn't covered by the dmd test suite (since it passes 100%.. being one of the primary release criteria for all dmd releases).  THOSE are clearly worth adding.  I expect most (and would hope all, but I'm not that stupid) of those are also in bugzilla, which has a clear public domain label on all submissions.


You're right in that we shouldn't raise license concerns needlessly, but neither should we proceed recklessly.  The DMD bundle is already a mess with respect to multiple licenses (parts non-redistributable (backend), parts redistributable under two licenses (artistic and gplv1)(frontend)). I don't know that it's a problem to mix gpl2 into that mess, but I'd prefer not to find out if it can be avoided.

So.. considering the above.  The question left in my mind is:

Is there enough value in digging out tests in dstress that aren't in bugzilla attached to yet-to-be-fixed-bugs that it's worth both accepting multiple licenses on the tests and actually going through the effort to dig out those tests?

My gut tells me no, but, please, keep trying to convince me I'm wrong.

The irony (agony?) here is that if Thomas were still around, I suspect he'd say 'do what ever you want with them'.

Later,
Brad

Brad Roberts wrote:
> On Mon, 14 Jun 2010, Leandro Lucarella wrote:
>
> 
>> Brad Roberts, el 14 de junio a las 10:16 me escribiste:
>> 
>>> On 6/14/2010 6:02 AM, Leandro Lucarella wrote:
>>> 
>>>> Brad Roberts, el 13 de junio a las 17:23 me escribiste:
>>>> 
>>>>> On 6/13/2010 1:30 PM, Benjamin Shropshire wrote:
>>>>> 
>>>>>> Brad Roberts wrote:
>>>>>> 
>>>>>>> The problem with incorporating fixes from other sources is the same as
>>>>>>> for
>>>>>>> source code, the license they're under.  DStress has never made that
>>>>>>> clear,
>>>>>>> though it's intention is very clear.
>>>>>>> 
>>>>>>> 
>>>>>> IIRC some big swaths of DStress are explicitly linked to bug numbers.
>>>>>> Either derived from code in the bug to written explicitly to show a
>>>>>> specific bug. I wonder if the author of DStress (is he still around?)
>>>>>> would, at a minimum, place /them/ under some acceptable license (or even
>>>>>> public domain).
>>>>>> 
>>>>> Yes, many are either directly in bugzilla or linked from it.  Since dstress is
>>>>> gpl v2 (see other email on this thread)
>>>>> 
>>>> What issues do you find in using some test cases with GPL license in a test suite?
>>>>
>>>> 
>>> I really don't want to have tests under various licenses.  It's overly
>>> confusing.
>>> 
>> Confusing how? For test cases there are no issues as with the standard library, which will be included in every (commercial) product compiled with DMD and *must* have a rally permissive license.
>>
>> You just need to be able to use and modify the tests, that's it. I think
>> it's a shame to discard a *lot* of good tests, with a license that is
>> more than sufficient for what is required just because, well, it's
>> "confusing". I can't even see where can it be any confusion, maybe
>> a little more maintenance work, but really, a simple line in each
>> file with License: BSD/GPL/Boost/whatever is enough. Write one, don't
>> care again ever! =)
>>
>> If you decide not to include test with a license different from Boost
>> (or whatever you like), I hope it has a real good rationale behind and
>> is not just some allergy to GPL or some reflex from the traumatic Phobos
>> license change =P
>> 
>
> The test style for dmd is many tests per file.  To merge in dstress tests with a different license would by that nature result in different blocks of code within the same file falling under different licenses?  No, not going to happen.
>
> So, that leaves the option of drawing a license barrier between files. That's certainly better, but also is far from ideal, imho.
>
> All that said, there's a last reason that's not been discussed in this thread yet which is redundancy between the suites.  It'd be stupid to just squish them together and celebrate.  MANY of the tests are redundant. Determining which are and which aren't.. sigh.
>
> Obviously any test that fails in dstress (or the ldc suite) against current dmd isn't covered by the dmd test suite (since it passes 100%.. being one of the primary release criteria for all dmd releases).  THOSE are clearly worth adding.  I expect most (and would hope all, but I'm not that stupid) of those are also in bugzilla, which has a clear public domain label on all submissions.
>
>
> You're right in that we shouldn't raise license concerns needlessly, but neither should we proceed recklessly.  The DMD bundle is already a mess with respect to multiple licenses (parts non-redistributable (backend), parts redistributable under two licenses (artistic and gplv1)(frontend)). I don't know that it's a problem to mix gpl2 into that mess, but I'd prefer not to find out if it can be avoided.
>
> So.. considering the above.  The question left in my mind is:
>
> Is there enough value in digging out tests in dstress that aren't in bugzilla attached to yet-to-be-fixed-bugs that it's worth both accepting multiple licenses on the tests and actually going through the effort to dig out those tests?
>
> My gut tells me no, but, please, keep trying to convince me I'm wrong.
>
> The irony (agony?) here is that if Thomas were still around, I suspect
> he'd say 'do what ever you want with them'.
> 

Then merge the GPL test into one file (gpl.d?) and put the non-GPL in another. It's not "one big test" is it?

On Mon, 14 Jun 2010, Benjamin Shropshire wrote:

> > The test style for dmd is many tests per file.  To merge in dstress tests with a different license would by that nature result in different blocks of code within the same file falling under different licenses?  No, not going to happen.
> > 
> > So, that leaves the option of drawing a license barrier between files. That's certainly better, but also is far from ideal, imho.
> > 
> > All that said, there's a last reason that's not been discussed in this thread yet which is redundancy between the suites.  It'd be stupid to just squish them together and celebrate.  MANY of the tests are redundant. Determining which are and which aren't.. sigh.
> > 
> > Obviously any test that fails in dstress (or the ldc suite) against current dmd isn't covered by the dmd test suite (since it passes 100%.. being one of the primary release criteria for all dmd releases).  THOSE are clearly worth adding.  I expect most (and would hope all, but I'm not that stupid) of those are also in bugzilla, which has a clear public domain label on all submissions.
> > 
> > 
> > You're right in that we shouldn't raise license concerns needlessly, but
> > neither should we proceed recklessly.  The DMD bundle is already a mess with
> > respect to multiple licenses (parts non-redistributable (backend), parts
> > redistributable under two licenses (artistic and gplv1)(frontend)).
> > I don't know that it's a problem to mix gpl2 into that mess, but I'd prefer
> > not to find out if it can be avoided.
> > So.. considering the above.  The question left in my mind is:
> > 
> > Is there enough value in digging out tests in dstress that aren't in bugzilla attached to yet-to-be-fixed-bugs that it's worth both accepting multiple licenses on the tests and actually going through the effort to dig out those tests?
> > 
> > My gut tells me no, but, please, keep trying to convince me I'm wrong.
> > 
> > The irony (agony?) here is that if Thomas were still around, I suspect he'd
> > say 'do what ever you want with them'.
> > 
> 
> Then merge the GPL test into one file (gpl.d?) and put the non-GPL in another. It's not "one big test" is it?

You seem to have read approximately only the first two paragraphs of the email.  Any comments on the rest?

Brad Roberts wrote:
> On Mon, 14 Jun 2010, Benjamin Shropshire wrote:
>
> 
>>> The test style for dmd is many tests per file.  To merge in dstress tests with a different license would by that nature result in different blocks of code within the same file falling under different licenses?  No, not going to happen.
>>>
>>> So, that leaves the option of drawing a license barrier between files. That's certainly better, but also is far from ideal, imho.
>>>
>>> All that said, there's a last reason that's not been discussed in this thread yet which is redundancy between the suites.  It'd be stupid to just squish them together and celebrate.  MANY of the tests are redundant. Determining which are and which aren't.. sigh.
>>>
>>> Obviously any test that fails in dstress (or the ldc suite) against current dmd isn't covered by the dmd test suite (since it passes 100%.. being one of the primary release criteria for all dmd releases).  THOSE are clearly worth adding.  I expect most (and would hope all, but I'm not that stupid) of those are also in bugzilla, which has a clear public domain label on all submissions.
>>>
>>>
>>> You're right in that we shouldn't raise license concerns needlessly, but
>>> neither should we proceed recklessly.  The DMD bundle is already a mess with
>>> respect to multiple licenses (parts non-redistributable (backend), parts
>>> redistributable under two licenses (artistic and gplv1)(frontend)).
>>> I don't know that it's a problem to mix gpl2 into that mess, but I'd prefer
>>> not to find out if it can be avoided.
>>> So.. considering the above.  The question left in my mind is:
>>>
>>> Is there enough value in digging out tests in dstress that aren't in bugzilla attached to yet-to-be-fixed-bugs that it's worth both accepting multiple licenses on the tests and actually going through the effort to dig out those tests?
>>>
>>> My gut tells me no, but, please, keep trying to convince me I'm wrong.
>>>
>>> The irony (agony?) here is that if Thomas were still around, I suspect he'd
>>> say 'do what ever you want with them'.
>>> 
>>> 
>> Then merge the GPL test into one file (gpl.d?) and put the non-GPL in another.
>> It's not "one big test" is it?
>> 
>
> You seem to have read approximately only the first two paragraphs of the email.  Any comments on the rest?
>
> 

Darn tiny net-book screen must have ended at a paragraph gap :(

That said, I don't have much of an opinion on it any way: 1) INAL but I don't think there would be any more problems hosting code with different licenses in the same repo than there would be on the same host and 2) if it were up to me I'd stuff all of them in, maybe moving the ones that dstress ones that pass into a "fulltest" target so they can be skip most of the time.

Brad Roberts, el 14 de junio a las 19:10 me escribiste:
> On Mon, 14 Jun 2010, Leandro Lucarella wrote:
> 
> > Brad Roberts, el 14 de junio a las 10:16 me escribiste:
> > > On 6/14/2010 6:02 AM, Leandro Lucarella wrote:
> > > > Brad Roberts, el 13 de junio a las 17:23 me escribiste:
> > > >> On 6/13/2010 1:30 PM, Benjamin Shropshire wrote:
> > > >>> Brad Roberts wrote:
> > > >>>> The problem with incorporating fixes from other sources is the same as
> > > >>>> for
> > > >>>> source code, the license they're under.  DStress has never made that
> > > >>>> clear,
> > > >>>> though it's intention is very clear.
> > > >>>> 
> > > >>>
> > > >>> IIRC some big swaths of DStress are explicitly linked to bug numbers. Either derived from code in the bug to written explicitly to show a specific bug. I wonder if the author of DStress (is he still around?) would, at a minimum, place /them/ under some acceptable license (or even public domain).
> > > >>
> > > >> Yes, many are either directly in bugzilla or linked from it.  Since dstress is gpl v2 (see other email on this thread)
> > > > 
> > > > What issues do you find in using some test cases with GPL license in a test suite?
> > > > 
> > > 
> > > I really don't want to have tests under various licenses.  It's overly confusing.
> > 
> > Confusing how? For test cases there are no issues as with the standard library, which will be included in every (commercial) product compiled with DMD and *must* have a rally permissive license.
> > 
> > You just need to be able to use and modify the tests, that's it. I think
> > it's a shame to discard a *lot* of good tests, with a license that is
> > more than sufficient for what is required just because, well, it's
> > "confusing". I can't even see where can it be any confusion, maybe
> > a little more maintenance work, but really, a simple line in each
> > file with License: BSD/GPL/Boost/whatever is enough. Write one, don't
> > care again ever! =)
> > 
> > If you decide not to include test with a license different from Boost (or whatever you like), I hope it has a real good rationale behind and is not just some allergy to GPL or some reflex from the traumatic Phobos license change =P
> 
> The test style for dmd is many tests per file.  To merge in dstress tests with a different license would by that nature result in different blocks of code within the same file falling under different licenses?  No, not going to happen.
> 
> So, that leaves the option of drawing a license barrier between files. That's certainly better, but also is far from ideal, imho.

Another option to explore is to make all tests GPL, AFAIK you can relicense every permissive license to a more restrictive one (but I'm not sure). Here is a list of GPL-compatible licenses: http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses

And even if that's not possible, as Benjamin said, it's not so bad to have one file with multiple tests for each license.

> All that said, there's a last reason that's not been discussed in this thread yet which is redundancy between the suites.  It'd be stupid to just squish them together and celebrate.  MANY of the tests are redundant. Determining which are and which aren't.. sigh.

Of course, I wasn't suggesting to just blindly drop dstress into the new DMD test directory. I think there even might be some incorrect test in dstress. But I was resuming a tedious work of selecting the test for the private test suite and extracting bugzilla tests anyways =)

And I'm not sure if is more or less work writing new test than analyzing existing ones (seeing if they are redundant).

> Obviously any test that fails in dstress (or the ldc suite) against current dmd isn't covered by the dmd test suite (since it passes 100%.. being one of the primary release criteria for all dmd releases).  THOSE are clearly worth adding.  I expect most (and would hope all, but I'm not that stupid) of those are also in bugzilla, which has a clear public domain label on all submissions.
> 
> You're right in that we shouldn't raise license concerns needlessly, but neither should we proceed recklessly.

Then we completely agree =)

> The DMD bundle is already a mess with respect to multiple licenses
> (parts non-redistributable (backend), parts redistributable under two
> licenses (artistic and gplv1)(frontend)).  I don't know that it's
> a problem to mix gpl2 into that mess, but I'd prefer not to find out
> if it can be avoided.

If you don't import or link tests with different licenses, there is no problem at all. That's for sure. Is like having an FTP with the sources of 2 programs, one GPL and one BSD/Boost. Not a problem at all. Even more, as I said at the begining, many of the licenses used are GPL-compatible. The only one is not is Artistic (and the backend, of course), but the front-end is GPL too, so no problem there. But anyways, you are not importing or linking code from the test suite in the backend or frontend, you are only importing and linking code from Phobos into the test suite, and Boost is GPL-compatible, so again, no license issues there.

> So.. considering the above.  The question left in my mind is:
> 
> Is there enough value in digging out tests in dstress that aren't in bugzilla attached to yet-to-be-fixed-bugs that it's worth both accepting multiple licenses on the tests and actually going through the effort to dig out those tests?

That is a good question, and I think the only valid concern about using other test suites. Because I see no licensing issues at all.

> My gut tells me no, but, please, keep trying to convince me I'm wrong.

I hope I convinced you about the non-existence of licensing issues, convincing you about this would be much harder ;)

I'm fine knowing the possibility of adding test from dstress or LDC exists if it has value to do so. My real concern was discarding those test just because of some unfounded fear to GPL =)

I guess there is a *lot* of work to do with just the private test suite and bugzilla, so there will be time to see it dstress and LDC test worth the selection process.

> The irony (agony?) here is that if Thomas were still around, I suspect he'd say 'do what ever you want with them'.

Again, I think that the less significant issue about adding (or not) dstress tests. Certainly that's not a problem with LDC test suite.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
ASALTAN, GOLPEAN SALVAJEMENTE A ANCIANA Y LE COMEN LA PASTAFROLA.
	-- Cr?nica TV

On 15 June 2010 15:24, Leandro Lucarella <luca at llucax.com.ar> wrote:
> Brad Roberts, el 14 de junio a las 19:10 me escribiste:
>> All that said, there's a last reason that's not been discussed in this thread yet which is redundancy between the suites. ?It'd be stupid to just squish them together and celebrate. ?MANY of the tests are redundant. Determining which are and which aren't.. sigh.
>
> Of course, I wasn't suggesting to just blindly drop dstress into the new DMD test directory. I think there even might be some incorrect test in dstress. But I was resuming a tedious work of selecting the test for the private test suite and extracting bugzilla tests anyways =)

A pretty large fraction of the still-failing dstress tests are
incorrect (primarily because there are a very large number of tests
which correspond to a single, invalid bugzilla bug)
I don't know the early history of DMD + dstress, but I suspect there
are very few tests which pass, which aren't already in the internal
test suite.
I think it'd be more useful to go through dstress and check that every
failing test has a corresponding open bugzilla bug.