...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...

...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...

...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...

...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:

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.

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.

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

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:

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

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

...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.

[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

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:

...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 they 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 Fogether

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...

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":

...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).

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:

Some open source license / free software examples:

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":

Microsoft's comments on licensing:

A typical restrictive Microsoft license:

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?

• 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?

  
  

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.

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.

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.

Sincerely,

Kurtz-Fernhout Software

Paul Fernhout
pdfernhout@kurtz-fernhout.com