BorlandTalk.com Borland discussion newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  DCU file ownership          BorlandTalk.com Forum Index -> comp.lang.pascal.delphi.misc View previous topic :: View next topic   Author Message Ryan Guest Posted: Fri Feb 03, 2006 9:31 am    Post subject: DCU file ownership I have a bit if a generic question as I want to gauge peoples opinions. We have an external supplier who previously wrote our applications and now supports them. I'm bringing the work in house gradually and taking the work off them which they are aware of. Our contract states that all of the work is owned by us and they have provided the vast majority of the files as agreed. However, there are a number of common functions etc... that they use and these have been provided as compiled units (.DCU). They won't release the .pas files unless we pay a licence and at which point, these will be split out (which is fine). The reason is that they consider these 'special materials' and part of their generic code for all clients. There is a clause in the contract, so I need to look closely at the implications. So, the question is do you consider DCU files to be sufficient for 'provided code'. We can re-build the vast majority, and probably re-use a lot of the source, but cannot check or change the code in these files. They cover things such as encryption functions that we use heavily. Having little experience of providing code in this way, I'd like to see what is generally thought of before forming my own opinions. Thanks Ryan Back to top Ryan Guest Posted: Fri Feb 03, 2006 9:33 am    Post subject: Re: DCU file ownership Just as a follow up, the files are listed in the project and not as installed components. Back to top J French Guest Posted: Fri Feb 03, 2006 10:56 am    Post subject: Re: DCU file ownership On 3 Feb 2006 01:31:53 -0800, "Ryan" <ryanofford (AT) hotmail (DOT) com> wrote: Quote: I have a bit if a generic question as I want to gauge peoples opinions. We have an external supplier who previously wrote our applications and now supports them. I'm bringing the work in house gradually and taking the work off them which they are aware of. Our contract states that all of the work is owned by us and they have provided the vast majority of the files as agreed. However, there are a number of common functions etc... that they use and these have been provided as compiled units (.DCU). They won't release the .pas files unless we pay a licence and at which point, these will be split out (which is fine). The reason is that they consider these 'special materials' and part of their generic code for all clients. This is not uncommon or unreasonable, if you hire a guy to build a house exttension it is unusual to expect him to give you his tool kit. Quote: There is a clause in the contract, so I need to look closely at the implications. Whoever wrote the contract on your side made a major mistake Quote: So, the question is do you consider DCU files to be sufficient for 'provided code'. Definitely not - DCUs are platform and language specific - with a different version of Delphi you are ... stuffed Quote: We can re-build the vast majority, and probably re-use a lot of the source, but cannot check or change the code in these files. They cover things such as encryption functions that we use heavily. Your suppliers should really have provided these functions in StdCall DLLs - actually probably just one DLL As a fallback I would be inclined to write StdCall drivers for the stuff in the DCUs and get the lot in a DLL Quote: Having little experience of providing code in this way, I'd like to see what is generally thought of before forming my own opinions. You can't really expect software suppliers to give away years of accumulated work as a freebie with some application code. Also, from their point of view someone in your place could pinch the source and start competing with them. On the other hand, unless you can continue to use the utilities on a later platform (version of Delphi), you are in a very precarious situation. As a matter of policy, you should not buy in anything unless you have the full source - or it is a tightly defined utility wrapped in a portable DLL (and even that can be risky). Back to top Nico de Jong Guest Posted: Fri Feb 03, 2006 11:29 am    Post subject: Re: DCU file ownership Quote: On 3 Feb 2006 01:31:53 -0800, "Ryan" <ryanofford (AT) hotmail (DOT) com> wrote: I have a bit if a generic question as I want to gauge peoples opinions. We have an external supplier who previously wrote our applications and now supports them. However, there are a number of common functions etc... that they use and these have been provided as compiled units (.DCU). They won't release the .pas files unless we pay a licence and at which point, these will be split out (which is fine). The reason is that they consider these 'special materials' and part of their generic code for all clients. The way I see it, it depends on how you define "common functions". Who paid for them originally ? If they were developped under the terms of your contract, the work is yours, and they must deliver the source. If they developped the functions for their own benefit, e.g. as a toolbox to distribute to various customers, a license fee is fair. Nico Back to top Bjorge Sæther Guest Posted: Fri Feb 03, 2006 1:37 pm    Post subject: Re: DCU file ownership J French wrote: Quote: On 3 Feb 2006 01:31:53 -0800, "Ryan" <ryanofford (AT) hotmail (DOT) com> wrote: So, the question is do you consider DCU files to be sufficient for 'provided code'. Definitely not - DCUs are platform and language specific - with a different version of Delphi you are ... stuffed I'd call .dcu files "worthless". Unless you get a contract with DoDi, of course... ;-) Quote: Having little experience of providing code in this way, I'd like to see what is generally thought of before forming my own opinions. You can't really expect software suppliers to give away years of accumulated work as a freebie with some application code. But, OTOH, this means you don't *get* the source code... Quote: Also, from their point of view someone in your place could pinch the source and start competing with them. It's not that simple. It just isn't so that a programmer's library is worth a lot to someone else. Unless thoroughly documented, another programmer wouldn't choose to use them. I can't think of any code being so, uness it was actually *built* to be universally useful. No, us programmers tend to overestimate our superiority ;-| Bjorge Back to top Bjorge Sæther Guest Posted: Fri Feb 03, 2006 1:39 pm    Post subject: Re: DCU file ownership Nico de Jong wrote: Quote: On 3 Feb 2006 01:31:53 -0800, "Ryan" <ryanofford (AT) hotmail (DOT) com> wrote: I have a bit if a generic question as I want to gauge peoples opinions. We have an external supplier who previously wrote our applications and now supports them. However, there are a number of common functions etc... that they use and these have been provided as compiled units (.DCU). They won't release the .pas files unless we pay a licence and at which point, these will be split out (which is fine). The reason is that they consider these 'special materials' and part of their generic code for all clients. The way I see it, it depends on how you define "common functions". Who paid for them originally ? If they were developped under the terms of your contract, the work is yours, and they must deliver the source. If they developped the functions for their own benefit, e.g. as a toolbox to distribute to various customers, a license fee is fair. Writing functionality to be generally useful is more tedious, and I doubt whether it's that much saving involved. By no means this means that it justifies an extra fee. Who cares whether the code was written for you or for another customer ? Bjorge Back to top J French Guest Posted: Fri Feb 03, 2006 3:59 pm    Post subject: Re: DCU file ownership On Fri, 03 Feb 2006 14:37:29 +0100, =?ISO-8859-1?Q?Bjorge_S=E6ther?= <bjorge (AT) xitte (DOT) no> wrote: <snip> Quote: It's not that simple. It just isn't so that a programmer's library is worth a lot to someone else. Unless thoroughly documented, another programmer wouldn't choose to use them. I can't think of any code being so, uness it was actually *built* to be universally useful. No, us programmers tend to overestimate our superiority ;-| So nobody uses the Win API ? <g> Back to top Tom de Neef Guest Posted: Fri Feb 03, 2006 4:08 pm    Post subject: Re: DCU file ownership "Ryan" <ryanofford (AT) hotmail (DOT) com> schreef in bericht news:1138959113.569744.174300 (AT) g14g2000cwa (DOT) googlegroups.com... Quote: I have a bit if a generic question as I want to gauge peoples opinions. We have an external supplier who previously wrote our applications and now supports them. I'm bringing the work in house gradually and taking the work off them which they are aware of. Our contract states that all of the work is owned by us and they have provided the vast majority of the files as agreed. However, there are a number of common functions etc... that they use and these have been provided as compiled units (.DCU). They won't release the .pas files unless we pay a licence and at which point, these will be split out (which is fine). The reason is that they consider these 'special materials' and part of their generic code for all clients. There is a clause in the contract, so I need to look closely at the implications. So, the question is do you consider DCU files to be sufficient for 'provided code'. We can re-build the vast majority, and probably re-use a lot of the source, but cannot check or change the code in these files. They cover things such as encryption functions that we use heavily. Having little experience of providing code in this way, I'd like to see what is generally thought of before forming my own opinions. In the end it is all a matter of contractual obligations. In that respect I would consider two points: 1) the supplier may well have been chosen because he could benefit from these 'common functions', e.g. because it allowed him to deliver faster or offer a better price. In which case he's already been paid for the functions by the award of the contract. 2) whatever the contract specifies in terms of deliverables, it is most unlikely that the contractual obligations are fulfilled if the delivered system can not be maintained. And other posters have pointed out that a DCU alone is not sufficient for that purpose. So you should get a DLL or a commitment to upgrade the DCU's when needed. Tom Back to top Bruce Roberts Guest Posted: Fri Feb 03, 2006 5:17 pm    Post subject: Re: DCU file ownership "Tom de Neef" <tdeneef (AT) qolor (DOT) nl> wrote Quote: 1) the supplier may well have been chosen because he could benefit from these 'common functions', e.g. because it allowed him to deliver faster or offer a better price. In which case he's already been paid for the functions by the award of the contract. Are you a lawyer? This is some of the most twisted logic I've ever seen. A supplier has not "already been paid" because they won a contract. They are paid for delivering what was contracted. The reasons behind the sucess of their bid are immaterial at that point and should not factor into an after the fact, after contract signing, determination of payment. In the situation you cite one could as easily suppose that the purchaser has already benefited from the common code because a) the project price was lower, and /or b) the vendor was the only one who could deliver the desired functionality in the required time-frame. Quote: 2) whatever the contract specifies in terms of deliverables, it is most unlikely that the contractual obligations are fulfilled if the delivered system can not be maintained. And other posters have pointed out that a DCU alone is not sufficient for that purpose. So you should get a DLL or a commitment to upgrade the DCU's when needed. Based on this argument one could go on to say that the vendor should supply all compilers, 3rd party tool sets, libraries, and o/s. After all every one of those is required to "maintain" the system. As I suspect most software vendors do, I generally stipulate that the only source to be delivered is that written specifically by the vendor to meet the needs of the client's project. Any code written for more general application or previously written is specifically excluded, as is anything written by 3rd parties. Unless the contract states otherwise, a software vendor never sells a continually working system, nor does he give or imply any warranty of continued execution. To expect such is ridiculous in the extreme. Speaking for myself, I only ever sell a license to use the written software, ownership is never transfered. If the vendor has delivered a working system and met the terms of the contract, she has no obligation to assist the customer in removing their business. Its not logical to expect that a vendor should have to work against her own best interest, unless specifically contracted to do so. Back to top Maarten Wiltink Guest Posted: Fri Feb 03, 2006 7:23 pm    Post subject: Re: DCU file ownership "Ryan" <ryanofford (AT) hotmail (DOT) com> wrote [...] Quote: Having little experience of providing code in this way, I'd like to see what is generally thought of before forming my own opinions. It's a pain and a timebomb, but it's not illegal or immoral by itself. Read the contract carefully but also try to see things from their point of view. The DLL proposal sounded very smart. Perhaps pay a little extra for it, or for good specs that allow in-house reimplementation. Groetjes, Maarten Wiltink Back to top Tom de Neef Guest Posted: Fri Feb 03, 2006 7:26 pm    Post subject: Re: DCU file ownership "Bruce Roberts" <dontsendtober (AT) pleaseatbancoems (DOT) com> schreef in bericht news:veMEf.14969$Sk1.322732 (AT) news20 (DOT) bellglobal.com... Quote: 1) the supplier may well have been chosen because he could benefit from these 'common functions', e.g. because it allowed him to deliver faster or offer a better price. In which case he's already been paid for the functions by the award of the contract. Are you a lawyer? I am a physicist. I am a user and I am a supplier. For many years I have been in charge of a large software company and I have assisted customers to manage system supplies. I have won 13 out of 16 legal cases, but none had to do with contracts and none in the US ;-) Quote: This is some of the most twisted logic I've ever seen. A supplier has not "already been paid" because they won a contract. They are paid for delivering what was contracted. The reasons behind the sucess of their bid are immaterial at that point and should not factor into an after the fact, after contract signing, determination of payment. In the situation you cite one could as easily suppose that the purchaser has already benefited from the common code because a) the project price was lower, and /or b) the vendor was the only one who could deliver the desired functionality in the required time-frame. If you need a laywer for a certain case, you select one who's specialized in that area. That offers a better price/performance ratio than when you select one who's new to that field. Thus the price agreed includes all previous knowledge, instruments and tools that the supplier uses. He can't charge extra for it. This led me to the argument that the common functions are part of the supply. It doesn't mean transfer of ownership. Neither is the laywer in the example required to pass on all his knowledge. Quote: 2) whatever the contract specifies in terms of deliverables, it is most unlikely that the contractual obligations are fulfilled if the delivered system can not be maintained. And other posters have pointed out that a DCU alone is not sufficient for that purpose. So you should get a DLL or a commitment to upgrade the DCU's when needed. Based on this argument one could go on to say that the vendor should supply all compilers, 3rd party tool sets, libraries, and o/s. After all every one of those is required to "maintain" the system. As I suspect most software vendors do, I generally stipulate that the only source to be delivered is that written specifically by the vendor to meet the needs of the client's project. Any code written for more general application or previously written is specifically excluded, as is anything written by 3rd parties. Unless the contract states otherwise, a software vendor never sells a continually working system, nor does he give or imply any warranty of continued execution. To expect such is ridiculous in the extreme. Speaking for myself, I only ever sell a license to use the written software, ownership is never transfered. If the vendor has delivered a working system and met the terms of the contract, she has no obligation to assist the customer in removing their business. Its not logical to expect that a vendor should have to work against her own best interest, unless specifically contracted to do so. You can look at it from different points of view. If you buy a car and find that you need the dealer to change tires because he's the only one who has the tools to unfasten the bolts, you will be very unhappy. Even though the car runs fine and does what a car should do, it can not be considered fair to the customer if he hadn't been informed about this. OTOH the dealer could say that he's delivered what's in the contract and that the customer should have read the manual before deciding. My point of view is not that the common functions should be supplied in source code without further charge. Neither do I argue that maintenance should be offered free of charge. But I do feel that a supply should be 'complete' and allow the buyer to be independent of the supplier if he so wishes. Remaining dependencies should been spelled out in the original offer. With all source code delivered, this DCU business seems such a dependency and the easiest way out is to supply a DLL. Tom Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         BorlandTalk.com Forum Index -> comp.lang.pascal.delphi.misc All times are GMT Page 1 of 1   Jump to: Select a forum C++ Builder Newsgroups----------------C++ BuilderC++ Builder (ActiveX)C++ Builder (Announcements)C++ Builder (Command Line Tools)C++ Builder DatabasesC++ Builder Databases (ADO)C++ Builder Databases (Desktop)C++ Builder Databases (InterBase Express)C++ Builder Databases (Multi-Tier)C++ Builder Databases (SQL Servers)C++ Builder (Graphics)C++ Builder (IDE)C++ Builder (Internet)C++ Builder (Internet Socket)C++ Builder (Internet Web)C++ Builder (Jobs)C++ Builder (Language)C++ Builder (Language C++)C++ Builder (Compatibility with MFC)C++ Builder (Native API)C++ Builder (Non-Technical)C++ Builder (Students)C++ Builder (Third Party Tools)C++ Builder (Upgrade)C++ Builder (VCL)C++ Builder (VCL Components Usage)C++ Builder (VCL Components Development)C++ Builder (VCL Usage)C++ Builder (WinAPI)C++ Builder Installation Delphi Newsgroups----------------Delphi (General)Delphi ActiveX Controls UsageDelphi ActiveX Controls DevelopmentDelphi As400Delphi DatabasesDelphi Databases (ADO)Delphi Databases (dbExpress)Delphi Databases (Desktop)Delphi Databases (InterBase Express)Delphi Databases (Multi-Tier)Delphi Databases (SQL Servers)Delphi DeploymentDelphi GraphicsDelphi IDEDelphi InternationalizationDelphi InternetDelphi Internet Isapi-WebBrokerDelphi Internet WebSnapDelphi Internet WinsockDelphi JobsDelphi Language BASMDelphi Language ObjectPascalDelphi Model Driven Architecture (General)Delphi Model Driven Architecture (Third Party)Delphi MultimediaDelphi Native APIDelphi Non-TechnicalDelphi ObjectPascalDelphi OLE AutomationDelphi OO designDelphi OpenToolsAPIDelphi Reporting-ChartingDelphi RTLDelphi StudentsDelphi TeamSourceDelphi Thirdparty ToolsDelphi Thirdparty Tools (General)Delphi Thirdparty Tools (IntraWeb)Delphi Thirdparty Tools (RaveReports)Delphi UpgradeDelphi VCLDelphi VCL ComponentsDelphi VCL Components UsingDelphi VCL Components WritingDelphi WebServices SOAPDelphi WinAPIDelphi XMLDelphi Installationcomp.lang.pascal.delphi.components.misccomp.lang.pascal.delphi.components.usagecomp.lang.pascal.delphi.components.writingcomp.lang.pascal.delphi.databasescomp.lang.pascal.delphi.misccomp.sources.delphi JBuilder Newsgroups----------------JBuilderJBuilder AnnouncementsJBuilder Applet IssuesJBuilder As400JBuilder CompilerJBuilder CORBA/RMIJBuilder DatabasesJBuilder DB SwingJBuilder DebuggerJBuilder DeploymentJBuilder DocumentationJBuilder EnterpriseJBuilder HandheldJBuilder IDEJBuilder JavaJBuilder JavaAPIJBuilder Java LanguageJBuilder Java SwingJBuilder Java BeansJBuilder Java Beans UsageJBuilder Java Beans DevelopmentJBuilder JBCLJBuilder JDataStoreJBuilder JobsJBuilder LinuxJBuilder MacintoshJBuilder & MobileSetJBuilder MultiLingual AppsJBuilder Non-TechnicalJBuilder OpenToolsJBuilder Servlets (JSP)JBuilder StudentsJBuilder Team DevelopmentJBuilder Thirdparty ToolsJBuilder UpgradeJBuilder Installation InterBase Newsgroups----------------InterBaseInterBase Bug DiscussionInterBase GeneralInterBase IBConsoleInterBase OpenSourceInterBase ReplicationInterBase SQLInterBase ThirdpartyInterBase Installation Miscellaneous Borland Newsgroups----------------AppCenterAppServerEnteraVisiBroker  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.