On Mon, 31 Aug 2009 13:03:33 -0700 Mike Payson <m...@kludgineering.com> wrote:
> On Mon, Aug 31, 2009 at 6:55 AM, Andy Eskelson<andyya...@g0poy.co.uk> wrote: > is really relevant. > First, with a robust search feature, browsing by category would be a > secondary means of finding parts anyway. If you want an ATTiny13, just > search for it, you'll find it much faster than navigating > ICs>Microcontrollers>Atmel>ATTiny. It doesn't matter if someone > accidentally tagged the ATTiny13 as a resistor instead of a > microcontroller, it will still come up when you search. That's debatable, but I understand what you are saying. > > But even ignoring search, it still isn't a big deal. There would be > only one file where all the parts would be stored, so the concept of > Libraries would not really be present anymore. There are categories, > but they are simply a tag in a database. A part can be in one category > or a dozen or more, however many is relevant (for example, the ATTiny > could be in the categories ATTiny, AVR, and Atmel). It's certainly > possible that a user could add the wrong category label to a part, but > since any logged in user can make corrections to the part, this is > easily fixed and once it's fixed for one person, it's fixed for > everyone. I'm getting slightly confused here. Where is this database? are you proposing that kicad be implemented with a database system, or are you referring to a database driving the web site system? What I am talking about is dealing with changes to the LOCAL i.e user end and how that is managed. If you are talking about a DB in at the kicad end then I'm not too keen on the idea of one big file. You then talk about fixing for one person then it is fixed for everyone. That is implying that there is some form of two way communications between the local and web system. Sorry I think that's a very bad idea. I can't help but expect that there is going to be an almighty clash of something and everyone will get upset. I'm fairly happy with the idea of the web repository being managed by a DB, that's a logical way to do things. > automatically keep a complete copy of the repository on their local > computer that is synced once a week or so. I really dislike this syncing idea. I'm happy with users selecting stuff to add to their local libs from a repository but any auto update is asking for trouble. I suppose I've had too many systems messed up by auto update systems that it makes me uncomfortable with the idea. > > Parts would never be locked out. Doing so means that some volunteer I was more thinking that a part would be locked once it was approved. Thus preventing any further mods. Nothing stopping the creation of another copy as unreviewed if needed. > > There does need to be a way for a user to make changes that are only > available locally, but for the majority of circumstances, the changes > will probably be best if they are shared. I don't think I'll agree to that people are a bit too individualistic I think :-) > "The parts do not -NEED- to be embedded into the file". Doing so as an > option is fine. I disagree with the notion of setting this as the > default. I agree that if I were sending a file to my customer for > review, including the parts is a good idea, but if I'm sharing a board > on the Internet, including the parts is redundant. Regardless, this is > an implementation detail and not a major sticking point. Too different approaches, from my perspective I would want the integrity of the project to be maintained at all times, but as you say that could be implemented. > A couple important points to remember: > * Standard schematic symbols are not copyrightable. Yes they are. Many companies have their "own" symbol sets. If you copied the design used by Elektor they would be very upset. They have specifically said that they would not allow their symbols to be used elsewhere. Collections of even standard and freely available parts are copyright, not the parts themselves, but the collection of them. > * The part itself is copyrighted, but by the part manufacturer, not > the library creator. who may need to gain permission from the copyright holder depending on the terms, > * Any text descriptions are copyrighted, though if it's taken straight > from the datasheet, there is no practical violation. You cannot say that. . > > It's also important that you understand what is known as the 'Safe > Harbor' provision of copyright law. Because this system would be Has no meaning whatsoever. You cannot overrule any copyright regardless of where it is. Don't forget that this is an international group, laws vary from region to region. The USA safe harbor system provides a means of managing things, but it does not exclude, on top of that it seems to be aimed at protecting the ISP holding the files, not necessarlly the owner of those files. Really needs an expert comment of that tho, as I don't know anything about the USA system. > > Yes, but you can't do protect yourself if you don't understand the law > in question. In this case, the law gives explicit protection to this > sort of service. We do need to consider the legal issues, but they are > absolutely not reason to prevent this proposal from moving forward. > > Copyright is a really strange thing, and it is causing all sorts of issues, but generally with written works the copyright is with the originator, this is normally an individual, or in many cases with a company who under employment contract take the rights to work done by their employees. You cannot give copyright away, it always resides with the author. The copyright holder can attach whatever conditions they like to their material up to saying that anyone can use it in anyway they want, but the copyright still resides with them. Providing that you make all reasonable efforts to follow the various copyright conditions, whatever they may be, then there should not be an issue. Taking down suspect items from a website is all well and good to resolve some problems, but whoever uploaded the material in the first place could end up in hot water. OK Unlikely in this particular case but why expose yourself to the possibility of trouble. Uploader: Who owns the copyright of the file you have just uploaded? What are the restrictions, if any, of this file? Do you have permission to upload this file? That's pretty much all you need to ensure, but it covers your back. >> But then you have sort of a chicken and egg problem. You can't have > of today, how many parts do you suspect that people have created for > KiCAD that have not been shared with anyone? Prob quite a lot, but the question is how useful they would be to others :-) > > All of these issues are based on a flawed understanding of what I'm > proposing. The notion of 'libraries' goes away under my proposal*, and > is replaced by a simple database. Do you want to override the pin > names of a part in you local copy of the library? No problem, a new > record is added in the "pin name" table of the database. That record > would never be overwritten, because the entire library is never > overwritten. Individual parts in your database would be overwritten, > but only if they are not in use in any of your projects**-- If they > are, the new version is downloaded, but the old version is kept as > well. That way you would always have the most current version of a > particular part for new projects (if you want it), but the old version > remains in your library as well. You no longer "download a library > file", instead you just add parts to your local database. Managing > your local library of parts is now trivial, since the vast majority of > it is done automatically in the background. It sounds to me as if you are proposing to have some sort of DB at the user end. I have some reservations about that as I have already said. Unless it is very very simple i.e. based around simple flat text files then it has the potential to go very wrong. Which is why I am so adamant regarding libs and where they are held. I'll now add to that to HOW they are held. I am very uncomfortable with the notion of things updating automatically. > > * To be clear, the existing libraries would probably remain available > at the start, though it makes little sense to maintain both systems in > the long run. That is going to be dependant on the final system. But whatever happens the user must have libs stored locally and that is where the project should obtain them from. > ** A side benefit of this feature would be that it would be easy to > get a list of every part you use and in what project you use them in. > Probably many other cool uses as well. Once you have a database, there > are all kinds of cool things that can be done with it. You can already generate a parts list so that function could be done now with a bit of work, however unless you do a similar cross reference system, you would appear to be thinking of adding data to the lib database that would indicate what projects a part was used on. Sorry no, I really don't like that idea, I'm not very happy about databases at the user end in the first place. but this seems to be adding complexity for it's own sake. Keep the lib management totally clean, and leave it at that. Building up other functions I think should be left to other applications. Andy
