Official License Anti-Proliferation policy?

[Chuck Swiger]

Howdy--

Smith, McCoy wrote:
> As I indicated in my email of a couple of weeks ago, Intel would be OK
> if the Intel Open Source License is deprecated (or whatever term is
> found to be acceptable by OSI for the concept of discouraging future use
> of the license), despite the fact that the new tiering policy is not at
> this time retroactive.  

Like Ernie, the impression I have gotten is that the tiering policy is, or 
will be, retroactive.

However, because Intel is volunteering to depreciate your license, you make an 
excellent test case for figuring out what to do.  For example, I think that 
when a license is depreciated, there ought to be a statement made by the 
original author (and/or the OSI board if the decision is not agreed-upon by 
all concerned) notifying people of this, containing a recommendation what 
projects using that license ought to use.

Obviously, it's up to the individual project authors and IP owners to decide 
whether to follow that advice, but if the OSI board wants to facilitate 
license anti-proliferation, somebody's got to try to shepherd these projects 
towards using something from the recommended tier.  In the case of the Intel 
license, it seems easy enough to recommend that people relicense their code 
under the BSD license.

Should someone contact all of the ~200 project administrators at SourceForge?
Probably.  If so, who?

Or perhaps we just need to contact the admins at SF, or collab.net, or any 
other community which seems affected, and let them deal with passing the word 
on themselves...?

-- 
-Chuck

PS: Please don't construe anything I've said as a criticism of Intel's 
position.  Intel has made significant efforts to make tools like icc available 
to open source projects-- having alternative compilers available is a win for 
all of us, including the gcc project itself, because software authors and 
maintainers can actually test whether code is portable or whether it contains 
non-portable GCC'isms.

Intel has also created and shared a huge variety of specifications and 
guidelines and such about voltage specs, RAM memory timing docs, interface 
standards, and such in your online technical documentation, under fair and 
open terms.  It's a valuable resource, and appreciated.