License boilerplate missing on source files

[rtucker]

Per the COPYING file, something like the following ought to be injected atop each source file:

    <one line to give the program's name and a brief idea of what it does.>
    Copyright (C) <year>  <name of author>

    This program is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation; either version 2 of the License, or
    (at your option) any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License along
    with this program; if not, write to the Free Software Foundation, Inc.,
    51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.

This is mostly scripty grunt work, but before it is undertaken: what should be? A general assignment to Nuand:

    Copyright (C) 2013 Nuand LLC

or all of the contributors to each particular file:

$ git log --date=short --format="Copyright (C) %ad %an <%ae>" fx3_firmware/bladeRF.c | cut -b1-18,25- | sort | uniq
Copyright (C) 2013 Brian Padalino <bpadalino@gmail.com>
Copyright (C) 2013 Keith Rothman <litghost@softhome.net>
Copyright (C) 2013 Nuand <bladerf@nuand.com>
Copyright (C) 2013 Robert Ghilduta <robert.ghilduta@gmail.com>
Copyright (C) 2013 Robert Ghilduta <robert.ghilduta@nuand.com>

(The latter is probably the way it ought to be, even though it is slightly more PITA.)

[bpadalino]

The licensing has to get figured out and settled. Being GPLv2 for the main library is silly and I believe, due to the lifting of ezusb.c from libusb, we are required to be at least LGPLv2 for the library. For the other bits, I am OK with a very permissive MIT or BSD license.

The question becomes, for shared items, what license goes into those files? Does license information even go into header files since header files aren't really copyrightable?

As for contributions, I saw CLAhub. Thoughts on using that?

[litghost]

I assumed were we GPLv2 per bladeRF/COPYING.

[bpadalino]

Originally that's what we had planned, but a library being GPL'd is kind of crappy. Keeping the CLI and flash utilities GPL is fine for me too. Not sure HDL really works very well being GPL.

[DanielG]

The HDL can't really be GPL at all since it "links" with the proprietary NISO core. So a BSD style thing is probably appropriate there.

[rtucker]

I am, in general, in favor of MIT.

But: if the license is going to be changed at this juncture, it will probably need the explicit approval of all committers so far. (So, the sooner, the better, I suppose!) On Oct 3, 2013 9:03 AM, "Daniel Gröber" notifications@github.com wrote:

The HDL can't really be GPL at all since it "links" with the proprietary NISO core. So a BSD style thing is probably appropriate there.

— Reply to this email directly or view it on GitHubhttps://github.com/Nuand/bladeRF/issues/125#issuecomment-25618395 .

[jynik]

Regarding getting existing an future committers to sign a CLA, I came across CLAHub. However, the project is marked "in progress" and doesn't seem to have had any updates for 7 months... perhaps it's be easier to folks to "sign" a provided CLA template and email it to bladerf@nuand.com?

As for the CLA itself...holy IANAL batman! I assume the Harmony agreements are kosher...

[jynik]

A dev-license branch has been pushed, with liceneses and CAA's in a legal/ folder. Feel free to join the fun in slapping the appropriate license text at the top of each file.

All contributors should have received an email. Once we get the okay we can work to merge this into master.

If you received no such email, please contact me or email bladeRF@Nuand.com

[smunaut]

