From: Paul Fernhout <pdfernhout@kurtz-fernhout.com>
All -
I just attended a DKR telephone conference where I promised to post
something about IP licensing issues to this mailing list. Let me preface
this by saying, I am not a lawyer, so this is just my personal take on
some IP issues the colloquium needs to address. Comments and corrections
are welcome. Also, what I write here goes mostly for U.S. law, not
international law, and some countries have different rules (or none at
all).
I am just a software developer who has released some open source
software, who is working on some more, and who has worked with yet other
open source software. In the process of all that I have thought about
these issues some.
So, as always, consult your IP lawyer before taking action based on
anyone's internet ramblings. These issues are very complex, and I do not
do them complete justice here. Also, some issues are still open to
interpretation in the courts.
===== some history =====
First, some background generalities. Intellectual Property (IP) is
things like Copyrights, Patents, Trade Secrets, and Trademarks. If you
look back historically, many ancient cultures (I believe including both
ancient Greece and ancient China) did not believe the individual has any
right to their creative ideas or expressions. Such ideas were given by a
god or inspired by a muse and were to be used by any and all.
U.S. copyrights and patents were not created under the U.S. Constitution
because it was thought people had the right to own information (as
opposed to the more accepted belief in the U.S. of a right to own land
or tools). From:
http://lcweb2.loc.gov/const/const.html
"Section 8. The Congress shall have power to ... promote the progress of
science and useful arts, by securing for limited times to authors and
inventors the exclusive right to their respective writings and
discoveries" So, copyright and patents were actually created to
increase the store of public domain knowledge. Trade Secrets and
Trademarks (mentioned later) are more along the line of "owned" things,
since they may in theory be held privately forever.
Copyrights http://lcweb.loc.gov/copyright/ supposedly encourage the
creation of information which in time would become part of the public
domain. They do this by allowing the creator to have a short term
franchise on the knowledge as an encouragement to create. That franchise
was originally a couple of decades; through clever legal lobbying it is
now up to nearly a century.
Patents http://www.uspto.gov/web/menu/pats.html were created to prevent
most knowledge from being kept as trade secrets. They do this by
ensuring, in exchange for exclusive use for a time, the disclosure of
methods. These methods in time fall into the public domain rather than
remain hidden as secrets. Patents have limits to their lifetime
(decades).
Trade secrets http://www.execpc.com/~mhallign/ are typically preserved
by non-disclosure agreements and other means. This gives rise to the
usually jesting comment related to trade secrets, "I could tell you, but
then I'd have to kill you (or hire you)". Trade secrets have no limits
on their lifetimes. For example, the exact formula of Coca-Cola(TM) has
been a trade secret for around a century. Trade secrets can occasionally
be very dangerous to the public good. For example, Coca-Cola(TM)
originally contained cocaine (thus "coke"). As the formula was a trade
secret, how would one know an addictive substance was in it or exactly
how much of such a thing it contained? The same thing happens in
proprietary software -- how do you know proprietary software is really
secure if you can't at least look inside it? Copyright law requires
submitting the source code of a program to obtain a documented copyright
providing certain legal advantages, however large portions of the
submitted code can be blocked out as "trade secrets".
Trademarks http://www.uspto.gov/web/menu/tm.html are a fourth class of
Intellectual Property, and like trade secrets can in theory be owned
indefinitely. Trademarks are effectively "brands", as represented by
names, icons, colors, music, and so on. Their use is to avoid confusion
in the market place -- so that when a consumer buys brand X they know
who they are buying from and are assured of a certain quality. The first
company to establish a significant commercial brand using a trademark
usually wins the right to use that trademark. Trademarks are supposed to
only relate to things that are sold. It is not clear if open source
related trademarks are valid, unless like RedHat(TM) they relate to
goods or services. For example, CoDIAK perhaps could not be legally
trademarked, unless services were sold related to that. With that said,
I think people can get such trademarks -- they may just not be legally
defensible. Remember, while the trademark is seemingly owned, the intent
behind allowing the ownership is for consumer protection (not monopoly).
Historically, copyright and patent owners have lobbied for extensions of
these rights, the latest successful (and I think unfortunate and
outrageous) case being this:
http://www.freedomforum.org/technology/1999/1/21copyright.asp
Some people argue the rise of the internet implies the complete opposite
-- that copyrights and patents should be instead shortened in length to
a decade or less. Of course, these people generally don't have lobbying
dollars or motivation of current IP holders.
However, assuming such extensions do not go on indefinitely, all
information created now, even this email, will at some point enter the
public domain. It may take 100 years in some cases, but it will happen.
Even your diary in a century or two will be in the public domain
(although it might still be kept by your descendants as a "trade
secret"). Never forget when thinking about IP that the long term
constitutional intent of copyright and patent law is to increase the
public domain store of knowledge.
===== the current colloquium license as I see it =====
As things stand now, contributions to the colloquium are under a license
that allows Stanford or the Bootstrap Institute a "Permission to Use"
them.
http://www.bootstrap.org/colloquium/permission.html
This appears to be done so that A) Stanford can rebroadcast the
colloquium and B) The Bootstrap Institute can make various uses of the
contributions in an open source DKR. The original contributor also
retains various rights to their original work.
What does this mean to other people involved in the colloquium?
Basically, to use something contributed to the colloquium, in the
absence of any other license, you need permission from either the
contributor, Stanford, or the Bootstrap Institute. While this state of
affairs is probably adequate for the durection of the colloquium,
clearly it is too one-sided to persist for the long term. If major
contributions are to be made to the OHS/DKR, then they will need to be
made under a license that gives a much wider audience some sort of
permission to use the contributions and redistribute them.
Eventually, presumably, the Bootstrap Institute is going to put some or
all contributions under an open source license. So, what are the
possibilities and issues?
===== three areas of licensing =====
First, there are at least three different areas that are licensable.
These are:
* the code -- meaning actual executable programs and source
* the content -- meaning the words and concepts in email and video and
transcript
* the collection -- meaning the specific compilation of code and
content with perhaps an index or other organization and structure
These three areas do not necessarily all have to be under the same
license. And for each area, items in it do not necessarily have to be
under the same license.
For example, some code could be under the GPL license (utilities?), and
other code under the BSD license (the DKR core?).
Some content might require attribution (manuals?), other content might
only be used without alterations (email?), and other content might be
public domain (link submissions?). Two example content licenses are at:
http://www.opencontent.org
http://opencontent.org/opl.shtml -- similar to the GPL
http://opencontent.org/openpub/ -- prevents modification of opinions
Likewise, multiple collections could be released, each with a different
license -- perhaps one restriction redistribution without payment (a
Stanford course?), or another allowing users to be able to redistribute
subsets of the database (a Bootstrap DKR?).
For a discussion on database licensing issues, see:
http://slashdot.org/askslashdot/99/12/28/151211.shtml
As you can see, there are many complex issues to address. Also, there
may be many licenses. For each area, one or more licenses need to be
decided on and individuals and organizations need to commit to putting
code, content, and a collection under that license.
===== what licenses can cover =====
Licenses cover a variety of possibilities. These include warranty,
intellectual capital accumulation, distribution, originality, patents,
attribution and modification, preferred contributors, advertising,
lawsuits, using trademarks, and implied consent for using suggestions
from users. As you might imagine, there can be problems making pieces of
code available under different licenses legally fit together. People
occasionally suggest there should be one standard license with
checkboxes for each of the possiblities in an area. This would at least
make the legal problems easier to understand and resolve.
===== warranty =====
One issue is a disclaimer of warranty. When information is put in the
public domain, effectively, all warranty is disclaimed. This may not
prevent a lawsuit (if the information is intentionally designed to be
harmful), but barring that, there probably is little risk to putting IP
you legitimately own into the public domain. Typically, people disclaim
all warranties in their license. However, sometimes they provide a
warranty in exchange for some compensation (like when you buy a new
car).
===== intellectual capital accumulation =====
Another issue is the "virality" of the license. This ranges from public
domain, X-MIT, or BSD-revised licenses on one side (no restrictions on
what you do with the code) to GNU GPL on the other side (requiring you
to redistribute modified code if you ship binaries derived from it).
[GPL == General Public License, related to the term "free" software
http://www.fsf.org]
In the middle of this spectrum lies the LGPL (Lesser GPL, or originally
Library GPL) which says you only need to ship modifications to the
original code, but not to your code that statically links to it. Another
license in the middle is the Squeak license, which requires changes to a
core to be redistributed, but allows you to build on that core without
having to redistribute.
I'm ignoring a few subtleties here (static vs. dynamic linking, Squeak
VM vs. classes, etc.), but I think in the main this is a fair summary.
This concept has also been called "Intellectual Capital Accumulation" by
Jim Spohrer and others at the EOE
http://www.eoe.org
who are actively studying this issue.
This virality debate causes many heated arguments in
newsgroup:gnu.misc.discuss and other places. In short, GPL in effect
legally forces users to give back to the community changes to the
source. The actual rules are more complex and have to do with
distributing source with binaries, and allowing users redistribution
privileges. This actually works in some cases, but in other cases many
people avoid GPL code for precisely this reason.
Also, using GPL code at the beginning of a project requires an immediate
commitment to give away the result as open source software, whereas many
projects start out intending to be proprietary but only become open
source over time. These projects might choose to use other open source
packages with less restrictive licenses at the start, and in the end
might make major donations to them.
It is clear that projects like Python show that contributions are made
even under non-viral licenses. There are many reasons to contribute to
open source projects that have little to do with legal compulsion.
A twist on virality is to allow modifications to be proprietary for some
time (a few years) and then to legally force their public distribution.
In theory all code under a license like GPL could also be obtained under
proprietary terms by arranging agreements with all the original and
contributing authors, but in practice the large number of authors on
some projects makes this infeasible (as well as that some GPL using
authors are actively opposed to any proprietary licensing).
Some authors release code under the GPL precisely so they can gain the
benefits of advertising their product and still make deals with
companies to license a proprietary (non-GPL) version of their software.
This strategy only works if the product codebase has no other GPL code
from other authors.
===== distribution =====
Another issue is restrictions related to distribution. These
restrictions form another group of licenses -- generally not considered
"open source". Typical proprietary software licenses like most of
Microsoft's simply prohibit redistribution to anybody (and even may
prohibit making more than a certain number of backup copies). Other
licenses restrict by classes of user -- like prohibiting commercial use
without a payment but allowing home or educational use. Some prohibit
use beyond a certain scale (numbers of users, size of database, etc.).
Others prohibit use beyond a certain time. Other restrictions might have
to do with visiting a web site to download the product or looking at
advertising. Generally these restrictions have to do with a profit
motive.
However, some distribution restrictions may have to do with legal or
liability obligations. For example, U.S. companies and individuals are
prohibited from doing business with certain countries and individuals
identified by the U.S. Department of State as supporting terrorists
(Libya, Iraq, etc.). It is less clear where open source software fits on
this -- I think (but IANAL) as things stand now you can put open source
code without such a restriction which you are not selling on an
internationally accessible web server, but you could not ship it (say in
email) to people in such countries. (I remember one admonition in a
shareware FAQ saying if you ever do get a registration check from
someplace on the State Department's list you should burn it!) Other
software might need to legally prohibit minors from using it, or might
prohibit people from using it in various U.S. geographical locations
with restrictive laws. Other limitations might be to prevent use for
certain classes of activities with a high cost if there was a potential
failure, like aviation or medicine or nuclear power.
Finally, other restrictions may have to do not with distribution of the
code, but its use. Like, for legal reasons, one might prohibit a music
synthesizer from generating blue box tones (to control telephone
payments). It is not clear to what extent one needs to prohibit illegal
use of software by licenses if the act itself is illegal. However, law
allows "contributory" claims, where one might argue the software vendor
has contributed to making it easy for someone to break the law
(copyright or otherwise). Various MP3 related programs or search engines
are now facing such claims.
http://slashdot.org/articles/99/12/08/0752248.shtml -- Napster
http://slashdot.org/articles/99/03/24/1230235.shtml -- Lycos
[Do I risk contributory infringement related to MP3 pirates by pointing
to articles that point to other news articles about infringement that
point to the home pages of systems that might point to infringing
media? Where does it end?]
===== originality =====
Licenses may put obligations on the contributor to a set of code or
data. Typically, to show a good faith effort to avoid infringement of
proprietary Intellectual Property (IP), a license might require that
contributors have either created the work originally, or they have
whatever rights in the work are necessary to contribute it. The
Colloquium license includes such a provision. This provision may not be
in the redistribution itself, but may exist as a repository of licenses
kept by the license maintainer tied to every contribution.
Python is working towards such a repository -- since otherwise corporate
users may be reluctant to use an open source product. Imagine the
problem down the road if you were to find out a major system was either
stolen code or was done by someone employed by a company whose engineers
all sign agreements that the company owns everything they do.
Incidentally, such agreements are a reason many individuals at major
companies cannot legally contribute to open source efforts without some
sort of official approval from their company.
For an example, of what the Python project makes contributors sign, see:
* CNRI's legal policy regarding contributions to Python
http://www.python.org/1.5/legalfaq.html
* Signature Form (substantial contributions)
http://www.python.org/1.5/wetsign.html
* Contribution Release Form (minor contributions)
http://www.python.org/1.5/bugrelease.html
* General contribution information
http://www.python.org/1.5/patch.html
It is easy to get bogged down in a situation where you don't have
statements of originality or other disclaimers, needed eventually so
that users at companies with deep pockets can show at least a good faith
effort to avoid infringement or liability.
===== patents =====
Licenses often make statements about the degree to which patents used or
described are useable. Under the GPL, patents embodied in the code must
be freely licensed to everyone or the code cannot be distributed under
the GPL. This is one reasons why a large company with an existing patent
portfolio might be hesitant to use the GPL -- it is not clear what they
are giving away. Other licenses (like some early versions of the IBM
Public License) may only allow licensing of related patents if a certain
percentage of code is included. Others might require some sort of patent
licensing to use the code (MP3 decoding?), even though though the code
itself might be distributable (just not useable!).
Note that usually just describing a patented method does not constitute
use or infringement. For example:
http://www.patents.ibm.com/
includes information on many thousands of patents in great detail. I'm
especially interested in this issue in the context of creating
collections of material about manufacturing. It is not clear to me what
the meaning of the GPL would be if applied to such a collection of
information about patents.
===== attribution and modification =====
Licenses often make statements about attribution and modification
rights. Some licenses require attribution if the code or content is
used. Some require modifications be clearly marked. Others allow no
modifications, only inclusion. For cases where these make sense,
consider a book you write which describes how to use Microsoft Visual
C++, and at the same time says what is wrong with the product. You might
want to allow people to copy this freely, but not allow someone to edit
out your opinions of Microsoft products.
===== preferred contributors =====
Licenses may also give special provisions to a class of users. The
"owner" of the license get contributions under preferred terms, and gets
to use these contributions in proprietary ways. Alternatively, creators
may have two versions -- an open one (say under the GPL) and a
proprietary one. They may require contributors to allow the contribution
to be also used in the proprietary version (by demanding the contributor
sign somethign with language that basically says the original owner can
use the new contribution however they wish.)
===== advertising, lawsuits, using trademarks =====
Licenses have some other roles. Some licenses (particularly the original
BSD license, but no longer) require advertising involving the product to
acknowledge the creator of the product. Licenses tell you who to sue if
something goes wrong. Licenses may prohibit you from using the author's
name or trademarks in certain ways. Licenses link code to creation dates
and the copyright system.
===== implied consent for using suggestions =====
Many software licenses included an implied consent provision that if you
contact technical support, they can use your suggestions in new products
and new versions without compensating you. They often can also use any
other data the find out about you in creating future versions of the
product (computer hardware / OS / configuration, etc.). Most Microsoft
EULAs contain this clause.
===== problems making licensed code fit together =====
Some of these license provisions are incompatible. So for example, older
BSD style code with an advertising clause could not be merged with GPL
code (which prohibits such a requirement). Similarly GPL code cannot be
merged with code with commercial redistribution restrictions. I'm not
entirely sure about whether one can merge GPL code with code with export
restrictions, like Squeak http://www.squeak.org .
===== some further comments on licensing issues =====
A comment on license enforcement. Publicity is often the way open source
license (particularly GPL) are enforced. If a company does not adhere to
an open source license, everyone publishes that fact and the company
looks bad. Many (or all) of these licenses have not been tested in
court.
A comment on public domain. It is commonly claimed that if you put
something in the public domain a company can come and make a minor
change and copyright it. This is true, but it does not prevent someone
from accessing an original copy of the public domain work if they can
find it and using that.
Similarly, various laws related to slander for example would prevent
someone from taking your work and modifying it in such a way that it
makes it appear you are incompetent or hold opinions you did not
express. It is not always necessary to have a license protect you
against things that laws protect you from. (This from a recent slashdot
discussion on this issue.) Going a step further, if there are key issues
related to attribution that seem really important, it may be worthwhile
to pass laws related to them rather than try to enforce them in
licenses. It might be fun to think through the legal laws that a OHS/DKR
might need to run well.
A related issues is the notion that one should not legislate morality.
If one thinks making attributions, giving back changes, documenting
changes, and so on are moral obligations, then perhaps one should have a
moral code of use rather than a legal license. I myself tried to create
a "moral license":
http://www.kurtz-fernhout.com/oscomak/license.htm
but it has not attracted much interest so far.
A comment on content & collections vs. code. Code often can be shipped
as obscured binaries. Content or collections usually are shipped in a
way that makes them accessible for copying or modification. Thus, some
built-in possibilities for maintaining control over code while providing
utility (hiding the source, but making the binary freely
redistributable) are not as easily doable with content or collections.
A comment on ownership. In general, if you publish or contribute code
under one license, you are free to publish it under another. However,
you can sign over control of code to others completely, and this is
commonly done when work is created for hire.
===== avoid new licenses ======
A comment on new license creation. There are too many licenses already,
so creating a new one is to be discouraged over using existing ones.
Every new license needs to be reviewed by legal counsel at a large
company before they will use this. This adds another delay to adoption
of the code. Lawyers tend to love to make custom licenses and stuff the
kitchen sink of provisos into licenses (like a recent effort by Corel to
prevent people under 18 from using Linux under the (untrue) thinking
they aren't otherwise potentially bound by shrink-wrap contracts).
http://slashdot.org/articles/99/11/25/1943208.shtml
This tends to just create more work for other lawyers, who need to read
these things in detail. Some of these provisions may be covered by other
laws related to commerce and fair use. In the case of the Corel issue,
minors' use of software is presumably convered by their guardians' legal
rights and obligations.
===== some links =====
Some general pointer to open source / free software license information:
http://www.opensource.org
http://www.fsf.org
Some open source license / free software examples:
http://www.opensource.org/licenses/
http://www.fsf.org/philosophy/license-list.html
Microsoft has done a wonderful (if biased) summary of various licensing
systems, in their infamous "Halloween" memos on how to subvert Linux,
especially "Software Licensing Taxonomy":
http://www.opensource.org/halloween/halloween1.html
Microsoft's comments on licensing:
http://www.microsoft.com/DirectAccess/Products/Licensing/faq.asp
A typical restrictive Microsoft license:
http://www.microsoft.com/TechNet/WCE/tools/termsvr.asp
===== questions to ask about OHS/DKR licensing =====
So after all this, the first two big questions:
* How many different OHS/DKR systems embodying collections of code and
content will there be, and will all these systems be under the same
license?
* For any given system, will the three areas (code, content, collection)
be under different licenses?
In addition to those two big questions, for all license here are a host
of small questions:
* Will the licenses provide any warranty?
* How viral will they be? (Or what parts will be viral?)
* Will they restrict distributions to any class of user?
* Will they require legal restrictions on distribution or use?
* Will the make explicit the originality or IP status of contributions?
* What will they say about patents embodied or described?
* Will they require attribution or limit modifications or removal of
opinions?
* Will there be special classes of contributors who have more rights
than others?
* Are there restrictions related to advertising?
* Who is sue-able if something goes wrong?
* How are creation dates maintained to know when parts go into the
public domain?
* Will there be a provision that suggestions from users can be added to
the product?
* How do these licenses interact with existing license?
===== a strawman proposal =====
One possibility:
* Code: Individual pieces are either MIT-X/BSD-revised-like
http://www.x.org/terms.htm or GPL . (Leaning to X).
* Content: Primarily X. Might want to consider open content for some
things. However, again, there might be a mix of content licenses.
* Collection: X?
Effectively, everything that doesn't otherwise have a special case
reason should be under a license that is like MIT-X/BSD-revised/Python
-- just a disclaimer of warranty and statement of the date and author.
Of course, someone from the FSF would argue everything should be GPLd.
Or, one might just decide to make it all public domain right now (rather
than wait for copyrights to expire). Things fragment (fork) much more
rarely than one would expect.
http://www.tuxedo.org/~esr/writings/homesteading/homesteading.html
So, perhaps the default really should be "public domain". Then argue
your way up from there into more and more restrictions for code,
content, and collection for various reasons.
===== conclusion =====
This license stuff may seem boring and complex (a difficult
combination!). But, it is essential to address these issues if the
products created by the Bootstrap Institute and colloquium participants
are to have any hope of evolving in the way the creators intend.
A first step is to figure out what it is exactly the creators of the
license (and other participants) want to accomplish (the goals). From
there, one needs to choose or create licenses that are most likely to
accomplish those goals.
When creating an open source license, one is to an extent crafting a
"constitution" for a collaborative effort. Of course, the organizations
that work with such systems may themselves have their own constitutions,
and one needs to be aware of the extent to which those constitutions of
tool and user will cooperate or clash.
In the flavor of bootstrapping (and democracy), perhaps these IP
constitutions need to have a process for amendments, so they can improve
over time. How to do that, I am not sure. The GPL has a provision of
including a section that says you may choose the terms of this license
or any later one from the FSF (giving the FSF sole control, although as
a non-profit is is accountable to the public interest and its charter).
It is not clear in a software effort who the citizens are (users,
creators, beneficiaries?) or at what times they could exercise voting
rights or other formal means of influencing the license. It is also not
clear people would want to contribute to a license that might change in
ways the original contributor might not approve of.
So -- many, many complex issues. But, in my opinion, some commitments to
specific licenses need to be made before people will make major
contributions to an OHS/DKR.
-Paul Fernhout
Kurtz-Fernhout Software
=========================================================
Developers of custom software and educational simulations
Creators of the open source Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com
All trademarks are those of their respective owners.
--------------------------- ONElist Sponsor ----------------------------
Get what you deserve with NextCard Visa. ZERO. Rates as low as 0
percent Intro or 9.9 percent Fixed APR, online balance transfers,
Rewards Points, no hidden fees, and much more! Get NextCard today and
get the credit you deserve. Apply now. Get your NextCard Visa at
<a href=" http://clickme.onelist.com/ad/NextcardCreative3CI ">Click Here</a>
------------------------------------------------------------------------
Community email addresses:
Post message: unrev-II@onelist.com
Subscribe: unrev-II-subscribe@onelist.com
Unsubscribe: unrev-II-unsubscribe@onelist.com
List owner: unrev-II-owner@onelist.com
Shortcut URL to this page:
http://www.onelist.com/community/unrev-II
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 18:56:43 PDT