Re: [PATCH 001/114] Add initial port for Phoenix-RTOS.

[Jeff Johnston <jjohnstn at redhat dot com>]

See below.

----- Original Message -----
> Hi Jeff,
> 
> Then I must have misunderstood you earlier about what should I do.
> 
> So correct me if now I'm wrong now:
> - I will put another entry to COPYING.NEWLIB with 2-clause BSD license
> for Phoenix-RTOS targets.

Yes, please license any new files you wrote with a BSD-style license.

> - I will keep license in any copied file, that origianally had it.

Yes, you cannot re-license a file that you borrowed from elsewhere.  Did you
copy files from glibc?  Is that why you have the LGPL everywhere?

> - I will remove license from any other file in my sys directory
> (because one in COPYING.NEWLIB will be in force).

No, you should have licenses in all files you submit.  A missing license implies the
Red Hat license (from COPYING.NEWLIB) which isn't true in this case.  The idea is to identify files you have
written vs files you have borrowed.  Even if your configuration falls under LGPL which is
bad for a statically linked platform, at least others can borrow your new parts in the
future without requiring the LGPL.  If only some files are LGPL, you should consider rewriting those
bits yourself or borrowing from another BSD-compatible source to fix the problem (e.g. FreeBSD) or simply
support a shared library build by default (using libtool).

> 
> And how should I confirm that I'm the author and that my employer is
> fine with it?

I am fine with you stating on this list that all files marked as new and licensed/copyrighted
by your company were written by you (or mention team members if appropriate).  I am
also ok with you stating that your company has given your team permission to submit any
new code written by you and your team to newlib.  Obviously don't state it if it isn't true and if not true, ask your employer
for permission to submit it.

> If the above is correct, then I will send patches again: one with all
> changes to common configure files and second with whole sys/phoenix
> directory.

Sure.  Don't forget about other common files such as ieeefp.h and config.h.  See the newlib faq on what files are needed
for a port.  Use as much as you can from the shared portions of newlib to save you maintenance and to possibly reduce
the number of files you would need to rewrite to get rid of the LGPL if you want to support static linking.

> 
> As for time-line, my employer made it 'urgent', but with no deadline.
> 

Ok, good to know.

-- Jeff J.

> Regards,
> Jakub
> 
> 2016-05-02 21:44 GMT+02:00 Jeff Johnston <jjohnstn@redhat.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.
> >> >>
> >>
>