Hi all, I think that we as mainainers should look at all code that we know and involves us and do the change area by area For the Sony contributions I will change the license in all contributed files as soon as I get clearance from our department
Regards Alin On Sat, Mar 21, 2020 at 1:24 AM Adam Feuer <a...@starcat.io> wrote: > Thanks Justin. I think Brennan is volunteering to be release manager and > get the next one out, as long as we can start a license clearing process > and make things a little better (become more Apache-like :) ) each release. > Here's what Brennan and I are planning for this weekend: > > 1. We're going to work on the scheduler module (nuttx/sched/) > 2. Some recent changes were made to license headers under that > directory. We're going to go back in time to before those changes... > 3. Brennan will use Fossology to generate license reports for the files > under sched/ > 4. I will find the set of C files that only have NuttX committers (who > we should have ICLAs from) > 5. We will check this set of files manually and against the Fossology > report > 6. For the files that are BSD license and have authors that are NuttX > committers, we'll change the license headers and commit the result to a > branch. > 7. I will create a PR for this change, and we can use the PR to discuss > next steps. > 8. Once it's merged, Brennan will work to get the release out. > > For more info: > https://cwiki.apache.org/confluence/display/NUTTX/License+Clearing > > Improvements to this are welcomed. > > cheers > adam > > On Fri, Mar 20, 2020 at 5:03 PM Justin Mclean <jus...@classsoftware.com> > wrote: > > > Hi, > > > > INAL but the copyright notice in the header is just a claim and may not > > reflect who actually has copyright. It doesn’t mean that that person or > > company owns the copyright on the entire file. With a company it’s > usually > > easier as employment contracts say the company owns the copyright of > works > > produced by their workers. With individuals it gets more complex as they > > may or may not own the copyright or may be unaware who does. (Worse case > > scenario see [1], where an employee was forced to implement an idea he > had > > outside of work unpaid and had to pay costs) > > > > Each person who made changes would own copyright (or for their company) > > automatically on their work. Especially in this case where I believe the > > project had no ICLAs or agreements in place with it contributors about > > copyright. If you a more qualified opinion please ask on legal-discuss. > > > > We know this is currently an issue, so I would you just note that it is > in > > the work in progress DISCLAIMER for the initial release, so that way > people > > who use the release are aware of it. Given the licensing terms of the > files > > it’s not an issue that would stop most people from using the software. > > > > What Brennan and Adam are suggesting sounds like a good process to me. > > Identifying all of the contributors that don’t have ICLA is useful, it’s > > also good to has some ideas of the size of their contribution. For large > > contributions it would be best to get an ICLA from the individual, this > may > > be a lot of work, and in some cases it may not be possible. That fine we > > can deal with that as needed and this shouldn’t hold up a release or > > graduation (as long as progress is being made) and can be done in > parallel. > > > > A release could have been made at any point in the last several months, > > the only barriers to not do so that are ones you are putting up for > > yourself. A release doesn’t have to be perfect, in fact it doesn’t even > > have to work as far as the ASF is concerned. A good goal to aim for it to > > make each release better than the last, and release frequently rather > than > > trying to make a perfect release. > > > > Thanks, > > Justin > > > > 1. > > > https://www.chicagotribune.com/news/ct-xpm-2002-08-05-0208050013-story.html > > > > -- > Adam Feuer <a...@starcat.io> >
