ath5k, license is GPLv2
The files are available only under GPLv2 since now.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
---

commit 330c2ab9a53ddce27003218bd546034e8eeeff17

tree b24cecd991fbe3046d5c5269c61e0090427e4fd3

parent ceeaf6b9aac9daaa41ec38fbba3d2c1972af4470

author Jiri Slaby <jirislaby@gmail.com> Tue, 28 Aug 2007 16:27:51 +0200

committer Jiri Slaby <jirislaby@gmail.com> Tue, 28 Aug 2007 16:27:51 +0200
 drivers/net/wireless/ath5k.h        |   12 +-----------

 drivers/net/wireless/ath5k_base.c   |   22 +++-------------------

 drivers/net/wireless/ath5k_base.h   |   33 +--------------------------------

 drivers/net/wireless/ath5k_hw.c     |   13 +------------

 drivers/net/wireless/ath5k_hw.h     |   12 +-----------

 drivers/net/wireless/ath5k_reg.h    |   31 +------------------------------

 drivers/net/wireless/ath5k_regdom.c |    4 +---

 drivers/net/wireless/ath5k_regdom.h |    4 +---

 8 files changed, 10 insertions(+), 121 deletions(-)
diff --git a/drivers/net/wireless/ath5k.h b/drivers/net/wireless/ath5k.h

index 0c6f3f5..c76b97b 100644

--- a/drivers/net/wireless/ath5k.h

+++ b/drivers/net/wireless/ath5k.h

@@ -2,17 +2,7 @@

  * Copyright (c) 2004-2007 Reyk Floeter <reyk@openbsd.org>

  * Copyright (c) 2006-2007 Nick Kossifidis <mickflemm@gmail.com>

  *

- * Permission to use, copy, modify, and distribute this software for any

- * purpose with or without fee is hereby granted, provided that the above

- * copyright notice and this permission notice appear in all copies.

- *

- * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES

- * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF

- * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR

- * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES

- * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN

- * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF

- * OR IN CONNECTION ...
[ message continues ]

Since the BSD people are already getting upset about (for various

reasons among which seem to be a clear non-understanding) I'd suggest

changing it to:
+ * Parts of this file were originally licenced under the BSD licence:

+ *

+ * Further changes to this file since the moment this notice was extended

+ * are now distributed under the terms of the GPL version two as published

+ * by the Free Software Foundation <yaddaya>
johannes

-

How about asking for changes to be dual-licenced too ?
	Xav
-

In theory, that could work, but in practice relying on functions that

the Linux kernel offers in GPLv2-only headers etc. will make the result

GPLv2 anyway, and disentangling it would be a nightmare.
johannes

Is this really a good idea?  Most of the reverse-engineering was

done by the OpenBSD folks, and it would certainly be helpful to

work together with them on new hardware revisions, etc..

-

The heck with "good idea" - it's unclear to me if Jiri is even *allowed*

to remove the BSD/other license.   Jiri can release *his* code as GPLv2

only, but I suspect the files as a whole really should be dual BSD/GPLv2,

due to the numerous other stakeholders in those files.

This mess has been occurring in the kernel for years. The DRM graphics

drivers are used in both BSD and Linux. It is quite easy to contribute

something to this code via LKML and think you are doing it under the

GPL. Doesn't a patch against the kernel have to be GPL? When these

patches get pulled back into BSD and distributed with it, did BSD get

infected with the GPL? AFAIK this has never been legally sorted out.
--

Jon Smirl

jonsmirl@gmail.com

-

I'm not aware anyone has felt it needed "sorting out". Its not exactly

complicated.
	BSD non advertising is compatible with GPL
The GPL says:

	"when you distribute the same sections as part of a whole which

	is a work based on the Program, the distribution of the whole

	must be on the terms of this License, "
The BSD license doesn't conflict with that
The GPL (and copyright law also say)
"If identifiable sections of that work are not derived from the Program,

and can be reasonably considered independent and separate works in

themselves, then this License, and its terms, do not apply to ..."
All a bit irrelevant anyway as Ath5K code (not the .h file) say:
 * Alternatively, this software may be distributed under the terms of the

 * GNU General Public License ("GPL") version 2 as published by the Free

 * Software Foundation.
So Jiri is choosing to distribute it under the GPL, and with his changes

GPL only.
So whats the problem ?
-

BSD code can definitely be brought into a GPL project as you describe.

The problem is the other direction.
Aren't patches made against the kernel GPL'd if the author doesn't

explicitly grant them more liberal BSD license in addition?
The problem then comes in taking the patches that were only made

available against GPL code and reshipping them under the BSD license

without the author explicitly agreeing to this.
What if a patch spans both code that is pure GPL and code imported

from BSD, how do you license it?
--

Jon Smirl

jonsmirl@gmail.com

-

Is it actually necessary to change the license?  With the dual-license,

you can keep a single code-base for both BSD and Linux platforms, which

seems terribly important to me.  It'd be awful to lose that.  It would

be a maintenance nightmare for BSD.  Is it even possible--in real life,

I mean--to accept GPLed patches into a BSD project?  Nightmare, I tell you!

-

See the acpi codebase for a worked example.
Alan

-

Why?
Very good point, but, in my opinion, it should be still resonable for

both sides: it simply means such changes are mostly unusable for the

other side, but nobody is going to waste time for marking all these

places, or care about suing if accidentally the changes, after some

adaptation, are usable for the other side. Unless you think or know

that "#include xyz" or "print_linux_way()" should add more than these

(maybe unusable) words or lines only?
Jarek P.

-

I think it's a valid assumption, if we say that the author

of the patch read the license header of a file and agreed with it.

So the patch is licensed to whatever the fileheader says. And if

there's none, it's licensed with the COPYING terms.

If a patch author likes some other license conditions, he must

explicitely add them with the patch to the file, saying that this

and that part have these and those conditions. Of course they must

be compatible with the original license.
--

Greetings Michael.

-

I didn't track this thread from the beginning, so maybe I repeat

somebody's ideas (probably like above), but IMHO: do we have to be

so selfish/pedantic? Can't we sometimes 'donate' a little bit to our

'older' bsd cousins or half-brothers? I think, it could be like this:
- if our changes are minor and authors of these changes don't mind

the file could stay BSD licensed only; plus we ask BSD to let it be

dual licensed (but no big hassle);
- otherwise, we should always distinctly mark all GPL parts.
Regards,

Jarek P.
PS: there is probably some mess with gmail addresses in this thread.

-

On Thu, Aug 30, 2007 at 10:26:52AM +0200, Jarek Poplawski wrote:
...or maybe it's OK...  Sorry.
Jarek P.

-

Technically the best we can do is to leave the license as dual

licensed, but keep in that technically that means nothing and is just

for show, the GPL is what would apply as its derivative work and is

the most restrictive license. This applies to any other driver in the

kernel right now with a dual license tag.
  Luis

-