Softpanorama Bulletin
Vol 13, No.03 (July, 2001)

Prev | Contents | Next

Chapter 3: The Idea of Dynamic Licensing

Dr. Nikolai Bezroukov
Draft (version 0.76)

Prev | Contents  | Next

Copyright 2000-2011, Nikolai Bezroukov. This is a copyrighted unpublished work. All rights reserved.

Contents

Abstract

Introduction

3.1. Licensing taxonomy

3.2 The possibility of the formal software license specification

Abstract

Let's try to approach the software development as a process similar to biologic with stages of childhood, adolescence, maturity, and subsequent decline and death.  This approach presuppose that the license should be viewed not as a static (casted in iron) document, but is an dynamic algorithm that perform balancing of the requirements of various user groups on different stages of development by activating different modules on each of such stage. One important warning is that you generally you never try to remove the previous license, but you can add to it a new one that is better suited particular stage of development. Removal of GPL typically invoke "GPL jihad" run by "true believers" and that's the last thing you want to experience as a developer of a free open source software. We will try to provide a software licensing taxonomy based on rights of major user subgroups  ( author, user, contributors and developers of derivative products) that compose a virtual multidirectional space and that, like for spaceship entering atmosphere, there is a trajectory of the product in this space; some trajectories are better for the survival of the crew.  The author stresses the value of algorithmic simplicity of the license as an important factor of success of the mature free/open software product.

Introduction

That's return to the earlier discussion of  the four major subgroups of users that software license addresses. Those subgroups of user space can be considered as a variables on which the license operates. I propose to partition this user space into five sub-dimensions:

• authors (original contributors);

• users;

• distributors;

• contributors;

• creators of derivative works.

Those stakeholders have conflicting interests. As Jessica Litman noted in New Copyright Paradigms:

Current copyright stakeholders have their eyes on the size of their slices of pie. The question of what balance should be embodied in the copyright law is liable to get lost in the bickering. In the current scheme of things, it is nobody's job to look out for what "should" be the law.[41] But the question deserves to be asked more thoughtfully than the reflexive invocation it commonly receives as a prelude to an argument that the copyright law needs to be further clarified in the speaker's favor.[42] To determine what balance the copyright law should strike, we need to step back from seeking close analogues to activities and devices that current law deems lawful or infringing. Rather than diverting our attention with debates over whether personal computers are indeed akin to printing presses, or copyright protection devices mere siblings to automobile door locks, we need to ask more basic questions. Here is one: The essential balance embodied in the copyright law, which has been characterized variously by an assortment of actors, is a balance between giving copyright holders enough control over their works to permit them to exploit them commercially, and allowing the rest of the world sufficient access to those works to permit us all to read, see, listen to, use, reuse, learn from, and build on them, and thus promote the progress of Science and useful arts. The copyright laws we have relied on until now pegged the owner's control to reproduction, because that made functional sense. In a digital world, it may not. If we want a copyright law that balances copyright owners' control with public access in a way that enables all of us to use copyrighted works and to create new ones, are there ways to define the nature of that control and access that are more suitable for a digital age?

If we assume that on each stage of the development of software product we need to  balance (with probably conflicting) requirements of each of those subgroups, a software license can be views as an algorithm that should be designed (and debugged ;-) to solve this particular optimization problem. The idea of formal language for the software license is introduced using two simple examples. in which software license is viewed as several "license modules" that address requirements of a particular user group glued by some control structure. I will show that Perl GPL/Artistic license can be considered to be the first algorithmic license that got a widespread adoption and as such proved to be more flexible and better serving the need of each of user groups that each of the sublicenses it includes (especially GPL alone). The second example introduces the idea of  adding separate set of requirements applicable the creator of derived products sublicense that distinguish between changes that adhere to the standards of the base application (compatible changes) and changes that breath exiting API or standard (incompatible changes).

