This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: [PATCH 001/114] Add initial port for Phoenix-RTOS.
- From: Jeff Johnston <jjohnstn at redhat dot com>
- To: Jakub Sejdak <jakub dot sejdak at phoesys dot com>
- Cc: newlib at sourceware dot org
- Date: Mon, 2 May 2016 15:44:26 -0400 (EDT)
- Subject: Re: [PATCH 001/114] Add initial port for Phoenix-RTOS.
- Authentication-results: sourceware.org; auth=none
- References: <1460370132-4880-1-git-send-email-jakub dot sejdak at phoesys dot com> <570CBA29 dot 2040200 at embedded-brains dot de> <CAFvk=0vKpZ=fVOHv-k46B3rOMrDP8p1K1eRA4O0oCD=Bf3Uztg at mail dot gmail dot com> <CAFvk=0tyD=crt5v77xzkzyt7MTXdXCTNZ7w4D10NKq32iE6=8g at mail dot gmail dot com> <571092E4 dot 3050507 at embedded-brains dot de> <CAFvk=0sFaYBaKhQDx8QeD23WaO=oi4A3p-U0qQUMAL=EVv2hJQ at mail dot gmail dot com> <281088438 dot 4815603 dot 1460742796876 dot JavaMail dot zimbra at redhat dot com> <CAFvk=0tXG0VGk2i5A5cwOeq--caMiC2cbDJGe6QAGVY9wkZ+DQ at mail dot gmail dot com>
Jakub,
Corinna is away on vacation. I was awaiting your response on the licensing
issue. Without a valid reason to use the LGPL now, your code should be re-licensed
with any BSD-style license you choose (see COPYING.NEWLIB). The license should only be
used for shared libraries or if you grabbed the code from such sources.
That done, any code that sits in its own machine or sys directory, I can quickly approve as it is segregated to your configuration.
Please group these files as much as you can to reduce the number of patches I have
to review and, more importantly, apply to the repo (i.e. if it is licensed correctly and you have tested it,
I am fine with applying it). It would help if you could confirm that you are the author
of this code and that your employer is fine with you submitting this code to newlib.
Also please note and group files that are shared with other newlib configurations. That helps as those
are the files I must look at closer to ensure other configurations aren't affected.
Regarding a time-line, I can do this quickly if you conform to bigger patches to review. Let me know
if you have a required date so I will prioritize it with other work I have to do.
Regards,
-- Jeff J.
----- Original Message -----
> Hi again,
>
> Can Jeff or Corrina summarize status of applying my patches? We have
> some business targets that depend on those patches and I need to know
> more or less how long will it take.
> As for licensing, we do not support shared libraries for now and that
> is why it is disabled at build time.
>
> Thanks in advance,
> Jakub
>
> 2016-04-15 19:53 GMT+02:00 Jeff Johnston <jjohnstn@redhat.com>:
> > Hi Jakub,
> >
> > They are not rejected. You did submit 114 patches to look at to be fair
> > and a number of
> > them require loading. I am just looking at it today.
> >
> > Licensing as LGPL is not an issue if you are building a shared library form
> > of the library.
> > Otherwise, any statically linked application using your library must be
> > licensed LGPL. In the case of x86-linux,
> > the files were taken directly from glibc at the time and we do build a
> > shared library.
> >
> > If your code has been copied/taken from LGPL sources, then you can't
> > relicense, but if you are the original
> > owner, you should relicense with a more-relaxed license as I notice your
> > code does not enable
> > shared library support in configure.host
> >
> > -- Jeff J.
> >
> > ----- Original Message -----
> >> So question to Corrina or anyone else who is responsible for
> >> maintenance: what should I do now to have my patches applied? Or are
> >> they already rejected?
> >> If you wish I can send another set with changed/removed license in
> >> each file, but this will generate another huge set of emails.
> >> As for duplicated headers: this shouldn't be much of a problem,
> >> because the same situation is, as I see, already in Linux port.
> >> This has no impact on Cygwin, RTEMS or FreeBSD builds.
> >>
> >> Later on, after publishing this (and also patches to binutils & gcc)
> >> we can think about reducing headers duplication.
> >>
> >> time_t is currently defined in kernel header as typedef from int.
> >>
>