(1) So is it the case that research & techniques published in journals are in public domain? I’m not sure about things like player written scripts, unless our EULA specifies that and the player has agreed to the EULA.
While posting on the internet is a form of publishing, determining who is the owner is key. And it sounds like from Scassa’s work that may be defaulted in some cases to the end user and not to Stanford, so it would have to be codified & released with informed consent through some kind of EULA.
As mentioned elsewhere, and by LFP6, CC is not appropriate for protecting software.
(2) It looks like my next step is to look at the Rosetta & Foldit licenses. In the meantime, yes repository separation with clear licensing terms per ownership of the repository is advisable.
If the code is to be noncommercial, then open source options may not be usable as is [see exploration below], but perhaps usable aspects of them could be adopted and modified.
Charging for-profit entities for use via licensing is better than outright sale of xyz research, because licensing offers finer control over terms, and opportunity for updating those licensing terms as the landscape evolves.
For example, it is better for Stanford / Eterna / Players to remain the sole owner[s] of our IP, such that production partners are only licensing access according to the terms of our agreements, and explicitly do NOT receive transferred “ownership” of our IP.
In other words, there is a distinct difference between what it means to license out access vs. what it means to sell ownership over a piece of data, and we can retain more control by creating explicitly defined license agreements, per client if need be. Legal can comment more specifically than I can on the subtleties here.
(3) I’m very appreciative that we have community and dev support for open access of the research. I would love to keep our research owned by the global community in the pursuit of the highest good.
There are some [I’m sure non-exhaustive] complexities with regard to a few considerations about licensing, which I’ll outline below:
A. Commercial Use
Open source and what it means in the context of commercial ventures.
It’s not all good or all bad. In some ways open source inherently defends and promotes commercialization diversity; in other ways market share can be limited, but is that even a concern for us?
It appears you can use AGPL and other flavors of GPL for commercial purposes, with the specific restrictions as defined in the particular license:
“Both the AGPL and the MIT license only address redistribution and have no restrictions at all regarding how you use the software. Neither forbids any form of commercial activity.
The only restriction is that the AGPL forces you to publish any code changes you make. So when you change the software to add support for displaying advertisement, you will have to publish these changes.”
One of those restrictions in GPL is for example that you cannot require all end users to pay you a fee in the case that you sell your product to a person who then chooses to distribute your product for free to other users:
"If I distribute GPL’d software for a fee, am I required to also make it available to the public without a charge?
No. However, if someone pays your fee and gets a copy, the GPL gives them the freedom to release it to the public, with or without a fee. For example, someone could pay your fee, and then put her copy on a web site for the general public."
http://www.gnu.org/licenses/gpl-faq.en.html#WhyDoesTheGPLPermitUsersToPublishTheirModifiedVersions
This means that it would be difficult to control the market for the product, since anyone with ability to go into production could potentially distribute it for free, or for sale:
"If I use a piece of software that has been obtained under the GNU GPL, am I allowed to modify the original code into a new program, then distribute and sell that new program commercially?
You are allowed to sell copies of the modified program commercially, but only under the terms of the GNU GPL. Thus, for instance, you must make the source code available to the users of the program as described in the GPL, and they must be allowed to redistribute and modify it as described in the GPL.
These requirements are the condition for including the GPL-covered code you received in a program of your own."
http://www.gnu.org/licenses/gpl-faq.en.html#GPLCommercially
B. Definition of "User"
A key difference between AGPL and GPL appears to be how “users” are defined, which changes who the license applies to:
“For the GPL you only need to provide the source code to people to whom you distributed the object code, not to the general public (the GPL does allow them to give away the source to anyone). For the AGPL you must also provide the source to “all users interacting with it remotely through a computer network”. i.e. users of your web site.”
C. Derivative Works & Sharing Source Code
Open source literally means our source code is required to be released, particularly when derivative works are created. This inherently means that any code licensed under a GPL flavor or otherwise open source license, will require even commercial ventures and licensees to release modifications they make at minimum to other “users”, depending on how the license is written. ( If I understand? )
I assume this is in alignment with our stated mission to go open access with as much as possible, but for clarity it should be understood that if there are any circumstances under which xyz research or source code needs protection, then that would have to be stipulated, since the licenses discussed thus far involve specifically making the source code available, even in commercial applications.
And as mentioned, who is a “user” also depends on how the license is written.
If “user” is defined as the general public, or if the whole license is granted by default as open source software, then any clause stipulating that source code must be shared with licensees means that even if a commercial venture is permitted, any new source code produced in the process of that venture must be released to other “users” , depending on how that is defined.
This may or may not be desirable [please feel free to chime in here], depending on exactly what we are doing with any commercial venture.
For example, if we invest time & resources into refining and developing xyz piece of IP into a product, and we use a GPL license, does that mean that any changes we make to the IP in the process will require us to release the new source code to pre-existing licensees / users [per however that is defined in our license]? Since derivative works will inherit the rules of this license?
I’m not sure I have a decisive opinion on whether or not it is desirable to protect our source code or open source it. I like the idea of open access as we’ve been doing with paper publications, and lean towards that as my preference. And I also see complexities that we should at least be aware of in moving forward either way.
So let’s examine some pros & cons…
Pros of using a GPL flavor license requiring open sourcing of [derivative] works [in commercial applications]:
- Even if we partner with xyz company to assist in production, they will be bound by the license to release to us and anyone defined as a “user” any modifications that they make.
- Also, [x]GPLs tend to have wording that protects against some or all patenting of source or derivative works, preventing our original IP from being materially used in an attempt to circumvent the original license.
- By keeping the research open source, we maintain the respect and participation of the global research, scientific, and technology communities which value and are in mutual pursuit of cures to countless diseases, certainly more than we can do just on our own anyway.
Cons of open sourcing derivative works are similar to going the explicative patent route vs. more opaque publication / prior art defense of IP:
- In releasing our source code publicly, even with rules protecting the IP codified in the license, we will still have essentially released our schematics and trade secrets publicly, and controlling that in practice will require legal enforcement.
- In other words, it’s easier to protect IP with walled gardens and black boxes than to release it and chase down people who violate the license.
- Some corporate / production interests find open source intimidating due to a perception that it may impede their ability to monetize and lock down the market for xyz product, and it appears that stipulating restrictions on ability to sell derivative works is not in the spirit of open source:
“Question:
I want to release the framework under a license that specifies that the framework is open-source, free, and cannot be sold. However, the framework can be used in commercial products, … [further conditions]
Answer:
You can get such a license written, if you really like, but I’d rather you didn’t call it open source. The Open Source Initiative definition of Open Source requires that other parties be able to sell the software. Therefore, you’ll be confusing people.
If you want a specific sort of license that fills particular requirements, I’d suggest getting a lawyer. There won’t be a Free Software/Open Source license ready for you to use. If you’re willing to allow your stuff to be sold as long as it stays Free/Open Source, look into copyleft licenses like the GPL family. LGPL is probably what you want for the framework, since an LGPLed DLL can easily fit into any sort of license scheme. You probably want a GPL version for the app, and I’d suggest the Version 2 or any later version for maximum compatibility.
The GPL requires that all derivative works be licensed under the GPL. It is possible to sell GPLed software, but it’s impractical to sell GPLed shrinkwrap software since anybody buying it can legally share with the rest of the world. If that’s what you really want, or are willing to settle for, the GPL will work for you. The LGPL works much the same, but allows linking to other software regardless of license.”
D. Gated Licensing
With or without [x]GPL open source code license terms, an alternative approach to carte blanche public license access is the traditional licensing path for protecting IP, where you gate access to a license by specifying exactly which groups of users have which levels of access.
For example:
- user group A: specifically defined free access to the general public
- user group B: specifically defined free & / or discounted access to academic institutions
- user group C: specifically defined fee based access to production / corporate / for profit interests ( which itself may be tiered depending on the size of the organization & their intentions / industry / etc. )
By combining clearly defined user groups or classes in the license, and gating access, we can clarify which license terms apply to which people & applications of which IP. It’s tedious to be specific, but will enable greater flexibility.
This means that much like each type of IP has a specific kind of license, each type of user group has specific levels of access / permission, or even a specific kind of license per user type / IP combination. It sounds complex but it’s not too hard to wrap your head around if you just pick one place to start and branch out the options. Think of it as a logic table for licensing. :)
So we would:
- Define the licenses that apply to each type of IP
- For each type of IP, define the terms that apply to each user group. This may take the form of different licenses per user group, or simply involve modifications within the license of each group’s definition & permissions.
E. Human Rights
Some of my colleagues developed CGPL, which includes the Declaration of Human Rights in the license, and protections against patenting. I like the idea of contractually binding users of our research to some basic standards of decency, since one of my primary concerns with both CC and open source is the end use of the research, depending on who gets their hand on it.
While of course we can’t enforce these rules for those who would not listen anyway, any deterrent and legal standing is always a step in the right direction, and taking a stand for human rights is something we are well positioned to set a good example for. As with the other licenses we could use all, or modify as needed.
F. Custom License
I don’t know any of these licenses word for word, and even if I did it is unlikely that any of them are 100% suitable for all of the scenarios on our plate.
So whatever licenses we decide are most appropriate for each IP & user group, need to go through a couple stages of review:
- Review of the licenses ourselves, keeping what is appropriate and removing what is not, per IP category / user group
- Review of our modifications by a legal team
Okay this is probably enough to process for now. And please anyone do correct me if I have any misunderstandings.
And my next task [hahaha since I said that several posts ago I think] is to review Foldit & Rosetta licenses in the context of this conversation. But I think it is helpful that we rounded out the idea first of what we want, before being influenced by it, so I think the conversation has been very helpful, thanks to all!