Copyright law exists mainly to encourage people to create and publish works.  The idea of copyright is to balance the interests of the author and the interests of the public. Naturally there are many ways to balance the interests of the authors with the interests of the public and this balancing requirements change with time. The idea of synchronizing licensing changes with the stage of the lifecycle that product reached product a certain phase (for example phase when the original developer steps down) is discussed and one such licensing algorithm is proposed.

The possibility of creation of a more formal "licensing language" similar to P3P is suggested. I also advocate dynamic licensing as an innovative way to overcome the deficiencies of any "atomic license" be it BSD or GPL or whatever and use the "license modules" that are best suitable for a particular stage of the development of the product. As Perl license shows modules can be simply added without removing previously existing modules. 

It is natural to suppose that  existing methods of balancing such interests are historically limited and need to adapt to social and technologic changes. This paper suggest one possible way that permits such an adaptation by segmenting public into several segments and analyzing interests of each of those segments as a separate group.

It's important to understand that those licenses do not exist isolated. They are all interconnected and represent a certain point in the multidimensional  free/open software licensing space. Actually they also implicitly interact and influence each other but this (gravitational) factor is not incorporated in the proposed model.

This process of balancing interest of public and interests of the author can considered as a process similar to mixing in a different proportion several basic colors. I would suggest that in software licensing the part of the public that is interested in the participating in the development and that is able to modify and enhance the software should be treated as a separate player. That means that in a software license we need to balance the interests of three major players: the initial developers, the users (part of public that generally is not interested in modification o f software belong the correction of errors), contributors (part of the public that is interested in enhancing the software feature, polishing code, etc.) and the creators of derived works. For the latter the original package often serve as a part of foundation for creating a different product. The most complex case arises when derived product directly completes with the original for users and contributors. That's why I think that a promising way to look at various software licenses is to present them as points in some multidimensional space with the following coordinate axis:

• The level of protection of the rights of the principal author(s), the copyright holder

• The level of protection of  the regular users right

• The level of protection of the co-developers/contributors rights

• The level of protection of the developers of the derivatives works rights (those right can conflict with the protection of righs of the original author).

Such graphical approach to the description of the whole spectrum of free/open source software licenses might be useful in understanding that some of the  requirements imposed by this three-dimensional model are mutually contradictive and that attempt to strike a balance between them is a pretty difficult undertaking that might well benefit from the algorithmic approach.  One might say that software licensing such a multidimensional represents space of authors, users, contributors and the creators of derivative works is a classical situation of "chose any two". This means that the licenses can be considered as a algorithms to solve rather complex problems and attempts to find a reasonable compromise between all three requirements requires some kind of algorithmic thinking.

That also suggests that modularization of the license on separate "subroutines" or "modules" can be an effective way to deal with the complexity of software licensing and that algorithmic thinking about the software license might represent an attractive approach for creation of future licenses.  Right now I just want to stress that the success of Perl who pioneered this approach with its dual licensing scheme can be interpreted as a simple if-then-else statement with two independent subroutines. The main idea of the paper is that more complex algorithms can be used. For example the license algorithms might provide a subroutine that is activated after a certain number of years of the product life or after a particular version was superseded by a certain number of  commercial versions. For example activation of a certain subroutine in time can help to solve that the legal problems of the pretty popular abandonware movement. Although this topic is beyond the scope of the paper I would like to note that like free/open software abandonware movement can serve as a pretty convincing illustration of the limitation of the current licenses. But this is a pretty complex phenomena in its own right and as such it deserve its own analysis that is beyond the scope of this paper.

Note. One very common misconception is widespread confusion of "GPLed software", and "Open Source". Open source is actually an umbrella term that includes BSD and several other less significant licenses. It often  more correct is to distinguish between the three major players in this area:

1. BSD and other non-discriminating "pro bono" licenses (X Consortium license, MIT license, Apache license, etc.).

2. The orthodox GPL camp (pure GPL licensing and LGPL licensing).

3. Everything else including dual licensing (Perl, Open Office), Artistic license, large corporation open licenses (IBM license, Sun license, Lucent license); public domain, etc.

