Re: SDK header translations licensing?

And yet more vitriol :(
  ----- Original Message ----- 
  From: Peter Haas 
  To: [email protected] 
  Sent: Friday, March 05, 2004 11:56 PM
  Subject: Re: [Delphi-JEDI] 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



   


[Non-text portions of this message have been removed]



------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for your HP, Epson, Canon or Lexmark
Printer at MyInks.com. Free s/h on orders $50 or more to the US & Canada.
http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/i7folB/TM
---------------------------------------------------------------------~->

 
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/