Re: SDK header translations licensing?

Hi Martin,

on 2004-03-05T00:50:22+01:00 you wrote:
> The problematic header is not actually JEDI submitted as far as I am
> aware. If I am to use it this will need to be corrected (and I must
> mail the translator about it.

Maybe I don't understand this correctly, then forget the following.

Why do you mean, that a header conversion need to be submit to JEDI
API Library?

Everybody can create a header conversion and publish it on his
homepage or any other web page without necessity to submit it to JEDI.
Rather currently all header conversions will developed outside from
JEDI API Library.

The reason is simple, the JEDI API Library page is unmaintained, the
project is practically dead. If you search a header conversion take a
look to the project JEDI+ API, which have links to the old JEDI
conversions and conversions from other authors and which active
maintain existing and create new conversions.


on 2004-03-04T12:41:05+01:00 you wrote:
> I develop audio software and use translations of DirectX and
> DirectShow headers and classes. I was discussing getting a full
> translation of the Cakewalk DXi 2 SDK together, which sits on top of
> DirectShow baseclasses so a translation of that needs to be available.

I know the DirectShow base classes and I don't think, that a 1:1
conversion is a good idea. I would prefer Delphi-like solutions for
the tasks, solved by the DirectShow base classes.

> At the moment I have my own translation made many years ago, but it
> would seem sensible to move to an already publically available
> translation. I was pointed towards DSPack which includes this. The
> home site of this claims "JEDI affiliation" but I think now the code
> isn't actually JEDI submitted. The relevant files have no Microsoft
> copyright notice remaining (dodgy) and a (partial, I think) MPL
> notice.

This is not related to the header conversions, this files don't have
removed the Microsoft Copyright. Maybe we should modify the the
WMF9.pas file, because there is not the usually hint in the header (it
is below). I will make this change in the next days.

A real problem are Baseclass.pas and DSUtils.pas, which contain code
from the DirectShow base classes without any copyright hint.

From the Microsoft License:

: 2.1 Source Code. “Source Code” means source code that is located in any
: directory or sub-directory named “samples” in the Software or that is
: otherwise identified as sample code in the Software, other than source
: code included in the SPSSDK, or is identified as Microsoft Foundation
: Class Libraries (“MFC”), Template Libraries (“ATL”), and C runtimes
: (CRTs). Microsoft grants you a limited, nonexclusive license (a) to
: use and modify any Source Code to design, develop, and test your
: software applications; and (b) to make and distribute copies of the
: Source Code and your modifications, subject to your compliance with
: Section 3.

...

: 3.1 ... (f) you will include a valid copyright notice on your
: Application sufficient to protect Microsoft’s copyright in the
: Software; (g) you will not remove or obscure any copyright, trademark
: or patent notices that appear on or in the Software as delivered to
: you;

I will try to add all needed copyrights to the DSPack source code in
the next days.


BTW: This is the wrong forum to discuss this problems. DSPack is a
JEDI Alliance project, practically this mean, that DSPack can add the
Allicance Logo to his homepage and maybe in many month or years JEDI
Steering set a link to DSPack on his homepage. But there is not
anymore, the other statements are pure theory. JEDI Steering have
accent expressly and repeatly, that DSPack is not a JEDI project (I
have a other sight regarding this).

You should discuss the problems, mentioned in this forum in the DSPack
forum, because the problems are DSPack related, not JEDI related.

To participate active on the DSPack development, please create a
account on SourceForge and write a mail to Henry Gourvest, he can
add you to the developer list. If you have any urgent modifications,
you can write me a mail as well and I will modify the sources on
SourceForge.


To give you any explanation about the JEDI API Library problems, I
have mentioned above, below a copy of a posting, that I have wrote in a
other thread. Maybe you can see, why DSPack is the better place for
your development.

Bye Peter.
-- 
JEDI+ API, the active JEDI Header Conversions Project:
http://jediplus.pjh2.de/api


x----

The official JEDI homepage is unmaintained since a long time (letters
of appreciation to Helen Borrie). One year ago I has addressed this
and other problems to JEDI steering, but JEDI Steering state that
there is not any problem. Because JEDI Steering hinder with this
behavior the publication of any new stuff, I have found JEDI+ API to
continue the tradition of the early JEDI, which JEDI Steering have
betray.

A half year ago, JEDI Steering confirm this statement from Robert
Marquardt: "It is not our job to work on new conversions or update
older ones." This was the official end of the original JEDI API
Library.

Meantime JEDI Steering have create a new strategy, it reduce the JEDI
API Library project to a link list and hope, that anybody from outside
modify the entries. With other words, other people do the work, JEDI
Steering get the fame, without doing anything. To create the
impression of a active project, Matthias Thoma copy some entries from
the JEDI+ API homepage. Actually not problematic, but the
circumstances create serious problems. The new project page create the
impression, that the stuff is submit to the project, intensified by
the link to JEDI's bug tracking system. But the authors of the new
stuff was neither inform about the links nor he has given her
permission. If a user write a bug report, the author don't have a
chance to get the information and therefore to improve his work.
Because JEDI API Library don't can maintain any stuff, the user is
angry, maybe about the author, the author get a bad reputation. This
is not acceptable.

Maybe the author create a new version of his conversion. Because there
is not anybody, which maintain the JEDI API Library list, any visitor
don't have a chance to get the new conversion. This is not any vision,
unfortunately this is reality. Already now JEDI API Library don't
reflect the currently state of the available conversions. Beside the
problem, that the new homepage is furthest unknown and with the
usually tempo of JEDI Steering this stay valid for many month or even
years.

Maybe a author submit a conversion to JEDI API Library. He guess, that
the project maintain the conversion, but nothing regarding this will
happens, how everybody can see on the old JEDI conversions. How wrote
Robert Marquardt one year ago: "Why should we be interested is someone
who considers us a waste basket?". Mister Marquardt have scared more
than one potential JEDI developers with his bad behavior. In
consequence JEDI Steering reduce JEDI API Library to a waste basket.


How JEDI can solve this problems? Regarding JEDI API Library there
would be a simple solution. JEDI+ API is a JEDI project, JEDI Steering
could create a link on the official homepage and therewith get a
really active API project without the problem, I have mentioned above.
But far from it, JEDI Steering don't acknowledge JEDI+ API as a JEDI
project ("You are not part of Project Jedi and you will never become a
part of it."), moreover it fight against JEDI+ API. I have try to give
JEDI Steering a new chance again and again, JEDI Steering disclaim.
Meantime a prominent ex-member of JEDI have try to start a new
conversation, but Steering stay to be a kindergarten, don't be able to
give anybody a rational reason for her senseless behavior.

How I wrote in the past, meantime there is not any necessity to have
JEDI Steering, because 12 active developer don't need 15 people which
steer they without knowledge about the currently development. It's
time for JEDI to deprive the power from JEDI Steering and give JEDI a
new chance to become able to solve the currently tasks. In a open
source project the active developer need to have the control, not any
inactive veterans.

x----



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
     http://groups.yahoo.com/group/Delphi-JEDI/

<*> To unsubscribe from this group, send an email to:
     [email protected]

<*> Your use of Yahoo! Groups is subject to:
     http://docs.yahoo.com/info/terms/