Subject: Re: [IBIS] EIA IBIS Open Forum Minutes (05/31/02)
From: Al Davis (aldavis@ieee.org)
Date: Wed Jun 05 2002 - 13:01:50 PDT
I feel compelled to respond to the comments about making the parser
open source.
The existing closed source licensing effectively prohibits its use
with other open source tools. The committee's opposition to open
source was a major factor in my decision to withdraw from the IBIS
futures committee last September.
I will now comment on some issues that were brought up...
> .... A drawback to using an open source model is
> the risk of someone creating a rival parser, but this risk is
> minimized by having the IBIS committee in control of the official
> IBIS spec.
If the parser is not open source, anyone making an open source tool
must make a "rival parser". The existing parser licensing
effectively prohibits any academic research projects from using it.
The restriction imposed by the existing license is very far reaching.
First, it means that no open source simulator can use it, at all.
Second, there is a potential for many small IBIS related projects
that could be done by individuals or small teams, perhaps as academic
senior projects. Some examples might be viewers, validation tools,
extraction tools, and others. All of these are prevented by the
existing closed source license.
Actually, I have a "rival parser". It parses IBIS 3.2 completely,
and most of the 4.0 extensions. I am planning to release it GPL when
I am ready. I developed it when I was working on the macro language
(which actually works), but stopped when I left the committee. What
is missing is the simulator specific code to actually simulate using
it. Since I distribute an free/open-source simulator
(http://www.gnu.org/software/gnucap) releasing the parser is of
benefit to me only if my simulator can use it, or if it generates
revenue, so I am withholding its release until that time. I offered
it to the committee but the committee rejected it.
I guess that brings up another risk of keeping the official parser
closed-source. There is a risk that an unofficial open-source parser
may become more accepted than the official closed-source one.
> ... On the GNU Public License
> (GPL) issue, Kim noted that the IBIS committee can still sell
> unrestricted licenses that will allow EDA companies to incorporate
> the parser source code into their commercial products.
Yes. This is true.
This is a way it could be financed. A company selling closed-source
software would need to buy such a license, as they do now. This
could fund development.
It also controls the "rival parser" issue, because even if such a
thing exists, the committee still can control what it endorses as the
official one. This endorsement is independent of ownership. If
someone else makes a parser, and releases it under GPL, and it is
incorrect, the committee can fork it, to a "corrected" version that
it declares to be official.
> In a response to a question from Bob Ross, Barry Katz indicated
> that the latest proposal document will be uploaded to IBIS quality
> committee web site:
>
> http://www.sisoft.com/ibis-quality/docs/
>
>
> Bob Ross again mentioned his concern that by making the IBIS parser
> source code open interested companies may not be willing to
> directly fund parser development, thus undercutting the current
> funding mechanism.
That is why the model of "GPL with exceptions for sale" makes sense,
as opposed to a BSD type license. The companies making closed source
software products could buy a license similar to the one used now.
Actually, the current funding model doesn't work. There is more to
it than making a parser to a spec. The current model provides no
incentive for anyone but a proprietary EDA vendor to take any
interest in development. It is particularly offensive to the
academic and open source communities.
> ... Stephen Peters concurred, and he also reiterated his belief
> that the gatekeeper(s) must be committed to a stable and long
> term relationship with the IBIS Open Forum.
Perhaps, but you need to consider why some people might have dropped
out, or have been dormant. I believe that the gatekeeper(s) must be
as impartial as possible, certainly not part of a vendor of
proprietary software. How about ... "the gatekeeper(s) must be
committed to a stable and long term relationship with open source
software and open standards." Even so, this role can be transferred
fairly easily.
> .... Finally, Bob noted that the IBIS committee does not have the
> resources to verify that all companies are in compliance with a Gnu
> Public License (GPL).
Does this really matter? Tradition has shown that public
embarrasment is usually sufficient to enforce compliance. It seems
to me that any license for sale scheme is no better in this respect.
Maybe the best way is to use a BSD type or LGPL type license. That
way it isn't necessary to enforce anything.
> Lynne Green asked if adopting an open source model means that we
> would move from bug fixes only updates (dot releases) to releasing
> new versions of the parser every time a bird was passed.
Here is another benefit of the open source model. Many projects have
both "stable" and "unstable" development tracks. The "stable" track
would be the official one, which would implement the official
standard. The "unstable" one would track the changes as they are
being discussed. It could even track unapproved birds, so they can
be tested before being formally approved. The best way is to follow
the Debian model, and have 3 ... "stable", "testing" and "unstable".
In this case, "stable" is the approved standard, with the parser and
standard approved simultaneously. "Testing" is made to the draft
standard, in hopes of it being approved. "Unstable" is where the
unapproved birds are presented. There could be more than one
"unstable" branch, trying out several paths of development. Of
course, they would need to be labeled clearly.
-----------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with the appropriate command message(s) in the body:
|
| help
| subscribe ibis <optional e-mail address, if different>
| subscribe ibis-users <optional e-mail address, if different>
| unsubscribe ibis <optional e-mail address, if different>
| unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a request to ibis-request@eda.org.
|
|IBIS reflector archives exist under:
|
| http://www.eda.org/pub/ibis/email_archive/ Recent
| http://www.eda.org/pub/ibis/users_archive/ Recent
| http://www.eda.org/pub/ibis/email/ E-mail since 1993
This archive was generated by hypermail 2b28 : Wed Jun 05 2002 - 13:16:20 PDT