| Content of these pages are owned and copyrighted by the poster. | |
| Hosted by: |
|
One of the issues unresolved in the JOS project is what license to use for our source code. GilbertHerschberger has written WhyOneLicenseForAllIsBad. I disagree with this, although each subproject is free to choose its own license there comes a point where we'll be working on something together. In this case, we should be agreed on the license for that effort.
This table is here for developers to indicate what their preferred license is. The aim is just to see what various people's views are.
| Name | Preferred License | Short reason |
| JohnLeuner | GPL | Ensures that we can benefit from changes made by others |
| WarnerO | BSD | Ensures that if I want to resell this as a product I don't have to fork the code. |
| PhilipGonia | zlib/libpng (with MPL1.1, BSD, or M.I.T. being alternates) | I believe these come the closest to the meaning of Free Software. At least in my mind. |
| AveryRegier | GPL + ClassPathExceptionClause | Compatibility with other open source projects so that we can reuse as much as possible. Exception clause allows linking of Class files |
| GilbertHerschberger | Undecided, GPL | This project can help all its members choose an appropriate license, and should. It cannot make such an important decision for them. |
| IainS | BSD / APL | I'm interested in JOS from both an educational and commercial viewpoint. |
| JackUnrue | GPL + ClassPathExceptionClause | It seems like a good compromise. |
Short License Summary
BSD / APL http://www.freebsd.org http://www.apache.org
In general, BSD authors are pretty much putting source into the public domain, while trying to keep rights to credit for the work (you can't call something an Apache Web server unless its licensed under the APL (a BSD style license)), and protecting themselves from lawsuits if the software doesn't do what it "should". It is very short and is considered "commercial" friendly for creating proprietary products based on or including BSD code.
GPL authors are looking for BSD rights and additional rights. These include the right to get free access to software that uses GPL'd software (improvements always return to the community), etc. The license is long in order to enumerate and enforce these additional rights (even if you cut out all the non-legal language which I don't think most GPL advocates necessarily agree with). The GPL is generally considered "commercial" unfriendly for creating proprietary products based on or including GPL code (part of the GPL goal is to make sure GPL code stays non-proprietary).
IainS opinion,
I like the BSD code base primarily for its commercial/proprietary friendly nature. Many dislike it specifically because of the very same thing! However for many general use tools, I really don't have that strong an opinion of going GPL or BSD because I don't see the tool as being particularly strategic (so being forced to open source it under GPL is not a burden).
For a Java OS I am very strongly BSD oriented because of the nature of GPL code and its interaction with Java, the Java object model, and implications for its use in the OS. For example, the following from the Free Software Foundation (GNU) FAQ on licensing (see http://www.fsf.org ) seems incredibly ominous to a Java OS using the GPL:
<GPL FAQ>
In an object-oriented language such as Java, if I use a class that is GPL'ed without modifying, and subclass it, in what way does the GPL effect the larger program?
Subclassing is creating a derivative work. Therefore, the terms of the GPL effect the whole program where you create a subclass of a GPL'ed class.
</GPL FAQ>
Notice the GPL affects the "whole program" not just that class.
So, if our JOS driver base classes are GPL'd and require specific drivers to sub-class to implement for specific devices (our most likely architecture), all drivers will have to be GPL'd. Much of this danger has to do with the way the GPL is worded for linked works that poses a weird requirement on Java apps (it was written with C programs in mind so it often gets really weird for Java and its dynamic compilation).
There used to be a web page at the FSF website where Richard Stallman discussed how the GPL and Java interact but it seems to be missing/moved and I can't locate it. It discussed essentially these issues and how GPL in Java essentially makes everything Java, GPL once you use a GPL'd class. If anyone else knows what I'm talking about and knows where that web page is I'd appreciate the link.
There are probably ways of creating public domain "buffer" classes/interfaces to isolate GPL classes from the rest of the system to prevent this. However it seems wrong to have to jump through these hoops...
I think it is important that someone from the GPL camp post a similar discussion (perhaps a rebuttal to these statements and exposition) there too.
JohnLeuner opinion:
The application of the GPL to Java code seems unclear. Linking is always dynamic in Java, unless you use a native compiler like GCJ.
I believe that standard libraries should not place any restriction on applications that use them. In Java's case, this means all the java.* classes.
When it comes to other libraries things become unclear. If your program invokes another program to do some work, is it linking to that program?
For example, you could do it like this:
Runtime.exec("some program", someArgs);
But you could also do:
org.someprogram.Main.main( someArgs );
And you can also use reflection:
Class c = Class.forName("org.someprogram.Main"); //then do getMethod, and call invoke()
Another case is when the application doesn't even know what code it will be running at compile time. Let's say a web browser wants to run a Java applet. It downloads the code and runs it.
Which of these constitute linking?
In the above examples, it is clear that you haven't used the source from another library. For me using the source in your program is the point where a license should kick in. I want people who are working with my source (not my binary .class files) to contribute any changes they make.
This means that a program can use a "Licensed" XML parser, a "Licensed" regular expression library or a "Licensed" console routine library without any restrictions. It should also be able to subclass classes in those libraries and implement interfaces without any restrictions. The crux for me is when the developer starts changing and using your source code.
Whether the program should say that it uses your library or not is another issue for discussion.
AveryRegier opinion:
I generally support us using the GPL + ClasspathExceptionClause for two reasons:
1) Maximum compatibility with other open source software, so that there is far less code that we'd have to rewrite in order to use directly in JOS. Understanding what other code you can use is conceptually far easier because the relationships of the GPL to other OSS licences is well-documented. If someone has written a DNS lookup protocol with license X, and X is documented to be compatible with the GPL, we can use it.
2) Us using the same exception clause as Classpath removes many legal ambiguities I'd rather not deal with (considering how closely affiliated the ClassPath code will be with JOS), and ensures that JOS too can be extended into the embedded space without an undue burden.
PhilipGonia opinion:
I have read the GPL/LGPL. For many of the same reasons outlined above by IainS I to have to say (to the level of my understanding these licenses) I disagree with their use on JOS or JOS related projects. The use of anything (code or otherwise) that falls under the GPL should also be questioned when related to anything JOS.
The use of the "ClasspathExceptionClause" does not in my view help the cause of the GPL as related to Java code. Because of the nature of Java inheritance. It seems to me that there is no way around the GPL FAQ response. (see Iain's opinion above.
This statement in and of itself makes the GPL licenses (GPL/LGPL) hard for me to support.
I think it may be helpful if we are careful with our terminology. Not to be legal or "proper" but to ensure that people do not get confused or misled.
I would suggest the following definitions be used carefully and precisely during our license discussions to avoid confusion and misunderstanding (alphabetic listing):
BSD - The license of the Berkeley Software Distribution of Unix (www.freebsd.org). Also implies almost identical licenses like the MIT license (X Windows), and APL (Apache public license). Typically even though you say you're using a BSD license, you really mean you're using a BSD-style license. A license that uses the BSD boilerplate, and substitutes all references to the "University of California Regents" with your project name.
Free - Avoid term at all cost. See other definitions for higher accuracy of your intent! I know its in our byline but I think this licensing discussion is partly setting our project's definition of this "loaded" word. The FSF take on free refers to its common use when referring to living things, particular humans (as in freedom) and definitely does not mean the same thing as free in common use when referring to non-living things (as in no cost). Since free software refers to software, I suppose you're free to choose a definition, or using the common usage, decide whether you consider software living (and human) or non-living... :)
Freedom - Use this term when referring to a license providing rights and priviledges similar to those granted to human beings (e.g. freedom of speech). This is what the GPL means when it says its a free software license. In this set of terminology, it is a freedom software license or software freedom license.
GPL - The GNU Public License. The license of the free software foundation (GNU). www.fsf.org. This is primarily a Freedom license (as freedom is defined here). It's goal being to promote software that grants its user and developer community freedoms similar to the US Constitutional freedoms like freedom of speech. Unlike BSD licenses, when people say the use a GPL license, they do mean the exact GPL license, with copyrights assigned to the free software foundation and not their own project, organization, or self.
MPL - The Mozilla Public License. Basically GPL with a commercial "escape clause" that allows a particular entity (usually the major/original contributor) to use the code and contributions to create proprietary products that are not constrained under the normal GPL restrictions. The JJOSPL license is (as I read it) a variant of the MPL. Like the BSD license, when people say they use an MPL license, they mean they use the MPL boilerplate license, substituting the name of themselves, their project, etc in where ever "Netscape/AOL" appears.
No-cost - Use this term to mean "you don't pay money for it" rather than "free" which can be easily misinterpreted.
Open Source - Adheres to the terms of the open source definition provided at www.opensource.org. This is a very broad definition of open source. It was intentionally written so that most open source licenses including BSD and GPL qualify. Notice that Richard Stallman says GPL is not open source even though the open source definition says it is. For the latest, check out the letters to the editor in this month's Dr. Dobbs where Richard Stallman specifically says this (September 2001... yeah, subscribers may get it a bit early).
SCSL - The Sun Community Source License. Significant only because the majority of the Java reference implementations are licensed under this license. Allows open source like rights between SCSL licensees for "research purposes" but reverts to relatively standard commercial licensing when you try and use it for "internal deployments" or "commercial products". Unlike the BSD license, when someone says they use the SCSL license, they do mean the exact SCSL license (similar to the GPL case). Because of the terms of the SCSL, most code released this way is either Sun code, or code that is required to be released under the SCSL because of SCSL licensing terms (code patches).
Viral - A property/clause of a license that helps it to spread into other code. The GPL is a typically referred to as a viral license because it forces code that uses (links to (except for LGPL libraries) or extends) GPL'd code to become GPL code. I think that the term viral has negative connotations so is unfavorable to the GPL. I would like to find another term to replace it so that our terminology isn't biased. Suggestions?
***********
So for example, I'm a BSD advocate even though I may be referring in actuality to the Apache Public License (APL). Regardless I may say something like:
JOS should have a BSD license. I want a no-cost, open source java operating system.
Which using the above definitions we can decode this to mean:
JOS should have a license that uses the BSD boilerplate license but substitutes the "JOS project" in where the BSD license assigns the copyright to the "University of California Regents". I want a no-cost (I don't have to pay for it), open source (as defined at www.opensource.org) java operating system.
A GPL advocate could then reply:
JOS should have a GPL license. I want a open source JOS that protects my Freedom.
Which is decoded to mean:
JOS should use the exact GPL license provided by the FSF and our source copyrights should be assigend to the FSF. I want a open (as defined at www.opensource.org) java operating system that grants developers and users certain freedoms as outlined in the GPL similar to the US constitutions freedoms granted to all humans.
This is much better than the same above conversation using the more confusing terminology of:
JOS should have a BSD license. I want a free JOS.
JOS should have a GPL license. I want a free JOS.
Which is confusing because it looks like they're saying the same thing even though they are not.
- IainS
| Content of these pages are owned and copyrighted by the poster. | |
| Hosted by: |
|