decoration decoration
Stories

GROKLAW
When you want to know more... 		decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

Click here to send an email to the editor of this weblog.

You won't find me on Facebook

Donate

Donate Paypal

No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.

What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments

Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
SFLC Completes Review of Atheros Wireless Driver for Linux, Releases Guide for Developers
Thursday, September 27 2007 @ 10:59 AM EDT

How different reality often is from flame wars, particularly when the subject is legal.

The Software Freedom Law Center has just announced that it "has carefully reviewed the lineage of the open source Atheros wireless driver for Linux and determined which portions can be distributed under the ISC license (also known as the 2-clause BSD license)" [the full analysis is here]:

The licensing situation for the Atheros driver is complex because much of it was originally derived from an OpenBSD project called ar5k. This original code is licensed under the ISC license, but Linux code is typically licensed under the GNU General Public License (GPL). The GPL places specific additional requirements on distributors of software to ensure that its users are able to obtain the software's source code, and freely to copy, modify, and redistribute all subsequent modified versions.

Ultimately, all the copyright holders of the Linux ath5k-driver code, derived from ar5k, have been contacted and have agreed to license their changes under the ISC license, thus allowing improvements to be re-incorporated into OpenBSD. One of the three historical branches of the code reviewed by SFLC, however, included portions that are only licensed under the GPL, and SFLC has determined that it would be very difficult to re-incorporate that code into OpenBSD.

So now you know why it took a while to get an answer. They were contacting all the authors. So much for hotheads. SFLC also released some guidance for developers who wish to incorporate code with a permissive license into a GPL program. Here it is. There is specific information on how to preserve copyright notices in a project that already uses a file-by-file approach instead of one single copyright file, as most GPL software does it, and there is a paper on what is and isn't copyrightable. And going forward, there is advice regarding dual licensing.

They analyze it from both perspectives, as the goal is to avoid confusion. For those who want a permissive license:

Common attempts by developers at stating dual license notices tend to be confusing, contradictory, and legally unclear. While there may be cases where it will make sense for a developer (with a knowledgeable lawyer’s assistance) to place a dual license on his code, we generally recommend that developers not use dual licensing if their goal is simply to allow recipients to use the code within larger GPL’d works as well as under permissive terms. If such a developer is using a license like the modified BSD license or the ISC license, where there is an established and widespread community understanding that the terms permit incorporation into larger programs covered by the GPL, the developer should simply use the permissive license without any further reference to the GPL.

If you do want to use the GPL and yet wish to incorporate code under a permissive license, there is a step by step guide on how to get it right:

One of the most challenging licensing policies to implement is one in which permissive terms are retained on files within a larger GPL’d work. This section presents procedures that should be followed by GPL’d projects that desire to maintain a subset of the codebase under permissive terms. These procedures will help such projects ensure that their work complies with all applicable licensing requirements while preserving collaborative relationships with partner projects working on permissive-licensed code.

As for what is sufficient to warrant a copyright notice, the advice is to be cautious and assume a copyright notice is legitimate:

Not every modification to a program is copyrightable by the person making the modification. Minor edits are sometimes too small or insufficiently original to give rise to a copyright interest. If a contributor has only made formatting changes or has only contributed non-expressive data, such as constant values, it is possible that the contributor holds no copyright in the work.

Most of the time, however, patches submitted to a project are sufficient to create a copyright interest. Most countries have adopted a very low standard of originality and creativity for copyrighted works, and even a few lines of code or the rearrangement of different sections of a project might be enough to cause the contributor to be a copyright holder. Because there is no way to know for certain whether a court in a given jurisdiction would find a particular contribution copyrightable, it is most prudent to assume that there is a copyright in the contribution. Such prudence is justified by a consideration of the legal consequences of error. If a notice of an invalid copyright is placed on the program, the copyright notice has no legal effect. If, on the other hand, notice of a valid copyright is omitted, there may be disastrous consequences if the contributor later objects to the use of the material contrary to the contributor’s license. For these reasons, every contributor to a given work should be listed in the copyright notice, and all contributors should be consulted when projects contemplate relicensing. Even if some contributions appear to be too minor or non-creative to be copyrightable, the project should consult with a copyright lawyer before determining that the contributor need not be consulted in a relicensing decision.

I haven't finished reading and analyzing it myself, so we can do it together. Here's the meat of the press release:

*************************

FOR IMMEDIATE RELEASE

Software Freedom Law Center Completes Review of Linux Wireless Code

Nonprofit Legal Services Organization Also Releases Guidelines for Developers

NEW YORK, September 27, 2007 -- The Software Freedom Law Center (SFLC), provider of pro-bono legal services to protect and advance Free and Open Source Software (FOSS), today announced that it has carefully reviewed the lineage of the open source Atheros wireless driver for Linux and determined which portions can be distributed under the ISC license (also known as the 2-clause BSD license).

