Designing Open Source Licenses

    Project: Research project

    Project Details


    After a software developer develops a software, there are at least two ways to distribute it. The first way is to go proprietary, meaning that she sells copies of the binary code for profit. Since binary code is difficult to interpret, it deters the others from disabling its security device and making illegal copies. But it also makes it difficult for future developers to learn from her source code. In other words, while going proprietary allows the developer to profit from her earlier e↵ort, it also stifles further development of her original idea.

    Another way the developer can distribute her software is to go open source, meaning that she makes her source code open for everyone to see and copy. By going open source, she forgoes the profit she could have made from selling copies of the binary code, but she can gain utilities when future developers, inspired by her source code, develop more advanced versions by adding extra functionalities to her original software. Such utilities may come from pride, prestige, sheer joy of seeing her idea further developed, or the satisfaction of using a more advanced version of her original software.

    There are two major kinds licenses a developer may use when she decides to go open source. The first is the restrictive kind, as exemplified by the GPL license. By sharing her source code using a GPL license, the developer is telling future developers, “You can use my source code to develop a more advanced version. But if you ever want to distribute your advanced version, you have to go open source instead of going propriety, and you have to go open source by using the same license I am using, namely the GPL license.” This kind of open-source licenses are restrictive because they restrict how future developers can distribute their software. In particular, the restriction is a “share-alike” requirement, requiring that future developers share in a manner like how the original developer shares her source code. In a sense, the GPL license is defined in a self-referential way because of this “share-alike” requirement.

    The second kind of licenses a developer can use when she goes open source is the permissive kind, as exemplified by the BSD license. By sharing her source code using a BSD license, the developer is telling future developers, “You can use my source code to develop a more advanced version, and you can distribute your advanced version in whichever way you like. You can go propriety, you can also go open source. If you choose to go open source, you can use any open-source license you like.”

    This project will provide an analytical framework to systematically identify new, never- heard-of open source licenses, and examine the circumstances under which they may serve purposes that existing ones such as GPL and BSD cannot serve. Our findings will provide practical advices for developers on whether they should choose the GPL or the BSD or other open source licenses, as well as on how more sophisticated open source licenses may be constructed out of existing ones. The findings of this project will be disseminated in seminars, conferences, and scholarly journals.
    Effective start/end date1/01/2231/12/23


    Explore the research topics touched on by this project. These labels are generated based on the underlying awards/grants. Together they form a unique fingerprint.