Note that the HDL can be GPL (I'm not saying or arguing it should be, just saying it probably can for the record). The "link" concept is often a shortcut used for software. For hw, you'd have to go back to the license wording which says "derivative work". You can't really argue the NIOS is a derivative work of the Nuand's code.

[DanielG]

But the whole linked HDL blob is a Derivative Work of the GPL licensed code and the proprietary NISO core, since the source code for the NIOS is not available (and wouldn't have a GPL compatible license anyways) distribution under the GPL wouldn't be permitted. So distributing the source is fine but the binaries are problematic. (See section 2 and 3 of the GPLv2)

[jynik]

So far we've got some great feedback from everyone regarding licenses and the CAA. As you can see from the current draft of the COPYING in the dev-license branch, we're generally leaning toward BSD/MIT where we can.

Another issue brought up was that libbladeRF being LGPLv2.1 may also be problematic when we begin porting that to the NIOS. It's been suggested that this become MIT or BSD, which I believe all the Nuand folks are okay with. Does anyone else see a problem with that?

[litghost]

We have to purge ezusb.c then. It is from libusb which is LGPL. That was consistent when I expected that the library was GPL.

[jynik]

Good call!

I can think of two possible solutions to this... what do you think:

1. We remove the use of ezusb.c from the library (removing the recover functionality from the lib), but keep it in the GPLv2-licensed bladeRF-flash. I don't think it's terribly unreasonable to use bladeRF-flash in those recovery situations, do you?
2. We allow libbladeRF to be dual-licensed. A CMake configuration option can be used to switch the library to be built between MIT-licensed (where the recover function returns an error indicating this is not supported), or LGPLv2.1, where this function remains. In this case,

Personally I think 1 is the least confusing option. We could go so far as to move ezusb.c into a utilities/common/ just to help keep folks from thinking they could pull that into the lib.

Unrelated, but wanted to note... The utilities are going to have to be kept GPLv2, just so we can link with various other useful things. I'd envision the lib and utilities would be packed separately in .debs. (Looking at you HoopyCat...)

[litghost]

That can work, but it means the "recover" option from bladeRF-cli will be gone without a common implementation.

[rtucker]

In the debianization pull request (still pending cough), there are separate debs for the libs and utilities. It appears they've thought of this when devising their policies. :-)

On Sat, Oct 12, 2013 at 10:55 PM, Jon Szymaniak notifications@github.comwrote:

Good call!

I can think of two possible solutions to this... what do you think:

1.

We removed the use of ezusb.c from the library (removing the recover functionality from the lib), but keep it in the GPLv2-licensed bladeRF-flash. I don't think it's terribly unreasonable to use bladeRF-flash in those recovery situations, do you? 2.

We allow libbladeRF to be dual-licensed. A CMake configuration option can be used to switch the library to be built between MIT-licensed (where the recover function returns an error indicating this is not supported), or LGPLv2.1, where this function remains. In this case,

Personally I think 1 is the least confusing option. We could go so far as to move ezusb.c into a utilities/common/ just to help keep folks from thinking they could pull that into the lib.

Unrelated, but wanted to note... The utilities are going to have to be kept GPLv2, just so we can link with various other useful things. I'd envision the lib and utilities would be packed separately in .debs. (Looking at you HoopyCat...)

— Reply to this email directly or view it on GitHubhttps://github.com/Nuand/bladeRF/issues/125#issuecomment-26210496 .

Ryan Tucker rtucker@gmail.com

[DanielG]

I don't think the GPL defines putting GPL/proprietary things in an archive as a derived work so this is not strictly necessary but it is still debian policy for different reasons.

Also a GPL licensed program running on a proprietary processor isn't a derived work either so libbladeRF beging LGPL shouldn't be a problem unless you plan on somehow linking it with the HDL (??). As long as the NIOS program is just loaded into RAM/ROM that doesn't constitute a derived work I don't think.

[DanielG]

Even if the NIOS toolchain is proprietary that's also fine:

"However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable."

[jynik]

Upon getting a few remaining CAAs, I'll be looking to make the changes here this weekend, pending on some consensus about the lib's license not conflicting with anything (potentially after some changes).

Daniel -- some good points there, thanks! However, I thought the issue was more along the lines of the app-code running on the NIOS was statically linked with some proprietary libs, not just that it runs on a proprietary processor.

Update: I didn't totally understand the special exception Daniel mentioned -- so the argument there is the NIOS stuff linked against is a "Major component" of the OS, right? Therefore, there's no conflict?

I haven't been involved in working on the NIOS code yet, so I'm looking to those who have for some guidance here. Am I incorrect here?

Update: From further discussion on IRC -- it was noted LGPLv2.1 would work in the case where the NIOS code is linked with proprietary NIOS code, so long as the .o's were provided to allow folks to re-link the LGPL bits.

[jynik]

dev-license (rebased, forced-update inbound...) has been updated to have what should be the appropriate file headers. The new COPYING should reflect the state of each section of the tree, legal/CAA contains the contributor assignment agreements, and legal/licenses/ contains the licenses found throughout the code base.

There's a few of you we're still waiting to get CAAs from...I think folks know who they are. ;) Shoot an email to bladeRF@nuand.com with any questions or concerns.

Robert and Brian, mind doing a quick once over to make sure nothing's out of place?

HoopyCat -- I didn't tend to the debian/ or misc/arch yet...mind handling the items in debian/ and firing off a pull request against the dev-license branch?

Thanks!

[rtucker]

I have a branch with debian/ tweaks... hopefully I'll get a chance to land it this evening.

UPDATE: Pull request #163

[jynik]

Thanks Ryan! Pull request merged, and I believe we've gotten all the CAA's and OK's on the changes.

I'll dev-license should pretty much be armed and ready for the merge. I'll target a merge on Sunday afternoon (this shouldn't break the build, but in the evening we can verify this).

First, I want to check in with Brian and Rob to ensure merging this isn't going to cause them merge/rebase headaches.

Thanks again to all those involved!

[rtucker]

I can confirm that 625694e and edc468d address the issues I had originally. Closing issue.