The licensing situation for the Atheros driver is complex because much of it was originally derived from an OpenBSD project called ar5k. This original code is licensed under the ISC license, but Linux code is typically licensed under the GNU General Public License (GPL). The GPL places specific additional requirements on distributors of software to ensure that its users are able to obtain the software's source code, and freely to copy, modify, and redistribute all subsequent modified versions.

Ultimately, all the copyright holders of the Linux ath5k-driver code, derived from ar5k, have been contacted and have agreed to license their changes under the ISC license, thus allowing improvements to be re-incorporated into OpenBSD. One of the three historical branches of the code reviewed by SFLC, however, included portions that are only licensed under the GPL, and SFLC has determined that it would be very difficult to re-incorporate that code into OpenBSD.

To share its knowledge with the FOSS and legal communities and to share background regarding its analysis, SFLC today has also released two documents of general interest. One document is a set of guidelines for developers who wish to incorporate code with a permissive license, such as ISC, into a GPL-licensed project. The other paper discusses the legal standards of originality with regard to computer programs under U.S. and international copyright law.

The two general papers, as well as a detailed document explaining SFLC's review of the Linux Wireless team's ath5k driver, are available at http://www.softwarefreedom.org/resources/

"We're pleased to help bring clarity to the Linux Wireless Developers as they work towards inclusion of their code in the Linux kernel," said Karen Sandler, SFLC Counsel.

This is not the first time that SFLC has worked with the Linux Wireless developers. In July, SFLC announced that it had performed a confidential audit of the open source Atheros driver and determined that no portion of it was illegally copied from Atheros' proprietary code.

  


SFLC Completes Review of Atheros Wireless Driver for Linux, Releases Guide for Developers | 178 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Off-topic here, please
Authored by: overshoot on Thursday, September 27 2007 @ 11:21 AM EDT
Make links clicky if you've got them; HTML prettyprinting instructions in red at
the bottom of the comment form.

