From: Paul Fernhout <email@example.com>
Eric Armstrong wrote:
> Any chance of boiling it all down to a set of recommendations,
> and keeping the original for background?
> (He asked, with eyes crossed...)
Thanks for the question and the other comments.
It is difficult to me as an individual to make a pronouncement on a
license because it should reflect the shared values of the (would be)
participants and contributors of possibly more than one effort. However,
I will try to simplify things somewhat.
=== how many licenses ====
Paul Fernhout wrote:
> 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
There are already many open source efforts around the world with various
What the Colloquium and Bootstrap Institute decide will reflect group
dynamics. Obviously, it seems on the surface it is best to have one
common license, however evolutionary flexibility might argue against
Obviously though any one effort is in part shaped by its license. The
only variant of this is the idea of a constitutional license, and I am
not sure how to make such a thing workable (except as happens in
practice if all major contributors get a consensus).
This issue of a common license becomes most important if the licensing
strategy or constitution become tied to a trademark owned by an
organization. Thus the "Apache" or "Open Source" trademarks can have
legal teeth. If we had a "Bootstrap" or "CoDIAK" trademark, then there
could be a stronger argument that everyone contributing to something
under that trademark would need to abide by a common set of rules,
enforced by the trademark owner. Of course, like with "Open Source"
trademark, those rules might allow several licenses.
> * For any given system, will the three areas (code, content, collection)
> be under different licenses?
I think it is best if one well known license like X or GPL covers all
because this is easiest to understand.
However, in practice one license may not be adequate, especially for the
==== answers to little questions =========
Paul Fernhout wrote:
> In addition to those two big questions, for all license here are a host
> of small questions:
> * Will the licenses provide any warranty?
Of course not!
> * How viral will they be? (Or what parts will be viral?)
> * Will they restrict distributions to any class of user?
Not for open source.
> * Will they require legal restrictions on distribution or use?
Not for open source, except maybe export restrictions.
> * Will the make explicit the originality or IP status of contributions?
Sounds like a good idea.
> * What will they say about patents embodied or described?
> * Will they require attribution or limit modifications or removal of
> * 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?
Too long to think about.
> * Will there be a provision that suggestions from users can be added to
> the product?
> * How do these licenses interact with existing license?
No easy way to tell.
==== consolidating the open issues ====
So, I assume warranty will be disclaimed, no restrictions will be made
to class of user, no *explicit* restrictions will be made to export (X
doesn't), no special class of contributors will exist, no advertising
requirements are present, no one wants to be sue-able, there is no
special concern about creation dates, and no provision are put in for
users to be forced to give up improvement ideas.
As a "due diligence" precaution, contributors to a centrally managed
repository should be required to make a statement of originality or
sufficient ownership of rights to allow the contribution to be used
under the distribution license. However, this does not have to be in the
The most import unresolved issues of the list are probably:
* viral or not
* patent assignment or not
* attribution requirement or not
* modification rights or not
The choice on these issues will be the biggest determiner of what other
licenses the code and content can interoperate with.
I can think of several realistic alternatives:
1. Everything (code, content, collection) is put in the public domain
2. Everything (code, content, collection) is put under the GNU GPL
3. Everything (code, content, collection) is put under the
X-MIT/Python/CSD-revised license (disclaimer of warranty only)
4. More complex variations of (3) with statements about patents,
attribution, and modification rights
5. Assuming everything will be contributed under various licenses with
various patent and virality and modification and attribution
requirements, and simply making a collection license (viral or not)
==== my current thinking on these open questions ======
Here is my current thinking on things (and I may revise it, especially
if people provide feedback!):
Patents: Personally, I think these should have never been allowed for
software. They are not allowed in much of Europe. I think this should
not be a big issue in the license. If a software patent is infringed,
people can code around it or get the patent holder to make a special
exception. Hopefully, if this project takes off, this codebase itself
will represent prior art to invalidate later patents. We then allow the
possibility of companies owning patent rights related to their
contributed code and later trying to charge for the patent to use it,
but I think this is an acceptable risk. In the U.S. companies must
patent something within one year of public release or offering for sale,
and this limits the scope of the exposure. I prefer this to the risk
that people working at major companies cannot contribute because their
IP department doesn't like the patent clause. Conclusion: If we go with
the GPL fine, otherwise, don't worry a patent clause (famous last
Attribution and Modification requirements: While I could invent many
plausible scenarios, I think in practice they are all legally
unworkable, except perhaps for large independent works. I think some
versions of the DKR/OHS system should be designed to enforce preferences
regarding this, but I do not think we should make an explicit legal
statement about this. In part again this is because this is a slippery
slope, these claims should perhaps be morally enforced (or legally
outside the license), and legal restrictions may inhibit participation
and use of the codebase by large corporations. However, for an
alternative approach, see the Open Content discussion:
Virality: This is the toughest issue. I waffle on this. My wife and I
put six person-years of work (our garden simulator) under the GPL, so
obviously this license has some attraction. The GPL is well known and
the required openness has a certain value. On the other had, the GPL and
other quasi-viral systems like Squeak & LGPL make things harder to get
into various companies. And because of this, less people use GPL code
and many people reinvent it. One can also try clever ways to get around
these restrictions -- creating clubs where only club members agreeing
not to redistribute get the code, or the more usual way of creating
loosely coupled systems with dynamic linking or network connections
between modules, or the most usual way of getting around the GPL --
reinventing the wheel. So I don't have a final answer on this. Right
now, I might say for this effort, given the history, non-viral at all is
the way to go (so not GPL). You might say Linux succeeds because of the
GPL -- I would point to BSD (UNIX) or Python and say not necessarily.
This can be a very emotional issue. These licensing issues can be very
divisive and one needs to tread carefully.
So, I'd recommend (if forced to pick one license right now): MIT/X-like
for everything, simply because people will feel more comfortable having
a specific license they can point to over public domain.
If there was a huge outcry, I could probably be convinced to go GPL for
everything. But, I could still be convinced to put everything in the
public domain too. Or I might accept a lincense more like IBM's for
JIKES. Sorry to seem wishy-washy on this. It is not clear what license
is best in terms of getting industry participation, gaining independent
developers, managing content fairly, maximizing intellectual capital
appreciation, and avoiding legal liability.
==== MIT License ===
It would be worthwhile to examine the exact text of the MIT/X license:
Here is the body of the license:
Copyright (c) <year> <copyright holders>
Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
The above copyright notice and this permission notice shall be included
in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
===== other possibilities =====
But, here is another alternative. Xanadu for example wanted to allow
multiple ways of licensing rights. One could build into the DKR/OHS the
ability to add data with different licenses, and selectively copy data
based on license when the repository was cloned. There would still need
to be license for key content or code related to the DKR/OHS itself, but
not for other usage of the repository. So a license decision is mostly
made for core code (X-like?), with other code and any content considered
independent modules under various licenses, and the collection aspect of
it under a simple disclaimer license (or public domain). This also
gives the creator of a topic-specific OHS/DKR much flexibility. They
might choose to require all participants to make their contributions
available under some license.
===== conclusion =====
We need to start with an open source license for code, content, and
collection for the first OHS/DKR. This issue need to be addressed
officially and legally by the Bootstrap Institute (or, failing that,
Stanford who also owns the rights) after consultation with qualified IP
The license decision can probably still be delayed for some time based
on "good will" regarding the Bootstrap Institute and espoused goals, but
eventually a decision needs to be made if major contributions are to be
made by individuals.
I would urge Bootstrap to make the initial OHS/DKR code available under
a well known license -- either X-like or the GPL (and probably X). The
initial content (including the OHS/DKR specifications) also needs to be
released under a specific license. However future contributions might be
allowed under different licenses.
These licensing requirements faced by Bootstrap/Colloquium are more
complex and cover more ground than most open source projects. This is
because an OHS/DKR explicitly covers code, content, and the collection.
Further, the Bootstrap process intends on making improvements and
transformations of all those (perhaps including the license). So, these
licensing issues are very core to what Bootstrapping is about and need
to be understood by many people and discussed in detail. It is possible
some entirely new sort of IP license or constitutional licensing process
might emerge from this.
If it is Bootstrap's intent to retain more control over the OHS/DKR,
then they may pick something more like the open source IBM license for
JIKES (a Java compiler):
I am not sure whether this would be good or bad. The provision for who
can make new license verions would have to be discussed at the very
I am not a lawyer. I cannot make legal pronouncements. Many of these
legal issues are new and have not been fully tested in court. Some of
what I have said may be in error or may be biased or may omit key
issues. This license decision making process needs to be collective in
part to compensate for errors, bias, and omissions.
==== a way to think though feelings on licensing issues ====
As a final strawman suggestion: perhaps someone could explain why the
OHS/DKR source and initial contributions cannot just be put in the
public domain. Why wasn't the "Right to Use" agreement just a statement
that "everything contributed is put into the public domain"? That
discussion will lead to an understanding of how people in the colloquium
and at Bootstrap feel about issues like IP, ownership, trust,
recognition, control, hope, fears, lawyers, history, collaboration, and
Developers of custom software and educational simulations
Creators of the open source Garden with Insight(TM) garden simulator
--------------------------- ONElist Sponsor ----------------------------
Want To Be Showered With Kisses?
Visit eGroups Valentine Gift Guide
<a href=" http://clickme.onelist.com/ad/SparksValentine9 ">Click Here</a>
Community email addresses:
Post message: unrev-II@onelist.com
List owner: unrev-IIfirstname.lastname@example.org
Shortcut URL to this page:
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 18:56:43 PDT