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

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

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


No, actually I took it from some file in Linux port in newlib without
any greater reason. There is no problem to license our code under any
BSD license.

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


So I hereby state, that I'm the author of all curremt files licensed
by Phoenix Systems company in newlib. I (and also any other employee
from Phoenix Systems) have permission from our CEO to submit files to
sys/phoenix directory in newlib.

Tomorrow I will send my patches again. Second one will be rather big,
so I will send a link to our FTP to minimize data transfer for
everyone.

Thank you for your patience,
Jakub

2016-05-04 18:18 GMT+02:00 Jeff Johnston <jjohnstn@redhat.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.
>> >> >>
>> >>
>>