[ Reply to This | # ]

Corrections (if any) here
Authored by: overshoot on Thursday, September 27 2007 @ 11:22 AM EDT
Please describe the nature in the Title.

[ Reply to This | # ]

SFLC Completes Review of Atheros Wireless Driver for Linux, Releases Guide for Developers
Authored by: k12linux on Thursday, September 27 2007 @ 12:29 PM EDT
If you want to be certain that you can use future modifications of your code
made by others then use a license like the GPL.

If you want others to be able to use your code with almost no restrictions use
the BSD license. If Microsoft later scoops up your code and builds something
out of it and puts that under a restrictive license that doesn't even let you
see the changes, well that's what you allowed so you really can't complain.

It's ok for a closed-source company to re-license BSD code such that they lock
their changes to BSD code away forever. That's how the license goes. Why in
this case people cried foul when someone re-licensed BSD code in a much more
open way is beyond me.

I admit I didn't look at it very closely. If the issue was just that copyright
attribution (which is required by the BSD license) was removed, then the people
who removed those are indeed in the wrong.

---
- SCO is trying to save a sinking ship by drilling holes in it. -- k12linux

[ Reply to This | # ]

Copyright parser/manager..thoughts for a toolset
Authored by: Guil Rarey on Thursday, September 27 2007 @ 12:52 PM EDT
This is from footnote 3 to the SFLC whitepaper on copyright integration....
Though the file-by-file method was widely adopted in the free software community during the past two decades, it is not an ideal method, because ensuring that notices remain correct imposes a heavy burden of individual file change tracking. We recommend that project leaders begin to reconsider the file-by-file approach, as it is error-prone and can lead to inadvertent copyright infringement and improper attribution. Any method that projects choose must be properly reviewed and maintained for accuracy. If the file-by-file method continues to serve as the canonical method for copyright inventory, we believe that substantial improvements are needed in the day-to-day care of the copyright and licensing notices in most projects.
Assuming the file-by-file method is too useful to pass up, for other reasons - I suspect it is, because it enhances modularity of files, what are the elements of a good copyright management tool to be incorporated into a version control system or elsewhere in a software development environment - an EMACS mode if you will.


  • It should handle most standard FOSS licenses (plus others as required).
  • It should manage attributions from source and patches, including multi-file patches.
  • It should manage license type and license version collisions as configured or complain very loudly and specifically when the configuration does not exactly fit submitted input.
  • The configuration engine should be tuned such that a paralegal of ordinary competence advised by a young attorney of ordinary competence can maintain it, without headaches and without much or any involvement from the actual FOSS project manager except when new situations genuinely arise.
  • The configurator should automagically edit source text for copyright compliance as required when code is added to the - well version control system, but whatever this tool is sitting on.
  • It should leave a very explicit log of any and all changes it makes.

I don't code - at least I don't code as much as I want to, and what I do code is in VBA (out of necessity), so I don't know the open source parser/lexer tools well enough. But I have to believe that tools designed to parse source can easily hacked to parse copyright.

Legalese in general is too tightly bound to English, a natural language for much automation. Natural languages are like the real numbers - computers can't actually handle them. But a restricted subset of Legal like Copyright - that could probably be handled.

---
If the only way you can value something is with money, you have no idea what it's worth. If you try to make money by making money, you won't. You might con so

[ Reply to This | # ]

SFLC Completes Review of Atheros Wireless Driver for Linux, Releases Guide for Developers
Authored by: Anonymous on Thursday, September 27 2007 @ 02:17 PM EDT
Groklaw is good because, digging for Truth...
Truth take time. And 'hotheaded' action sometimes, especially when you got a
major project to run, and protect it from many legal threats.
"So know you know why it took a while to get a while to get an answer...So
much for hotheads." < Digging for truth, eh?
Bias and agendas are easy to pick out... Remember, many others grok for the
truth as well, especially while using the source...

[ Reply to This | # ]

SFLC Completes Review of Atheros Wireless Driver for Linux, Releases Guide for Developers
Authored by: vinea_mayhem on Thursday, September 27 2007 @ 02:28 PM EDT
You know PJ if it weren't for the "hotheads" this wouldn't have been fixed. The blame lay squarely on the madwifi guys who refused to fix the error until after this all went public and become a big "todo" and the SFLC compelled them to. Without the "hotheads" there's no way in heck the driver code would be ISC and not GPL.

Which is unfriendly as hell on top of trying to strip off the BSD headers which was wrong. Dare I say the word "theft"?

But instead of an apology it appears that the FSF/GPL side of the family prefers to continue to call the BSD side of the family names like "hotheads". Even if it fits Theo.

Pretty much any coder would agree...if the primary developer released it under an open source license then the polite thing to do is to simply return any changes in the same license even if it isn't your favorite. If he or she hadn't shared that code with you then you wouldn't have anything to derive from. I don't care if the license is GPL, BSD, ISC, CDDL, Apache, MS PL or whatever.

RMS should have simply said that at the beginning of this fiasco and let peer pressure do the rest.

Instead lawyers had to get involved.

[ Reply to This | # ]

News Picks Discussion
Authored by: DaveJakeman on Thursday, September 27 2007 @ 02:33 PM EDT
Please get the title to match and link to the article in question.

---
Monopolistic Ignominious Corporation Requiring Office $tandard Only For
Themselves

[ Reply to This | # ]

One good thing about all this...
Authored by: vinea_mayhem on Thursday, September 27 2007 @ 07:55 PM EDT
One good thing about all this is that SFLC clearly restated the fact that you
can have permissive files in a GPL project as long as they are GPL compatible.

Something some folks learned during Monodevelop switch to X11 but that didn't
turn into a flamewar and so was largely unnoticed by the larger OS community.

Sharpdevelop (#D) used to be GPL only (it is LGPL today). Monodevelop (MD) was
derived from Sharpdevelop (so was GPL as well) but then the Monodevelop team
decided that all new contributions to MD must be in X11 and retroactively got
all their existing contributors to relicence their MD code to X11. So all the
MD files and MD developed plugins were X11 but the core code from #D was GPL.
The MD project is GPL but most of its pieces are X11 or LGPL by now (especially
with #D moving to LGPL).

FSF said "that's okay". #D folks say "so sayeth the FSF so
that's cool with us too".

So you can fork a GPL project and make all new contributions some GPL compatible
permissive license. All your changes are usable by the original project if they
want. They now have a spiffy new HOWTO from the SFLC on how to do so if they
do.

So likewise you can always contribute a fix or enhancement to a GPL project
using a GPL compatible permissive license if you wish. Which someone thought
you could not do when I posted my personal "rules of thumb".

To recap my "Rules of Thumb":

Rule #1: Contribute fixes and enhancements using whatever license the original
author/project prefers.

Rule #2: If you can't/won't do #1 use a more permissive license so they
original author or project can still use your changes.

[ Reply to This | # ]

SFLC Completes Review of Atheros Wireless Driver for Linux, Releases Guide for Developers
Authored by: vinea_mayhem on Thursday, September 27 2007 @ 10:16 PM EDT
It has been repeatedly asked/stated that BSD/ISC/permissive licenses do not
REQUIRE that code modifications be returned. So why should you?

Rather than my answering why several times, you should ask yourself why did the
SFLC ask each of the ath5k copyright holders to relicense to ISC?

Because perhaps it is the RIGHT thing to do for an FOSS developer?

That FOSS developers should not need to be REQUIRED to contribute modified code
back to a FOSS project in order to do so?

This assumption is NOT vague. It is NOT something that needs to be
"understood by osmosis" but part and parcel of what it MEANS TO BE AN
FOSS DEVELOPER.

If I have posted a lot on this topic it is for this reason. If we don't get it,
who else will? If we only adhere to the letter of the law then on what grounds
are we to be outraged over Tivoization?

"But it's not required" is a Tivo style excuse. We should not need a
BSDv3 in order to hope that the Free Software developers contribute back code
changes to their Open Software brethren.

[ Reply to This | # ]

I think they (the SFLC) made a mistake.
Authored by: jo_dan_zukiger on Friday, September 28 2007 @ 10:15 AM EDT
I appreciate the efforts they are putting into this, but consider their
advice:

5.4 Create a system for tracking permissions.

First, this should have been prefaced with, "It's going to cause
problems. Don't do it unless you have the resources to clean the
mess up."

(Do we all misunderstand how source code control is such a
deceptively simple problem?)

Second is this:

"For a project that uses the GPL, patches submitted to project
subcomponents are assumed to be governed by the GPL unless
the contributor explicitly states otherwise."

This is a bad assumption, and the SFLC should have come out and
said so.

They advise that the project's leaders should instruct contributors
to specify whether their license terms are different from the
project's terms in their patch contributions. As Guil Rarey notes
above, this works against the legal modularity of the file. You
could say it creates "lmplicit legal linkage". (Perhaps,
"implicit legal
baggage" would be even more to the point.)

What they should have specified is that the default should be the
license terms of the _file_, and that a project's leaders should
discourage contributors from leaving off a notice about the license
terms of patch contributions _unless_ they intend to use the same
terms as the original terms on the file.

Why should the file's license terms have priority over the project's
license terms as default terms? Very simple. Any terms specified in
the file are already explicit, and do not require the recipient of the
file to have any knowledge of the project from which the file came.

Asserting the project license as a default is very similar to using
magic numbers and protocols in a program, for what it's worth --
implicit global parameters that you have to go searching through
tons of irrelevant stuff to find out.

The current practice, especially in the GPL crowd, may be to follow
project tradition, but it will create legal problems down the road,
for the same reasons that magic numbers and protocols cause
software maintenance problems: that implicit linkage thing.

Having said the above, I'm going to continue.

Something that a lot of people are sweeping under the carpet is
a rather simple fact. Any explicit grant of license accompanying
a work is essentially one side of a gentlemen's agreement.
Ettiquette, morals, ethics, common law (where applicable) and
other legal context, and natural consequences all come into play.

A gentlemen's agreement tends to not be overly specific because
it is well understood that any preconditions will tend to require
exceptions at some point. Gentlemen give each other room to do
things that are expedient, keeping two implicit expectations:

First, it is assumed that a gentleman will not deliberately foul the
pool, so to speak. Second, it is assumed that when a gentleman
receives benefit from the community, he will, when he is able,
give back to the community in tangible ways (not just pretending
that his presence in the community by itself is sufficient blessing
to the community).

Preconditions are kept to a minimum, not only because loopholes
will always exist, for those who look for them, but also because
there will always be cases where terms that were intended to be
liberal will prove too restrictive for some use the original authors
and most holders of copyright interest would agree would be
valid use. Rare cases, perhaps, but not non-existent.

The GPL looks this direction by trying to drop almost all
restrictions for uses which do not involve publishing the
program in either source or object form. The ISC, of course,
goes a lot farther.

We talk about the ISC as if it's "permissive", as if almost anything
goes as long as the copyright notice and license are kept intact.
We assume that it allows refraining from giving modifications back.
These assumptions are conceits.

First is natural law. What goes around comes around. Most
obviously, if everybody takes and no one gives back, the project
will die. Maybe you have the source, but you will almost surely run
into some need that will cost more to develop for yourself than it
woudld have cost had you got the original authors to at least help
with it. Another less obvious consequence of selfish use is that
code you fail to give back will never be examined for errors by the
people most qualified to find the errors.

And then there are the social issues. You soil the common
marketplace, and the other members of the market won't
particularly encourage you to continue to come back.

Permissive is not really a good term here. Even under the legal
doctrine of consenting adults, paternity and other obligations are
recongized.

The point of the GPL is that it provides a fairly explicit framework,
and requires agreement to the framework. The ISC gives a lot more
flexibility. But the basic obligations remain, even if they
sometimes require a project member with a strong personality to
remind everyone of them.

joudanzuki

[ Reply to This | # ]
    Groklaw © Copyright 2003-2013 Pamela Jones.
    All trademarks and copyrights on this page are owned by their respective owners.
    Comments are owned by the individual posters.

    PJ's articles are licensed under a Creative Commons License. ( Details )     		Site layout based on Woodlands theme by Bryan Bell.
    Groklaw logo by John Crowley.
    News Picks logo by Ted Thompson.
    Powered By GeekLog
    Created this page in 0.04 seconds