News | Mail Archive | OS Software Downloads | Patents Ad Info ::
Subject: Databases | Java | Linux | Open Source | XML | Data | Tech


Contribute:
· News/Reviews/Release
· Submit a New App!

Misc:
· My Account
· Editorial Feedback
· Logout

Login
 Username
 Password
 Remember me


 Become a Member!
 Login Problems?

News via email
Enter your Email



Recently Updated Mail Archives
debian-mips-debian
chromium-reviews
Google-Web-Toolkit
ftp-release-list
debian-russian-debian
general
coreaudio-api
Android-Developers
rhelv5-list
javacareers
android-ndk
kde-commits
plasma-bugs
java-net
kdelibs-bugs
web2py
Android-Beginners
kde-freebsd
svn-commits-list
minix3
dev.openjpa.apache.org
users
digikam-devel
surroundsound
fedora-package-review
sapjobshungary
fop-dev-xmlgraphics.apache.org
python_linux
CakePHP
mainframe_vsam
mongodb-user
debian-user-german-debian
debian-wnpp-debian
coworking
jbase
dev-servicemix.apache.org
derby-dev-db-apache
mahout-dev.lucene.apache.org
Popular Mail Lists: windows linux solaris osx ubuntu fedora enterprise crm ruby python java xml perl php cvs subversion version contol db
database mysql postgresql mobile telephony voip apple apache
all
sitemap (mail)




Posted Mar 02, 2005

New OSI President Seeking Proactive License Simplicity

      

Russell Nelson, newly appointed President of OSI (Open Source Initiative), is proposing the addition of three new terms to the Definition of Open Source. The move comes after drawing fire over the growing number of licenses the OSI approves as meeting the definition and a long acknowledged problem of the proliferation of vanity licenses & incomprehensible legal jibberish.

In an email to the OSI license-discuss mailing list Nelson wrote, "We have always pushed people in this direction, but by adding these terms to the OSD, we will be proactively refusing licenses which don't meet these requirements.

11. *The license must not be duplicative.* That is, it is up to the
submitter to demonstrate that the license solves a problem not
sufficiently addressed by an existing certified license. Certification
may be denied to any submitted license, even a technically OSD-
conformant license, if OSI deems it duplicative.

12. *The license must be clearly written, simple, and understandable.*
Open-source licenses are written to serve people who are not
attorneys, and they need to be comprehensible by people who are
not attorneys. OSI may deny certification to licenses which,
though technically correct and OSD-compliant, are so obscure
and complicated that an intelligent layperson cannot be assured
of knowing his or her rights and liabilities after reading it.
The burden of engineering this clarity falls on the submitter.

13. *The license must be reusable*. If the license contains proper
names of individuals, associations, or projects, these must be
incorporated by reference from an attachment that declares the
names of the issuer and any other cited parties, and which can be
modified without changing the terms of the license. As the sole
exception, the license may name its owner and steward."

The current version of the Open Source Definition does not include any such terms, while the license approval process only encourages the use of current licenses by insisting on an explanation of why the new license doesn't meet someone's legal need.

These new terms are still up for discussion.

Maybe Good, But Foremost You Need To... (Score: 1, Insightful)
by Anonymous on Mar 02, 2005 - 09:41 AM

This might be a good thing, so long as it doesn't scare licensors away from the OSI.

First, however, I would endeavor on a campaign to try and

(1) ascertain what licenses currently are duplicative and select the most common from each
(2) negotiate with all relevent licensors as to why they do not want to except the selected license
from each category, modifying the license where possible to bring them on-board

Then the OSI can say here are x number of licenses and here are the comparative characteristics of each. By selecting one of these, you can reduce the anxiety of customers and ensure that they are more likely to understand the terms and conditions.

Only once a thorough process such as this is conducted should you consider a forcible "use one of these licenses or else" approach. It's well understood that the OSI ensures the safety of using software in certain ways under approved licenses. As such, I believe the additional proposed requirements are in-line with that, but let's take a little time to better formulate the reduced set of licenses--I am sure a lot of the problem lies in minor details. Once those issues are resolved and the reduced set is more broadly acceptible, then add the requirements.


Re: New OSI President Seeking Proactive License Simplicity (Score: 0)
by Anonymous on Mar 02, 2005 - 10:34 AM
Sounds like an essential plan.

There's already too many duplicative licenses. Compare, the MIT and X11 licenses:
http://opensource.org/licenses/mit-license.php
http://opensource.org/licenses/xnet.php

They're word for word the same except for the line:
"This agreement shall be governed in all respects by the laws of the State of California and by the laws of the United States of America."


IMO, this choice of law option is a pointless incompatibility that should not be allowed in an OSI definition. Suppose you wish to combine QPLed source code with X11 source code. Both licenses are sufficiently liberal, so it should be possible. However, the QPL contains the line:
"This license is governed by the Laws of Norway. Disputes shall be settled by Oslo City Court.".

The last time I checked, Norway was not in the stage of California, so combining QPLed source code and X11 source code is impossible.


Just imagine if every open license had a variation for each state, province, region, and country. You'd never be able to reuse code.





Advertise With Us! | Comments are property of their posters.
Copyrighted (c) 2010, but we're happy to let you use what you wish with attribution. OSDir.com
All logos and trademarks are the property of their respective owners.
OSDir is an inevitable website. super tiny logo | Contact | Privacy Policy

Advertising by

Page created in 0.103591 seconds.