Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
Answered:
They don't allow any kind of redistribution with 2.6, supposedly, unless you have licenses for it. But they don't sell licenses for it. But they give it away free. But, who knows, i think they just want us to buy an overpriced thing we don't need to write a free utility. I guess I'll look at NVelocity or TaHoGen...
I am concerned about placing some DLLs that go with a project, which is also free (on SF.net), but hasn't had a particular license associated with it yet. This is a bit lawerly, but hopefully not so much so that it can't be answered through experience. And there is a lot of that here :)
I think the issues is really with CodeSmith 2.6, since they have their own "custom" eula. To view the "sourcelicense.txt" you need to download the zip and open it, but i've copied the relevant parts into the post (sorry they are so long!)
Edit:
What the app does it use CodeSmith 2.6
dlls, along with a collection of
custom templates, to generate class
files/etc. We don't need the
codesmith source, only the compiled
result. Of course, those dll's will
be distributed with the application in
the .exe. The question is whether or
not stuffing them in to the repo is
somehow different (or legally more
questionable) than putting them into a
.msi/.exe installer.
I'll approach codesmith about this,
but I would like a better
understanding than I have now, is all.
They are currently not in the repo,
but it would ease things for the dev
processess if they were.
End Edit
1 MIT Licensed component (doesn't seem like an issue)
Mysql.Data.dll (not sure of the license)
CodeSmith 2.6 Freeware DLLS
Compiled to DLL form
SchemaExplorer.dll / etc
CodeSmith.Engine.dll
I'd like to be able to make the project self hosting, and not have the user go traipsing around, downloading and/or compiling copies of the source (especially if they find a newer version or older verision, which could easily happen with the MIT/msql components.)
There will be nice instructions if the DLLs can't be included, but life is infinitely simpler if they can, and there are no chances of the project going "dead" if one of them is suddenly yanked.
SOURCE CODE LICENSE (from CodeSmith 2.6 eula/sourcelicense.txt)
The SOURCE CODE is protected by United States copyright laws and international copyright treaties, as well as other intellectual property laws and treaties. The SOURCE CODE is licensed, not sold.
GRANT OF LICENSE. This EULA grants you the following rights:
Source Code. You may install and compile one copy of the SOURCE CODE on a single computer. The primary user of the computer on which the SOURCE CODE is installed may make a second copy for his or her exclusive use on a portable computer.
Storage/Network Use. You may also store or install a copy of the SOURCE CODE on a storage device, such as a network server, used only to install or compile the SOURCE CODE on your other computers over an internal network; however, you must acquire and dedicate a license for each separate computer on which the SOURCE CODE is installed or compiled from the storage device. A license for the SOURCE CODE may not be shared or used concurrently on different computers.
Use and Modification. SMITH grants you the right to use and modify the SOURCE CODE to better fit your needs. You may not distribute the SOURCE CODE, or any modified version of the SOURCE CODE, in any form. Any modifications made to the SOURCE CODE will continue to be subject to the terms and conditions of this EULA. Any modified versions of the SOURCE CODE may only be executed in object form by users also owning a SOURCE CODE LICENSE or by users owning a CodeSmith Professional license.
Use of Generated Output. You may distribute the output of your custom templates or the included templates in any way.
DESCRIPTION OF OTHER RIGHTS AND LIMITATIONS.
Separation of Components. The SOURCE CODE is licensed as a single product.
Redistribution. The SOURCE CODE may not be redistributed in any way.
Custom Template Distribution. You may distribute your custom templates for the SOURCE CODE only if they are offered free of charge.
No Rental. You may not rent, lease, lend or provide commercial hosting services to third parties with the SOURCE CODE.
Non-Transferable. This license may not be transfered or sold in any way.
Termination. Without prejudice to any other rights, SMITH may terminate this EULA if you fail to comply with the terms and conditions of this EULA. In such event, you must destroy all copies of the SOURCE CODE and all of its component parts.
ADDITIONAL SOFTWARE/SERVICES.
Support Services. SMITH may, but is not obligated to, provide you with support services related to the SOURCE CODE.
Supplements. This EULA applies to additional software and updates of the SOURCE CODE, including without limitation supplements, service packages, hot fixes, or add-on components (collectively "Supplements") that SMITH may provide to you or make available to you after the date you obtain your initial copy of the SOURCE CODE, unless other terms are provided along with such Supplements.
COPYRIGHT. All title and copyrights in and to the SOURCE CODE (including but not limited to any images, photographs, animations, video, audio, music, text, SAMPLE CODE, and "applets" incorporated into the SOURCE CODE) and any copies of the SOURCE CODE are owned by SMITH. The SOURCE CODE is protected by copyright laws and international treaty provisions. Therefore, you must treat the SOURCE CODE like any other copyrighted material except that you may install the SOURCE CODE.
First: Stackoverflow is not a lawyer and can not provide legal advice. Take any legal information here with a grain of salt, and ask a lawyer if it matters.
Umm, that isn't anything close to a free software license, so I don't think it follows sf.net rules.
It doesn't grant you any permission to redistribute, either. In fact, it bars it:
2.2 Redistribution. The SOURCE CODE may not be redistributed in any way.
Possibly, your DLL is a "custom template", in which case it must be distributed free of charge, which violates clause 1 of the Open Source Definition
Custom Template Distribution. You may distribute your custom templates for the SOURCE CODE only if they are offered free of charge.
Other than that, you definitely need to clarify what you're doing.
I'm not familiar with what CodeSmith does, and I don't know exactly what you're doing with it. Obviously, you aren't going to redistribute source code, but they don't seem all that concerned with what you might redistribute.
There's that "Use of Generated Output" clause; are you going to be distributing template output only? Were you going to change their source code for this project? Without knowing the answers to questions like these, I can't advise you.
You could clarify what you're doing, or ask CodeSmith. I'm not sure that finding a lawyer who can answer your specific questions is going to be easy, as there's a lot of technical stuff going on in that license.
Related
I know that this is going to be kind of a silly question (I'm sorry; I tried googling, but I'm still a little confused). Here's what I want to know.
Suppose that I create an asset/game with InkScape/Unity3D (or any other freeware/open source tool). Do I need permission from the organization who made the freeware/open source tool to use the created asset for commercial purposes?
Thanks.
What cjmarsh says is definitely true about software licensing in general. Although, I would not be that insistent on talking to a lawyer (unless the project generates large amounts of money, that is).
Yet, I'd like to add a brief point about the difference in the tools OP is asking about (inkscape and unity):
inkscape
You are not bound by inkscape's license in distributing drawings produced by it. The license is about code distribution, which means the code of inkscape itself. The resulting drawing of an inkscape project is in SVG (or some other format depending on preference).
SVG is a standard on its own, published by the W3C, and does not contain any piece of code from inkscape.
unity
On the other hand, when developing with unity you are using API calls that originate from the unity libraries themselves (possibly wrapped by extra functions for whichever language you're using). Moreover, you project needs to link against the unity libraries in order to work.
Since your project will use pieces of unity code, you're bound by the license obligations from unity.
Software licensing is a complicated topic and to get a definitive answer to your question you'll have to speak to a lawyer. In layman's terms: you can use open source software for commercial purposes but there are often caveats depending on the specific license used. I should also note that Unity3D is not open source, however you can use the personal edition if you gross less than $100k annually. For more details check out their licensing page.
Inkscape on the other hand is free and open source with a good license for content creators: the GNU General Public License so "In short, this means you are free to use and distribute Inkscape for any purpose, commercial or non-commercial, without any restrictions. You are also free to modify the program as you wish, but with the only restriction that if you distribute the modified version, you must provide access to the source code of the distributed version."
There are quite a few different licenses like the most liberal of all CC0 Public Domain, a license that essentially puts your stuff in the public domain, making it completely free for any purpose to everyone, without you needing to be dead for 60 years. Then there are licenses like the LGPL which still lets you use it for commerical purposes but requires you to publicly disclose any changes made to the code that was under the license and if you embed it in your application (statically link it) then you have to release your product under the same license. There's also the kind of license like CC BY 3.0, a Creative Commons license that lets you do whatever you want so long as you give an attribution, include the license, and mention if it was modified. Here's a list of more open source licenses to give you an idea of how many there are.
Without paying the fees to consult a lawyer like everyone will tell you to do and nobody actually does you can check out summaries of the different licenses at sites like tldrlegal.com as well as read through them yourself and check out the licensing page on the individual sites of the software you use. In my opinion the software author's intention for distributing the software is more important to recognize than the legalese. Although you should also recognize the legalese.
Bottom line is you don't need explicit permission from the author because they already give it in the form of an open source license, so long as you satisfy the conditions of the license.
What are iTextSharp copyrights?
can I use it (without modifying it) in my project? I need to use it a PDF generation tool,
Any advise is appreciated.
thanks a lot,
This question is more or less a duplicate of several questions that were already answered on StackOverflow, but it isn't an exact duplicate of a single question. I have bundled several of these question in the free ebook The Best iText Questions on StackOverflow. If you want the full answer, I advise you to read the legal section of this book. I'll do an attempt to give a short answer here.
I am a Mentor at the Founder Institute and I use these slides to explain copyright and copyleft. You can find the text that explains slide 3 in my answer to the question Is iText Java library free of charge or have any fees to be paid?
You explicitly say that you do not modify the iTextSharp source code, which means you have probably read the copyleft license. However, you have doubts about the interpretation of the word "modifying". Allow me to copy/past from my book:
Start quote:
Free software is licensed software. iText is free software. That doesn’t mean that iText is for free: iText has always been distributed with a copyleft license.
Some people only read the first part in the definition of "copyleft". They read about receiving "permission to reproduce, adapt or distribute" iText, but they forget about the second part: "as long as any resulting copies or adaptations are also bound by the same copyleft licensing scheme."
iText versions pre-dating iText 5 were licenses using a weak copyleft license (more specifically the MPL/LGPL). This means that you can use such a version in an application that isn’t bound by the copyleft license. Your only obligation is to distribute the changes you make to iText under the MPL, the LGPL, or the MPL/LGPL. In theory, those versions can still be used inside applications that are not free. In practice, you should no longer use those old versions for both technical as well as legal reasons (as explained in one of the previous questions).
Starting with iText 5, iText has increased software freedom, in the sense that the license was changed to a very strong (some use the word "viral") copyleft license, more specifically the AGPL. When you use iText in an application that you distribute or when you use iText in a web application that allows
people to directly use iText (through a SaaS application, on a web site,...), you have to distribute all the source code that touches iText under the same license and under the same license only.
Some people argue: "We do not modify iText, hence we are not bound by the AGPL."
That assumption is incorrect. Writing a web application that uses iText is considered being a modification in the context of the AGPL and putting this application on a web server for people to access is considered being distribution.
End quote
In short: in a court room, linking your application to the iTextSharp DLL is considered being a modification, even if you do not change anything to the DLL. All modifications have to be distributed under the AGPL, hence your application has to be distributed under the AGPL. This way you contribute to the community.
If you do not want to share your source code under the AGPL, or if you want to distribute your code under a dual license to make money, you can escape from the obligations of the AGPL by purchasing a commercial license.
This way you also contribute to the open source project, as the money you pay is used to pay the salaries of about 20 people who work full-time for the iText group (and indirectly you pay for many more people such as accountants, freelancers, attorneys, etc. working for iText).
If you think this is unfair, think about how you would feel if you were not rewarded for the work you are doing. You don't want situations like what happened to the guy who wrote PGP who depends on charity, do you?
I need to come up with a CM process for PLC code.
Currently, the system is developed using RSLogix 5000. The build product is a monolithic file that can be loaded onto a PLC for execution and edited directly in the development environment. With multiple developers, this has become a problem. They're stepping on each others changes.
As an analogy, it's as if, when doing Java development, the only wway to edit and save the source would be to load up a *.jar file into your IDE, make the change, and then save it back to the jar file. This is less than ideal.
How can I coordinate changes between multiple developers working with PLC's?
If we are talking about one big binary files, then a VCS (centralized or decentralized) is not the best tool for the job.
An external referencial (a shared disk for instance) where a batch will copy and label the current PCL state is better.
See "Tracking Software History"
To avert discontinuities in the historical record of revisions, old versions of programs must be stored.
“We take it a step further, though. Using our MDT AutoSave, we actually go out and interrogate the equipment. Overnight or at whatever frequency is specified, the software reads the programs in the PLCs and then compares that information to the last known program. The version-control software will copy the new program and store it and [then] compare it to the last one.
Launching version control is fairly simple. Required is software installation and then hardware configuration. “You would need a server and a couple of weeks of engineering and you’re good to go,” Perysyn says. However, his company uses a “shrink-wrap approach” that involves installing the software and then customization by users filling in the blanks.
That being said, when you have multiple changes from multiple developers, you need an integration environment where a first delivery can be done and validated, before pushing it to the actual server.
See also this post.
I use Unity Pro, so this may not apply for other brands.
Unity can export an "archive" file which is XML which describes the PLC program and IO setup in its entirety. After commissioning changes, I create an export and check it in to my local Git repo. This gets me an annotated history of changes, but no visual comparison. I can always use UnityDiff for comparison.
Check out http://www.mdtsoft.com/ also
You need specialized versioning system for PLCs like VersionDog.
From the manufacturer:
"Special support with Smart Compares for SIMATIC S5, SIMATIC S7,
SIMATIC PCS 7, WinCC, WinCC flexible, InTouch, CoDeSys, TwinCAT,
Phoenix PC WORX, RSLogix, Schneider Modsoft, Schneider Concept,
Schneider Unity, SINUMERIK 840D, Bosch IndraWorks and more. Also robot
programs from ABB and Kuka and office related data formats like
Microsoft Word, Microsoft Excel and Adobe PDF are perfectly supported
by versiondog.
Update: Here is a screenshot showing ladder version compare. I guess that's what most PLC folks are interested in. We also use it to schedule e-mail report if PLC offline and online application versions are a match, as an alarm that something has been changed in PLC but not put into version control server.
About RSLogix5000 specifically, I have seen developers use an emulated PLC and make their changes online. The final product once developed is then put together with all the comments (as they are not contained in the PLC) and then commissioned. There are issues with changes that cannot be done online, such as AOIs. There are tools in place to stop two people editing the same logic online at once and to take ownership of sections. Backups can be done in the form of uploads, but there isn't any way to track changes.
It is a messy problem, messier still for when you are maintaining a system as you want an .ACD that you can go online with, as unless you are somehow doing a diff with the RSLogix compare tool you just see unreadable machine code like "+|Éû³´¬ÙÆW×晵‚>Ù,"
The most common revision control I have seen (sadly) is just saving the the latest file, then taking a copy and adding the current date to the file name, like the recommended control.com post described.
RSLogix5000 has always prohibited multiple users from opening and editing on the same .ACD simultaneously. However, if multiple users have identical .ACD files, open them, and all make connections to the same target controller, they each can edit on the controller simultaneously, but only if they are working on different routines. Other's edits appear automatically, if they were to look at another programmers routine.
Note that working online like this is usually done with the PLC running, even sometimes with the target system (some kind of machine) operating. This kind of arrangement for the purpose of completing work faster, or in some cases because the system is huge. No one develops like this, as it is really a debug tool and impractical for significant changes.
If one programmer finishes, and another is not done, the unfinished work of the other will be saved to the first programmer's .ACD when they save. Whoever saves last will have everyone's work.
Like others have mentioned in this thread, using file date is fairly reasonable. Some companies use a version control variable that is usually displayed on a connected HMI. Other companies use a separate document that documents who and what changes. Sometimes version notes are placed in a lengthy rung comment in the main routine.
My company uses a separate change log, and dated archive copies are maintained. Multiple programmers are only used in the most extreme cases. Someone is always designated to maintain the offline file integrity, usually the person who will be working the longest, or the project manager.
It is important to note that rung comments are not carried from one user to another before RSLogix5000 v21 because previous versions didn't store comments on the controller.
All this said, you might be trying to manage offline development. I haven't seen any sophisticated methods for this. Usually programmers write the needed routines separately, and a project manager will assemble them into a single project. The cleanest approach I've seen is where a project manager will create an architecture with global functionality, and assign routine work to others, giving them a copy of the .ACD to work with. They return the .ACD with changes, and the project manager copies and pastes their routines into the "master" project.
This is a very good question and it really depends on what you want it to do.
If you are only using Rockwell equipment it might be helpfull to look at their solution, I think it's called FactoryTalk AssetCentre.
Currently I am looking into using Bazaar from Canonical.
One thing that VonC pointed out is that a piece of software that can interogate the PLC is a deffinate plus, not a must in my oppinion but it sure as hell helps.
Am I reading your question properly and you have multiple developers working on the same PLC code at the same time? It's a scary thought but I know it sometimes needs to happen, Siemens PLC's are a bit easier to program with multiple developers but I would assign one person to consolidate and test all the changes before committing to the PLC. Any CVS system will let you create branches for every developer but how you would get them to consolidate their changes is the million dolar question.
Bart.
A simple thing to do would be to do a text diff on the .l5k files so you can easily see whether a developer has been messing with part of the file that is outside of their scope.
I saw this question just now from a link at stack exchange: Are There Realistic/Useful Solutions for Source Control for Ladder Logic Programs. Rather than have a link only answer, I'll dupe my answer here:
There is actually a canned solution - from GE-IP of all places. Check out Proficy Change Management. This product does version control from a PLC control systems point of view, rather than a pure version control of files point of view - it works as a layer sitting on top of a VCS (the scary part is that originally this VCS was Visual SourceSafe) and handles rights management, reporting and checkout/checkin.
While the product is from GE-IP, it is designed to support a variety of PLC and HMI systems out of the box.
Full disclosure, I used for work for a company selling and installing PCM (but that was 7 years ago). So if you ask me what it was like back then I'm likely to tell you where it all went wrong!
In my company we just started a trial with Copia.io
Check it out. Our first tests look very promising!
It brings, branching, merging, ladder diff etc... for multiple PLC platforms (Rockwell, Siemens, Codesys)..
PS. I work for a company that builds machines, we were looking for version-dog alike solutions with a bit more power in collaboration and diffing capabilities. I used tools like Mercurial, Git, Tortoise in past companies (not for PLC though).
Taken aback to day when I was confronted about the use of validation code used from the Csla framework. It felt like I was reprimanded for not disclosing the use of the framework to the client.
Is this not the same as using libraries such as jQuery etc?
You absolutely should acknowledge what you're using, IMO.
Some clients may have particularly strict legal requirements (whether for legitimate reasons or not - they're the client, it's not up to you to judge their laywers) and detailing any third party software you're using to create a product for them seems only reasonable.
What reason could you have for not wanting to be open with your client?
This depends on the license of the open source code you are using. Many of them require to acknowledge the use in some credits section, others require you to redistribute the source code, etc. You should read the license and act accordingly.
It depends on the project and the kind of client and whatever contracts you had. However, for a typical consultant delivering code to a customer, I would say no it is very strange that you would be reprimanded for not bothering them with details such as the use of CSLA. That's pretty odd.
It is the same, I have a feeling that you would have been reprimanded for using jQuery as well. There are enterprises that frown upon the use of open source for various reasons.
They boil down to
The type of license and what does it force the user to do
The availability of support in some commercial form
The need to 'share-alike' the results
You should know what's your customer/employer's stance on this. If they don't have a stance, then you have to discuss on a case-by-case basis.
I usually tell people I use a lot of open source and, by seeing the response I get I know the path to follow. If they jump and scream at the mention of open source and the lack of support and whatnot, I just tend to ask for budget to buy commercial components or present good cases as to why the open source version of X is better than the commercial alternatives.
It very much depends on the type of project and the type of client. The real problem here is that you were surprised, which indicates non-alignment of expectations. How did the client motivate its interest in Csla specifically?
If your client needs to know or cares about which technology you use, then you should specify everything as part of the project documentation. If the choices are clearly described, then it is easier to have a discussion about them, if required. Documentation also gives you a way to ask (literally) for 'sign-off', if that is the way you work.
From your question it is not clear whether the problem was the choice of framework, or not having informed the customer.
Even on projects with minimal documentation, if the customer owns the code then I always deliver at least a High-level architecture document that includes the names and exact versions of every software component used, along with a brief description of what it is for and why it was selected. This is also the correct place to address any license issues.
My organization has begun slowly repurposing itself to a less product-oriented business model and more contract-oriented business model over the last year or two. During the past year, I was shifted into the new contracting business to help put out fires and fill orders. While the year as a whole was profitable (and therefore, by at least one measure, successful, we had a couple projects that really dinged our numbers for the year back around June.
I was talking with my manager before the Christmas holiday, and he mentioned that, while he doesn't like the term "post-mortem" (I have no idea what's wrong with the term, any business folks or managers out there know?), he did want to hold a meeting sometime mid-January where the entire contract group would review the year and try to figure out what went right, what went wrong, and what initiatives we can perform to try to improve profitability.
For various reasons (I'll go into more detail if it's requested), I believe that one thing our team, and indeed the organization as a whole, would benefit from is some form of organized code-sharing. The same things get done again and again by different people and they end up getting done (and broken) in different ways. I'd like to at least establish a repository where people can grab code that performs a certain task and include (or, realistically, copy/paste) that code in their own projects.
What should I propose as a workable common source repository for a team of at least 10-12 full-time devs, plus anywhere from 5-50 (very) part time developers who are temporarily loaned to the contract group for specialized work?
The answer required some cultural information for any chance at a reasonable answer, so I'll provide it here, along with some of my thoughts on the topic:
Developers will not be forced to use this repository. The barrier to
entry must be as low as possible to
encourage participation, or it will
be ignored. Sadly, this means
that anything which requires an
additional software client to be
installed and run will likely fail.
ClickOnce deployment's about as
close as we can get, and that's awfully iffy.
We are a risk-averse, Microsoft shop. I may be able to sell open-source solutions, but they'll be looked upon with suspicion. All devs have VSS, the corporate director has declared that VSTS is not viable going forward. If it isn't too difficult a setup and the license is liberal, I could still try to ninja a VSTS server into the lab.
Some of my fellow devs care about writing quality, reliable software, some don't. I'd like to protect any shared code written by those who care from those who don't. Common configuration management practices (like checking out code while it's being worked on) are completely ignored by at least a fifth of my colleagues on the contract team.
We're better at writing processes than following them. I will pretty much have to have some form of written process to be able to sell this to my manager. I believe it will have to be lightweight, flexible, and enforced by the tools to be remotely relevant because my manager is the only person who will ever read it.
Don't assume best practices. I would very much like to include things like mandatory code reviews to enforce use of static analysis tools (FxCop, StyleCop) on common code. This raises the bar, however, because no such practices are currently performed in a consistent manner.
I will be happy to provide any additional requested information. :)
EDIT: (Responsing to questions)
Perhaps contracting isn't the correct term. We absolutely own our own code assets. A significant part of the business model on paper (though not, yet, in practice) is that we own the code/projects we write and we can re-sell them to other customers. Our projects typically take the form of adding some special functionality to one of the company's many existing software products.
From the sounds of it you have a opportunity during the "post-mortem"to present some solutions. I would create a presentation outlining your ideas and present them at this meeting. Before that I would recommend that you set up some solutions and demonstrate it during your presentation. Some things to do -
Evangelize component based programming (A good read is Programming .NET Components - Jubal Lowy). Advocate the DRY (Don't Repeat Yourself) principle of coding.
Set up a central common location in you repository for all your re-usable code libraries. This should have the reference implementation of your re-usable code library.
Make it easy for people to use your code libraries by providing project templates for common scenarios with the code libraries already baked in. This way your colleagues will have a consistent template to work from. You can leverage the VS.NET project template capabilities to this - check out the following links VSX Project System (VS.Net 2008), Code Project article on creating Project Templates
Use a build automation tool like MSBuild (which is bundled in VS2005 and up) to copy over just the components needed for a particular project. Make this part of your build setup in the IDE (VS.NET 2005 and up have nifty ways to set up pre-compile and post-compile tasks using MSBuild)
I know there is resistance for open source solutions but I would still recommend setting up and using a continuous automation system like CruiseControl.NET so that you can leverage it to compile and test your projects on a regular basis from a central repository where the re-usable code library is maintained. This way any changes to the code library can be quickly checked to make sure it does not break anything, It also helps bring out version issues with the various projects.
If you can set this up on a machine and show it during your post-mortem as part of the steps that can be taken to improve, you should get better buy since you are showing something already working that can be scaled up easily.
Hope this helps and best of luck with your evangelism :-)
I came across this set of frameworks recently called the Chuck Norris Frameworks - They are available on NuGet at http://nuget.org/packages/chucknorris . You should definitely check them out, as they have some nice templates for your ASP.NET projects. Also definitely checkout Nuget.
organize by topic, require unit tests (feature-level) for check-in/acceptance into library; add a wiki to explain what/why and for searching
One question: You say this is a consulting group. What code assets do you have? I would think most of your teams' coding efforts would be owned by your clients as part of your work-for-hire contract. If you are going to do this you need to make absolutely certain that your contracts grant you rights to your employees' work.
Maven has solved code reuse in the Java community - you should go check it out.
I have a .NET developer that's devised something similar for our internal use for .NET assemblies. Because there's no comparable .NET Internet community, this tool will just access an internal repository in our corporate network. Otherwise will work rather much the way Maven does.
Maven could really be used to manage .NET assemblies directly (we use it with our Flex .swf and .swc code modules) is just .NET folk would have to get over using a Java tool and would probably have to write a Maven plugin to drive msbuild.
First of all for code organization check out Microsoft Framework Design Guidelines at http://msdn.microsoft.com/en-us/library/ms229042.aspx and then create a central Location source control for the new framework that your going to create. Set up some default namespaces, assemblies for cleaner seperation and make sure everyone gets a daily build.
Just an additional point, since we have "shared code" in my shop as well.
We found out this is very much a packaging issue:
Whatever code your are producing or tool you are using, what you should have is a common build tool able to package your sources into a "delivery component", with everything used to actually execute the code, but also the documentation (compressed), and the source (compressed).
The main interest into having a such a "delivery package unit" is to have as less files to deploy as possible, in order to ease the download of those units.
The build process can very well be managed by Maven or any other (ant/nant) tool you want.
When some audit team want to examine all our projects, we just deploy on their post the same packages we deploy on a production machine, except they will un-compressed the source files and do their work.
Since our source files also includes whatever files are needed to compile them (like for instance eclipse files), they even can re-compile those projects in their development environment).
That way:
Developers will not be forced to use this repository. The barrier to entry must be as low as possible to encourage participation, or it will be ignored: it is just a script to execute to get the "delivery module" with everything in it they need (a maven repository can be used for that too)
We are a risk-averse, Microsoft shop: you can use any repository you want
Some of my fellow devs care about writing quality, reliable software, some don't: this has nothing to do with the quality of code written in these packages modules
We're better at writing processes than following them: the only process involved in this is the packaging process, and it can be fairly automated
Don't assume best practices: you are not forced to apply any kind of static code analysis before packaging executable and source files.