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

[Jakub Sejdak <jakub dot sejdak at phoesys dot com>]

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.
- I will keep license in any copied file, that origianally had it.
- I will remove license from any other file in my sys directory
(because one in COPYING.NEWLIB will be in force).

And how should I confirm that I'm the author and that my employer is
fine with 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.

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

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