A licence is just a bunch of legalese. You can use existing licences but it doesn't mean you cannot make your own licence from scratch. As long as clients are informed pre-development what restrictions will be applied there shouldn't be a problem. Of course, bear in mind that really restrictive licences can cause potential customers to baulk and not go for a solution with your company.
The problem after that is policing.How will you ever really know if the customer or another developer re-uses your code? While obfuscation/code encoding isn't foolproof as a protection mechanism it is something. A licence just gives you a legal route to take if you catch someone using what you don't want them to. On Tue, Nov 17, 2009 at 7:06 PM, Richtermeister <nex...@gmail.com> wrote: > > Hey Gareth, > > this is somewhat how it's currently working.. our own core plugins are > the same for every project, and the real product the clients are > paying for is the application-level customization/configuration/ > additions. We're just concerned that with every app we deliver, we > also deliver our core plugins, and we don't want another company to > start building websites with it and make a profit of our invested > work.. > > Encoding sounds like an option. Ideally I would like to have a license > that says that while the client is free to modify the site for their > own purposes, they are not allowed to use our building blocks in other > projects. Is there such a thing? > > Thanks for the help so far. > Daniel > > > On Nov 16, 10:24 pm, Gareth McCumskey <gmccums...@gmail.com> wrote: > > One way to do it is to design "your" CMS in such a way that any customer > > additions can be totally isolated plugins on top of your base of code. > That > > way you can provide tghe solution to your customer with full rights to > the > > plugin that was specifically developed for them and keep your CMS > > proprietary with whatever licence you decide. There are also ways to > > obfuscate or "encode" your own code to disallow editing of "your" CMS > > portion and leave the customer-specific code open for them to edit as > they > > wish. > > > > > > > > On Mon, Nov 16, 2009 at 8:09 PM, Richtermeister <nex...@gmail.com> > wrote: > > > > > Hi all, > > > > > our company is slowly shifting from selling "all custom" websites to > > > websites built on symfony + our own set of CMS plugins, and the > > > question of code ownership is starting to come up. > > > > > Traditionally we simply said that the client buys the entire site > > > including code and is free to do whatever with it. That was usually no > > > issue, because each sites was different and there were no "company > > > assets" included. > > > > > With the new approach this obviously changes a big, and we were > > > wondering how / if other companies out there handle this issue. For > > > example, we're not concerned what our immediate client do with the > > > delivered code, but we're wondering what happens when they change to a > > > different web company, and that company decides to build sites with > > > "our" cms. > > > > > Thanks for feedback, > > > Daniel > > > > -- > > Gareth McCumskeyhttp://garethmccumskey.blogspot.com > > twitter: @garethmcc > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google Groups > "symfony users" group. > To post to this group, send email to symfony-users@googlegroups.com > To unsubscribe from this group, send email to > symfony-users+unsubscr...@googlegroups.com<symfony-users%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/symfony-users?hl=en > -~----------~----~----~----~------~----~------~--~--- > > -- Gareth McCumskey http://garethmccumskey.blogspot.com twitter: @garethmcc -- You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-us...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/symfony-users?hl=.
