[PATCH v2 3/3] ttest01: New test
gedare at rtems.org
Wed Oct 2 17:48:26 UTC 2019
On Tue, Oct 1, 2019 at 10:52 PM Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> On 01/10/2019 23:40, Gedare Bloom wrote:
> >> +/*
> >> + * SPDX-License-Identifier: BSD-2-Clause
> >> + * SPDX-License-Identifier: CC-BY-SA-4.0
> >> + *
> >> + * Copyright (C) 2018, 2019 embedded brains GmbH
> >> + *
> >> + * Redistribution and use in source and binary forms, with or without
> >> + * modification, are permitted provided that the following conditions
> >> + * are met:
> >> + * 1. Redistributions of source code must retain the above copyright
> >> + * notice, this list of conditions and the following disclaimer.
> >> + * 2. Redistributions in binary form must reproduce the above copyright
> >> + * notice, this list of conditions and the following disclaimer in the
> >> + * documentation and/or other materials provided with the distribution.
> >> + *
> >> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
> >> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> >> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> >> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
> >> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> >> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> >> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> >> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> >> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> >> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> >> + * POSSIBILITY OF SUCH DAMAGE.
> >> + *
> >> + * ALTERNATIVELY, this software may be distributed under the terms of the
> >> + * Creative Commons Attribution-ShareAlike 4.0 International Public License as
> >> + * published by Creative Commons, PO Box 1866, Mountain View, CA 94042
> >> + * (https://creativecommons.org/licenses/by-sa/4.0/legalcode).
> >> + */
> > Is there any standing for dual-licensing 2BSD with CC-BY-SA?
> >> diff --git a/testsuites/libtests/ttest01/ttest01.doc b/testsuites/libtests/ttest01/ttest01.doc
> >> new file mode 100644
> >> index 0000000000..37d9ff8535
> >> --- /dev/null
> >> +++ b/testsuites/libtests/ttest01/ttest01.doc
> >> @@ -0,0 +1,19 @@
> >> +This file describes the directives and concepts tested by this test set.
> >> +
> >> +test set name: ttest01
> >> +
> >> +The test-*.c files must place the license header at the bottom of the file.
> >> +This allows a copy and past of the test code into documentation sources and
> > paste
> >> +enables a constent line numbering between the documentation code fragements and
> > constant ... fragments
> >> +the actual test output. For the same reason the T_TEST_OUTPUT() macros must be
> >> +placed after the actual test cases. The test source files are dual licensesd
> > licensed
> >> +BSD-2-Clause and CC-BY-SA-4.0.
> >> +
> > Thanks for the above explanation, it was helpful for this example. For
> > future tests, do you anticipate any text here such as a short
> > narrative description? Or this text should be deleted if it gets
> > copy-paste into new tests?
> Everything which may end up in the documentation (such as code examples)
> should be dual licensed BSD-2-Clause and CC-BY-SA-4.0 from my point of
> view. Otherwise we would have to deal with BSD-2-Clause also in the
> documentation set. Not every test needs this, just the one that may be
> used in the documentation, e.g.
Yes, I understand, my point was that the explanation of this
dual-licensing doesn't need to exist in every dual-licensed test. It
just needs to be understood (by developers/test-writers, maybe users)
> I would like to add also code examples to the RTEMS Classic API Guide
> for the managers (not in the next weeks).
Examples for using them? I can see this would be nice to dual-license.
> Another candidate for dual licensing are the interface specification
> items. I would like to generate the API header files with Doxygen markup
> and the API documentation from a single source - the interface
> specification items.
I might have missed something. Do you mean there is plan for an
interface specification using something like an interface definition
language (IDL), and you would like to generate header files such as
include/rtems/rtems/task.h, from IDL? Or something else?
> Sebastian Huber, embedded brains GmbH
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail : sebastian.huber at embedded-brains.de
> PGP : Public key available on request.
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
More information about the devel