My impression is that those are approximately three equal forces in free/open source licensing. Actually the BSD camp might have the  biggest share softwarewise although due to Linux success GPL camp lately got all the ink.  If we add free/open source software written for three major flavor of BSD (Free, Open and NET BSD), X consortium license and Apache license, then "pure GPLed" software represents  less that one third of the total volume of  "free/open source" code universe (with dual-licensed representing the second major player after BSD) Open Office as a major free/open source software package).  Even within the Linux community where GPL is generally more popular that other licenses GPL it is far from being overwhelmingly dominant. The following October 1999 posting to the license-discuss list provides some statistics on the popularity of various licenses in such "citadel" of GPL as the Freshmeat website -- website now owned by VA Linux. If one take into account the date of the survey and the subsequent decline of popularity of GPL due to the negative effects of KDE jihad (see below) one probably can agree these figures can give a reasonable approximation of the upper limit of popularity of the pure GPL license in the Linux camp. Taken into account of the low survival rate of small GPLed projects often launched by students during a study of a particular area of computer science and abandoned after that (so called v. 0.1 software) it is even more close to upper limit also because it does not distinguish between 'alive" and dead projects. 

Date: Fri, 15 Oct 1999 10:45:11 -0400
From: "Forrest J. Cavalier III" <[email protected]>
Subject: license counts
To: [email protected]

-------------------------------------------------------------
Count of "license type" field of freshmeat.net

15-Oct-99         4-Mar-99     License type
count   ratio   count   ratio
-------------------------------------------------------------
1       0.000   0       0.000   Eiffel Forum Freeware License
2       0.000   2       0.001   AFPL
2       0.000   0       0.000   Apache style
2       0.000   0       0.000   IBM Public License
9       0.002   2       0.001   QPL
14      0.003   7       0.003   source-available commercial
15      0.003   9       0.004   MIT
21      0.004   6       0.002   MPL
22      0.004   0       0.000   Artistic & GPL
39      0.007   10      0.004   Free Trial
48      0.009   23      0.009   Shareware
59      0.011   82      0.032   unknown
78      0.014   26      0.010   Public Domain
82      0.015   39      0.015   commercial
117     0.022   56      0.022   Artistic
171     0.031   82      0.032   BSD type
180     0.033   74      0.029   free for non-commercial use
208     0.038   92      0.036   LGPL
211     0.039   177     0.070   free to use but restricted
226     0.042   104     0.041   OpenSource
241     0.044   106     0.042   Freeware
263     0.048   118     0.047   freely distributable
3419    0.630   1510    0.598   GPL

Free/open software licenses are a complicated legal area.  In case a developer face the necessity to navigate legal minefield successfully he/she needs not only  understand your potential rights and obligations, he/she also need to interpret the many provisions of the license according to the established legal practice and apply them to the particular case.  The latter requires obtaining a legal advice from the  lawyer.  The approach adopted in this paper is techno-sociological and while offering some insights it does not, and cannot, represent any legal advice.  

Licensing Taxonomy

