lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87d4gi4joy.fsf@ebb.org>
Date:	Wed, 26 Nov 2008 09:59:25 -0500
From:	"Bradley M. Kuhn" <bkuhn@...twarefreedom.org>
To:	<linux-wireless@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<ath5k-devel@...ts.ath5k.org>, <ath9k-devel@...ts.ath9k.org>
Cc:	karen@...twarefreedom.org
Subject: Re: License of changes to ath5k/ath9k

Luis Rodriguez wrote at 16:04 (EST) on Tuesday:

> We have been using the Changes-licensed-under tag [1] for ath5k
> development but for ath9k we tend to ask developers individually if
> they are willing submit their changes and any future ath9k changes
> under the ISC. We keep this for our records just in case you haven't
> read the Singed-off-by.  I think it'd be easier too if we ensure
> developers really read that document too and ensure they understand it
> and also understood why are are doing this.

> We'll keep using the ath5k Changes-licensed-under tag until we get
> advice from SFLC if we have done enough to ensure this is no longer
> necessary.

I should note that there's no specific magic to the
Changes-licensed-under tag; we developed with with Luis as a mechanism
and tool to do the the thing that mattered: Carefully catalog the fact
that each person who makes a change on an ISC-licensed codebase agrees
to keep the code under ISC license for later sharing with BSD folks.

There are probably a dozen methods you could use to do this job, and
really you should use whatever method works for the development team.
The only fundamental requirement is that it be rigorous, detailed and
complete.

Of course, if situations change and become more complicated, the Linux
Wireless team is welcome to contact me and Karen at the Software Freedom
Law Center for additional legal advice on this subject.

Bob Copeland wrote on at 16:28 (EST) on Tuesday:
> I don't consider any of my changes significant enough to confer
> copyright,

Most non-lawyers like myself are amazed to find how little it takes for
something to confer copyright.  If you did anything more than correct a
spelling error, it's always better to assume you have a copyright
interest in the work.  Sometimes, you'll be wrong, but more often than
not, it will turn out the thing that looked uncopyrightable actually
*is* copyrightable under the Draconian copyright laws that now exist in
most industrialized countries.

> However, if everyone + SFLC prefers that we strictly use
> Changes-licensed-under even if we don't claim copyright, then I'll
> happily add the tag generator script to a git commit hook :)

Yeah, exactly, it's an easy thing to do just to be sure.  The worst that
happens is that you didn't have copyright in the thing, and your consent
to the ISC licensing of the work wasn't actually needed, but you gave it
anyway.  (It's like saying: "I consent to you going to the store today".
You didn't need my consent, but it doesn't hurt that you have it.)  This
is far better than the alternative: that the consent was needed but it
wasn't given because it seemed the changes weren't copyrightable but
they actually were.


BTW, SFLC published a white paper on this issue that might be of interest:

http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html
-- 
Bradley M. Kuhn, Policy Analyst and Technology Director
                 Software Freedom Law Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