The broad categories of licensing include (for an attempt of classification of existing software licenses from GPL position see Categories of Free and Non-Free Software - GNU Project - Free Software Foundation (FSF): 

Commercial software

Commercial software represents the majority of software purchased from software publishers, commercial computer stores, etc. Formally, when you buy software, you are actually acquiring a license from the individual or the company that owns the copyright. The conditions and restrictions of the license agreement vary from program to program. In general, commercial software licenses stipulates the maximum freedoms for the authors of software and minimum for users and co-developers. Among typical requirements:

 (1) per copy fee for licensing,

(2) prohibition of unauthorized coping and distribution; although an archival copies of the software can be made, the backup copy cannot be used except when the original package fails or is destroyed,

(3) modifications to the software are not allowed even if the user legally obtained the source from the copyright holder,

(4) recompiling (i.e. reverse engineering) of the program code is not allowed without the permission of the copyright holder,

(5) development of derivative works without the permission of the copyright holder is explicitly prohibited . Sometimes even upgrades from the software publisher require the proof of ownership in a form of the original distribution CD or floppy disk.

 

The main problem of a typical commercial software license is insufficient protection of fair use rights that among other things led to an the creation of pretty influential "abandonware" movement. Front-loaded sales schemes, such as "subscription" services or high-cost toolsets also discriminate against small- to medium-scale developers.

Demo and evaluation software

Demo and "Evaluation" software are usually functionally limited versions of commercial software which can be freely downloaded and sometimes freely re-distributed. The idea is to drive purchase of  the fully-functional commercial version. The most typical examples include 60-day time evaluation versions.

Shareware

Shareware products are fully functional and freely re-distributable, but the license mandates eventual purchase by both individuals and corporations after a certain period of time. This eventual purchase can be stimulated by periodic reminder or other means. Major compression utilities in Windows environment (like Arj, Pkzip, Rar, WinZip, etc) are distributed this way. Shareware is generally more user friendly type of software than pure commercial software and some types of shareware are fully functional in non-register version. A lot of various adds-on and enhancements to Microsoft Windows are distributed this way (among them especially popular are graphical programs, Notepad replacement, File manager replacements and add-ons, better ftp clients, telnet clients, network utilities, etc.). The shareware market is pretty noticeable in Windows environment with many excellent products.

Free for non-commercial Use Only

Non-commercial use software is freely available to non-profit organizations and institutions. It usually is re-distributable only by this entities too. For corporations this license is very close to Shareware license. 

For educational use only:

That type of software id similar to free for non-commercial use only but usually targeted at educational institutions and often comes as supplements to the books or other instructional materials.

Freeware

Freeware is software which may be freely used and distributed in binary form only. This software is covered by copyright and subject to the conditions defined by the holder of the copyright.  In general, freeware software licenses stipulate that (1) the software is covered by copyright, (2) copies of the software can be made for both archival and distribution purposes but that distribution cannot be for profit, (3) modifications to the software are allowed and encouraged, (4) reverse engineering of the program code without the explicit permission of the copyright holder may or may not be prohibited, and (5) usually the produict can be included is a in a derivative works is allowed and encouraged with the condition that derivative works must also be designated as freeware. That means that you cannot take FREEWARE, modify or extend it, and then sell it as COMMERCIAL or SHAREWARE software.

Some freeware vendors  explicitly prohibit reverse engineering of such software. Microsoft Internet Explorer, Outlook and several AOL products fit this model.

Advertising supported freeware (Eudora, Netscape, etc.)

This is a special type of freeware with one additional restriction in the user space: a user is prohibited from blocking special advertising messages that the product may display in the initial windows or periodically on in a special windows on the screen.
 

Free (Royalty free) libraries

Free libraries include a source code that can freely used and distributed long with binaries. The source code may not be modified by the user without violating the license. For example C++ and Java class libraries, header files belong to this category.

GNU license

CopyLeft or GPL (General Public License) based software is different from BSD license and it's derivatives (Apache license).  Whereas BSD style licensing permits users to "fork" the codebase under your own license terms (e.g. make it commercial), the GPL license requires that all derivative works must also be released under GPL. You are free to modify this code as long as your derivative is publicly available in source form and also modifiable on the same terms.

Plan 9 style -- contains some interesting restriction on modification of software:

3.2 You must cause all Licensed Software to which You contribute, i.e. Your Modifications, to contain a clear identification, e.g., a separate file, documenting the changes made by You and identifying You as the Contributor that reasonably allows subsequent Recipients to identify the originator of the Modification. To the extent You create at least one Modification, You may add Your name as a Contributor to the requisite notice described in Section 3.3.

You agree to provide the Original Contributor, at its request, with a copy of the complete Source Code version, Object Code version and related documentation for Modifications created or contributed to by You if used for any purpose. Original Contributor and/or other Contributors shall have unrestricted, nonexclusive, worldwide, perpetual, royalty-free rights, to use, reproduce, modify, display, perform, sublicense and distribute Your Modifications, and to grant third parties the right to do so, including without limitation as a part of or with the Licensed Software; and Original Contributor and/or other Contributors shall have the right to license or to otherwise transfer to third parties Your Modifications without notice, obligation or recourse to You. You grant to Original Contributor, Contributors and their respective licensees all rights and licenses (including patents) as are necessary to incorporate the Modifications created or contributed by You into the Licensed Software and to use, distribute or otherwise exploit such Licensed Software without payment or accounting to You.

BSD-style

BSD-style licensing allows free use and redistribution of both binaries and source code. source code can be used for creation of proprietary products. While users are allowed to modify the code, the development team does not typically take contribution of code and fixes from random contributors. You need to register yourself as a member of the development community to be granted such an opportunity.

Apache-style

Apache is a variant of BSD-style licensing with similar restrictions or more correctly the absence of thereof.

Public Domain software.

This type of comes into being when the original copyright holder explicitly relinquishes all rights to the software.

That means that:

• copyright rights have been relinquished,
• software copies can be made for both archival and distribution purposes with no restrictions as to distribution,
• modifications to the software are allowed,
• decompiling (i.e reverse engineering) of the program code is allowed,
• development of new works built upon the package (derivative works) is allowed without any limitations on the distribution or use of the derivative work.
   

Since under current copyright law, all intellectual works (including software) are protected as soon as they are committed to a medium for something to be public domain it must be clearly marked as such. Before March 1, 1989, it was assumed that intellectual works were not covered by copyright unless the copyright symbol and declaration appeared on the work. With the U.S. adherence to the Berne Convention, the presumption has been reversed. Now all works assume copyright protection unless the public domain notice is present. 

Some comparison of the existing licenses is provided in the table below:
 

Protection of  author and product  reputation

• Protection against the author name hijacking. For example "The name of the author may not be used to endorse or promote products derived from this software without specific prior written permission from the author. [BSD style]"
• Obligatory attribution requirements. For example "Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution."
• Product name hijacking. This is important for protection of the author as absence of such protection permits hijacking of the product in case development became slow of temporally stops. For example Products derived from this software may not be called "Sudo" nor may "Sudo" appear in their names without specific prior written permission from the author [Sudo license]
• Clear marking of derived works and modification  with a separate document documenting changes For example "3.3. Description of Modifications. You must cause all Covered Code to which you contribute to contain a file documenting the changes You made to create that Covered Code and the date of any change. You must include a prominent statement that the Modification is derived, directly or indirectly, from Original Code provided by the Initial Developer and including the name of the Initial Developer in (a) the Source Code, and (b) in any notice in an Executable version or related documentation in which You describe the origin or ownership of the Covered Code." [MPL]
• "Protection against the anonymous pollution of the original code" 3.2 You must cause all Licensed Software to which You contribute, i.e. Your Modifications, to contain a clear identification, e.g., a separate file, documenting the changes made by You and identifying You as the Contributor that reasonably allows subsequent Recipients to identify the originator of the Modification. To the extent You create at least one Modification, You may add Your name as a Contributor to the requisite notice described in Section 3.3."[Plan 9 license]

Protection of commercial interests of the original author

• The protection against liabilities suits.
• The ability to use open source code in own commercial products
• The ability to use contributors code in own commercial products
• The ability to combine products released on this license with your own commercial products
• The protection against hijacking of the development of the product

Provision of benefits from the derived works and modification

• Right to receive modifications used in a derived work (obligatory feedback to the central repository)
• Right to modify and reuse all submitted changes.
• Right to change the license for the submitted contributions, patches
• Protection against pollution of original API. 

The possibility of the formal software license specification

Such an approach lead to a natural conclusion that developers can benefit from coordination of the life stage of software with appropriate license. It might help to look at various software licenses as consisting of four major modules:

• The module that protects of the rights of the principal author (the copyright holder)

• The module that specify the extent of regular users right

• The module that specify the extent of contributors rights (for example see IBM Public License Version 1.0 )

• The module that specify the obligations of the developers of the derivatives works rights

For example at early stages of software the software author's) is the one to protect and the license should have a definite bios in this direction.  The second more valuate group are users. and the last group is developers of derivative products.

At the same time at slow growth and later stages the author probably got all the fame and already achieved most of his goals (and often is tied and disillusioned about the project) and the survival of the product is the top priority. that means that the license should favor parts of the user population that can help to prevent stagnation. At this stage co-developers should be the most important group and the license be adopted to reflect this situation.

Historically the first algorithmic license was first introduced by Perl with its dual GPL/Artistic license.  Although XML is a more appropriate language for such a formalism (see below) for simplicity we will use a regular algorithmic language notation. In this notation the idea of Perl license can be formulated as

if  (license1 is preferable to license 2) {
    use GPL_licence for derivative works /*  licensing fork of type I */
}
else if (licence2 is preferable to license1) {
    use Artistic_License for derivatives  /* licensing fork of type II */
}else {
    preserve existing double licensing /* no licensing fork */
}

As you can see, nothing prevents us extending it to more choices or changing the selection criteria and making it more complex case-like sequence of selections. For example here is a skeleton of hypothetical license that adds a couple of additional restrictions for the creator of derivates works and is structured along the user categories defines above (for categories other than the author the user can assign yourself as many categories as he/she wish):

if (classify(user) ==  "author") {
.....
}else if (classify(user)= "regular_user") {
... // sublicense that lists restriction for the user

}else if (classify(user) == "contributor") {
... // sublicense that lists conditions and restrictions for this category of users

}else if (classify(user="the_creator_of_derivatives_works") {
    if  (you plan to create derivatives that does not modify or enhance the existing API) {         
       ... //sublicense that lists conditions and restrictions for this category of users
    } else {
       ... //sublicense that lists conditions and restrictions for this category of users
    }
}

Such section-based licensing structure can help to address issues separately and thus might lead to more clear unambiguous and less complex licenses that eventually may be formally verified for compliance along the lines of P3P standard. Please note that in the the_creator_of_derivatives_works section we distinguish between the creator of compatible and incompatible extensions to the product. We will discuss this important problem in the next part of the paper. Now I will just note that this idea was mentioned in the rudimentary form in the Artistic license and was further developed in the Sun Community license. The approach that consider freely available version as a reference implementation of some explicit or implicit standard IMHO deserves further attention. And you can harmonize the level of protection more precisely by discriminating between derivatives that obey the standard and derivatives that broke the standard (or reference implementation) in the incompatible ways. This might help to address the problems similar to the problems of Microsoft extensions of  Kerberus without introducing the "viral" properties into the license.

I think that the most important us that sections of the license can be activated by both the user role and the stage of development or  version of the product. This lead us to an important idea that license should not be the same to the lifetime of the product and different periods might benefit from the different licensing. Such licenses that use different modules depending of the stage of development of the product (see below) can be called dynamic licensing and is one of the principal ideas that I would like to introduce in this paper. It will be discussed further in the section three of the paper. One of the main problem of software development is that software projects have different dangers on different stages of development. For example it makes sense to start development using more strict license like Sun Industry Standards Source License (SISSL) at the beginninge and change it to more simple BSD after the product reaches maturity switch to the BSD license:

if  (version of the product < 1) {
    use SISSL-like license  /*  the product is in infancy and needs additional protection */
}
else if (version of the product <= 3) {
    use Artistic_License   /* the world accepted the product; product is already established and some restrictions can be relaxed */
}else  if (version of the product > 3){
    use BSD license /* Product reputation is already well established; the author plans to pass development to other co-developers */
}

Another important idea that the license can specify "immutable sections" of the code, that might be useful for protecting API against forks. Actually this approach was used by Stallman in his GNU documentation license, which surprisingly is not interoperable with GPL. 

Above I used an algorithmic language notation for the licenses. But as I already mentioned XML can be used as well. And it can be a better formalism for the creation of a formal software licenses similar to P3P formalized privacy policies. P3P was designed to provide Internet users with a clear understanding of how personal information will be used by a particular Web site. Web site operators will be able to use the P3P language to explain their privacy practices to visitors. Users will be able to configure their browsers or other software tools to provide notifications about whether Web site privacy policies match their preferences. This potentially creates a possibility of automatic checking of compatibility of a particular component with the adopted license as well as other interesting applications. For example a user browsing some source code repository can view only those parts of the repository that corresponds to his licensing preferences. In this case his source browsers should contain a user agent part that reads formally encoded license and compare it to the requirements. The full investigation of this idea is belong the scope of the paper, but I would like to note that the following key words as defined in RFC2119 [KEY] and can be used in a formal license for interoperability with P3P in such an XML schema.  More detailed discussion of the possibilities of XML usage is beyond the scope of the paper. I just want to mention that there is a possibility of specified different levels of compliance, for example:

MUST or MUST NOT

This word or the adjective "required" means that the item is an absolute requirement of the specification.

SHOULD or SHOULD NOT

This word or the adjective "recommended" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course.

MAY

This word or the adjective "optional" means that this item is truly optional.

That means that the license can be structured as a table:

Table 2

Stage of development/user group	Developers	Users	Distributors	Codevelopers	Developers of derivative products
initial	Must Should May
Rapid development	Must Should May
Mature	Must Should May
Final	Must Should May

 

Conclusions

The main idea here is not just introduction of possible useful formal verification of licenses (and their compatibility)  in the form similar to P3P approach, but the idea of changes of the license modules as the software product progress thou its lifespan. It is generally safer to add licenses then remove of change them.

By modularization of the requirements into sets (licensing-modules) specified the rights of major subgroups of users one probably can better balance interests of each group and thus potentially attract more co-developers than in case of current licenses and thus increase chances for the survival of software beyond the support of the original author. I think it's worth looking at the whole spectrum of free/open software licenses and see how they have evolved, the way the community accepted them, and how they facilitate information transferee both with academic sector and business sector. Presented classification table of software licenses makes the first step in this direction and even in its present limited form raise suspicions that contradictions inherent in any radical license can lead to stagnation of software development, introduction incompatibilities due to ideological radicalization (license jihad) and other negative effects.

This analysis also suggests that licensing can benefit from incorporating of the notion of time (or version of the software) into the license.  It's natural to expect that the initial developers needs to be better protected against hijacking of the software during the first most crucial stages of the development of the product and on those stages a more pro-author license might make sense. After reaching, say, version 1.0 of the product that balance need to be shifted to satisfy rights of  users and co-developers in order to speed the adoption of the product and get a valuable feedback. this may be done by adding a second license, or replacing the initial. That suggest possibility of creation "time/version-sensitive" licensees. This approach corresponds to the historical path of development of PHP scripting language and if we look on the amazing success of PHP thus approach might have sense for other innovative products too.

This time/version-based "self-modification" approach might be helpful also in commercial  licensees: the extremes of commercial software license can be compensated by adopting a second license that will give users some additional rights when this will not undermine the competitive advantages of commercial product. Microsoft move toward providing 30-days evaluation version of Office XP and other products also represent step in the right direction. That means that it's possible to design some licenses that gives users additional rights after product was superseded by a certain number of newer versions (or discontinued). That can help to address the "abandonware" movement that is a natural reaction to the extremes of current commercial software licenses. For example I doubt that Microsoft commercial interests will be damages it releases DOS 6.12 and Basic as unsupported historical versions. after all they are really important historical landmarks and we need to put efforts into preservation of such landmarks and to providing some kind of access to visitors. For example Borland made certain version of its software  freely available as such historically important "monuments".  The same approach is applicable to some historically important games.

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Created May 1, 2000; Last modified: March 12, 2019