Slashdot Mirror
Open Source/Proprietary - An Issue of Two Codebases?
g00mba_b0y asks: "For the past year I and a small team of developers have been working on an open source targeted, general business application framework. I say targeted because we have not yet selected a licensing model and placed the code in the public domain (we are working on some specific functional targets). I recently demonstrated the framework to a potential client who liked what they saw, and wants to use the software for their flagship product. In addition, they want to hire me to further the development of the framework as well as participate in the development. The sticking point is the structure of the legal agreement. I'm really interested in two things: the experiences of developers who are doing something like this (how did you address the IP issues); and links to any information on this subject."
"We agree in principle that the framework related development that they will be funding should be available for open source licensing, while code related to their business should remain proprietary. The tough part is coming up with a legalese definition of where the boundary lies, and a means of addressing disagreements when they occur.
I've done my homework and found a ton of information on licensing strategies, motivations for OSS, etc., but nothing so far that addresses how companies, who are funding open source initiatives alongside commercial development efforts, draw the line between the two."
Unless another Korporate law gets passed, of course...
It's Christmas everyday with BitTorrent.
Would this be anything like the difference between mozilla and netscape?
Mozilla is open source, and is what Netscape is/was based on, however Netscape added additional features like AIM.
dual licensing. you can obtain a mysql database under gpl, or you can purchase a mysql database license from the company that develops it if the gpl doesnt suit your needs. this also applies for mysql drivers.
Curl up in the corner in the fetal position and cry yourself to sleep. It may not get you a job but there's a lot less legal wrangling. :D
Wouldn't it make sense to open source the code that has been developed BEFORE you've been employed by the company? At that point, you own the code.
At the point where they hire you to write MORE code, it is legally theirs, as they paid for it.
Wouldn't that be a reasonable solution to the problem? After all, as a mechanical engineer anything I develop while I work for a company they own. I don't see why software "engineers"... should be any different.
Just release 2 versions. GPL & Alladin Ghostscript.
As long as you don't have an exclusive agreement with them it isn't really an issue. License one to the customer however they want, license the other however you want to others.
OBDisc:I don't know anything about your product...
/t
Seems to me that if it's a modular/plugin architecture then the framework and some modules can be OSS whilst other modules are proprietary. As i understand it, this is how the netbeans IDE works. (let's try not to get bogged down flaming SUN's Public License - i'm sure this kind of thing could work under an Apache License as well)
#!/usr/bin/english
Never forget the power of dual-licensing. If the body of developers is small and you can get everyone to agree, you can always have the same code licensed under two difference licenses (similar to what the Qt people at TrollTech do).
However, if you ever accept patches from the general body of developers, you will have to make sure that author of the patch agrees to both licenses or redo the patch yourself.
Make the big-wig business people listen to this
the BSD License.
Seems as if Torvalds didn't have much problem doing this. But hes probably got more power to tell his 'boss' off than you do..
Well, the public domain is owned by the public, it can be seen by all, openly scrutinised, is inherintly more secure etc. Good job.
The IP is an interesting issue. Once released into the public domain, the public will own it... that's what the GPL, BSD licence and SCO say. You no longer have exclusive rights over it...
Someone else could do what the hell they like with it because the GPL has never stood up in court, and the BSD licence allows it. Like the IP-stack in BSD... everyone knows it was invented by Linux Torwaldis in 1974, but because the GPL has never stood up in court, BSD corporation (under orders from SCO IMHO) relinced it and claims it as theirs because their licence is better.
So, never release something in a public form. Infact, encrypt all your code... even when distributed... it should be decrypted every time it is run, and every time there should be an online fee paid to M$ and the RIAA for using their 16-bit secure coding system. That, my firend, is the only way to secure your code.
You can dual license your code if you are the copyright owner. You can release your framework to the world using the GPL and use a different license for your clients.
You must be careful with the license you offer to your clients, can they change your framework's code? can they make derivative products? Depending on the ammount of freedom you want to give them you may need to create your own license for your clients.
Life isn't like a box of chocolates. It's more like a jar of jalapenos. What you do today, might burn your ass tomorrow.
Have a look at Eclipse web site. IBM develops and sells WSAD and uses the open-source Eclipse framework for base functionality. FAQ's have a few scenarios under which you can use Common Public License (roughly the same as MPL) with commercial software.
"The deluded are always filled with absolutes. The rest of us have to live with ambiguity." - Aristoi, Walter Jon Willia
Repeat after me: placing IP into the public domain precludes any sort of licensing agreement.
Public domain means you have no claim of ownership.
You tell me how "whilst" differs from "while," and I'll stop calling you a pretentious jackass.
If it's public domain, there's no copyright on it, and you can't enforce any license. Public domain means that there are no restrictions on it at all.
You said they want to hire you. What about the people you developed this with ? Sounds like there is potential for jealously / fights.
I Am Not A Lawyer... You need a lawyer. Hire one and ask him, not Slashdot.
This sig has been temporarily disconnected or is no longer in service
Be really careful with using the term 'public domain'. If you put something into 'the public domain', then all licenses and copyright notices you attach to the program are for naught. 'Public domain' means something very specific in legal terms; it means that anyone can do anything they want, whatsoever, to your code, which includes removing copyright notices.
Asking the people who read Slashdot about these things is like asking Martha Stewart about investment advice. What do you think you're going to hear? I doubt you'll get a lot of useful legal advice on how to handle licensing and negotiations. But you're sure to get advice on how to give away your work more efficiently.
Close it up. Make a killing. That is also a freedom.
(hope you read at -1)
He's referring to the legal "public domain" term. Once a work is released into the public domain, there is no copyright restriction to it whatsoever. Anyone can use, modify or reproduce it however they want with no attribution to the original author. It can be released as part of any other product under any license or copyright.
If it is in the PD, you should still be able to copyright new code. However, you may be limited in the licenses you use. For example, public domain is not GPL-compatible (it doesn't have the GPL's added restrictions in the name of freedom).
As others have mentioned, look into dual-licensing. Have a lawyer write up a contract and license for you - it may save you headaches later.
I can't say that I don't give a fuck. I've just run out of fuck to give.
Either tell them to pony up and buy your dev time for the last year ... or BSDL(whatever you want) and they and every other company can start at the same point
The person asking this question needs to hire a lawyer who knows a little something about copyright. He obviously has no understanding of what releasing open source code means and what releasing something to the public domain means.
My suggestion to him, other than hiring a lawyer to explain a few things to him, is to just sell his code and his soul the the corporate devil. At least that way, he'll have some money.
Hey, if he wants to release his code to the public domain, that's great, too. However, then he'll have lost all control over who uses it and how.
Just be sure to wear the gold uniform when you beam down -- you know what happens when you wear the red one.
Does the FSF have any published opinions about this kind of issue that faces developers?
I assume from what you've written that the problem is that the person who wants to employ you does not want the source code to become open and you'd like to see an open source version of the code.
The key thing to clear up is who owns the copyright on the code. If you own the copyright then you can choose how and when you release the code (open or closed). But it's vital that you keep control of the copyright since it gives you the maximum flexibility. (This is achieved in my project, POPFile, through the POPFile License Agreement).
Specifically,
1. You should make clear to the employer that you hold the copyright and that the code is valuable property which you are willing to license to them in exchange for X.
X could be a job with them, or it could be $$$ or royalties. Exactly what depends on what you want out of the agreement.
2. The license to the company needs to be non-exclusive (giving you the freedom to license to someone else), or exclusive with an exception for an open source version of the code.
3. Once the agreement is in place release the code under the GPL. This will help protect the company's investment because anyone else using the code will be forced to release their code lowering the likelihood that someone else will try to make money off it.
4. When you get contributions from the community who are using the GPL code make sure that you get signed agreements from the contributors transferring copyright to you so that your source base is not contaminated and you maintain control of the copyright. (I've included the text of the agreement we use for POPFile below for reference).
5. Make clear in your contract with the company who owns copyright on the changes that they make or that you make while employed by them. The best solution is that you keep the copyright for yourself.
6. You should expect that the open source version of the code will make the company lower what they are willing to pay (they are after all sharing the code with someone else). You need to argue back that in fact you will be leveraging the open source community to improve the product free of charge to them.
The FSF has a page covering copyright issues here: http://www.fsf.org/licenses/gpl-faq.html
and here: http://www.fsf.org/licenses/why-assign.html
John.
Here's what we use for POPFile...
[snip]
POPFILE LICENSE AGREEMENT
CONTRIBUTION DESCRIPTION:
John Graham-Cumming ("jgc") acknowledges, with many thanks, the receipt by jgc
from Licensee of the above-described Contribution ("Contribution") to the
POPFile software and its related documentation.
Licensee confirms to jgc that, to the best of Licensee's knowledge and belief,
the Contribution is free of any claims of parties other than Licensee under
copyright, patent or other rights or interests ("claims"). To the extent that
Licensee has any such claims, Licensee hereby grants to jgc a nonexclusive,
irrevocable, royalty-free, worldwide license to reproduce, distribute, perform
and/or display publicly, prepare derivative versions, and otherwise use the
Contribution as part of the POPFile software and its related documentation, or
any derivative versions thereof, at no cost to jgc or its licensed users and
without any accounting obligation to Licensee of any kind, and to authorize
others to do so.
Licensee hereby acknowledges that jgc may, at his sole discretion, decide
whether or not to incorporate the Contribution in the POPFile software and its
related documentation.
EXCEPT AS OTHERWISE PROVIDED HEREIN, LICENSEE MAKES NO REPRESENTATIONS OR
WARRANTIES, EXPRESS OR IMPLIED, WITH RESPECT TO THE ABOVE-DESCRIBED
CONTRIBUTION. BY WAY OF EXAMPLE, BUT NOT LIMITATION, LICENSEE MAKES NO AND
DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY
PARTICULAR PURPOSE. IN NO EVENT SHALL LICENSEE BE LIABLE TO USERS OF THE
CONTRIBUTION FOR ANY INCIDENTAL, SPECIAL OR CO
Can you build the proprietary code as a separate library that builds upon the public framework? Then open-source the lower framework and keep the proprietary code closed. Thinking of an analogy... ah! Open-source the C standard library, but build libgif on top of it and keep libgif closed-source. The application may or may not be amenable to vertical splitting like this; this just looks like the easiest way with the least paperwork & red tape. Not two codebases - two projects.
Save time now so you can waste it later
I don't honestly see what so difficult:
.02 dollars
What u have developed thus far, you should open-source
What u will add to the framework that will be useful to other potential users of it, you should also open-source (this is why they r funding yer open- source development)
What u develop specifically for the clients' implementation of yer framework, Should be their's, propiatary, and not included in the framework.
I dont see a terribly large grey area in this!
just my
If the code is structured to make it easy to differentiate between the proprietary part and the open source part, this shouldn't be a problem. If you don't, it won't just be a legal problem, it will be a mantainance nightmare.
Give the proprietary section and the open source sections clearly different names, place the source for each in different places with different file names, and use those names in the contract.
For example, in Java, I would have two separate code bases: com.thecompany and org.myproject. I would keep a separate source directory for each, including separate build scripts (although the proprietary one might call the OSS one.) The legalese would refer to the "org.myproject" code by name.
Finally, when in doubt, place new code in the proprietary base. You can always migrate it into the OSS one (I hope!), but once in the OSS one it's hard to get out. That's true of any library vs. application or private vs. protected vs. public (source, not legalese) decision: start restrictive, and migrate out.
Is subject to negotiation and specification. It's entirely up to you and your client to define it. I think the real sticky point is defining it well, and conducting the conversation in a non-confrontational way.
I think if you approach them in a friendly and open fashion, and talk about your concerns and commitments, they'll listen. You sound like an honest person, you're clearly not trying to rip them off, otherwise you wouldn't be troubled by this.
One guideline is special purpose/general purpose, which is vague. A more specific one is what gives your client a competitive advantage, versus something they wouldn't care whether their competitors had it or not. An example of the latter would be things like payroll software.
Your client probably has a pretty strong attitude on that subject. It would be important to know what it is before deciding how to proceed.
'In knowledge is power, in wisdom humility.'
Various Licenses [both free and non-free]
Google Directory [Software >> Licensing]
I personally have no experiance, or legal expertise. However, I'd say, to figure out your borders of open/closed source... If your code will run without the business software you're writing, then it's officially open source framework. It's it's "extra" and related to that business software, then that code is closed source. Just an idea. Good luck!
And they'll be happy.
I can't believe nobody has modded down this crazy troll yet. (talking about parent...)
You're problem sounds like something that the LGPL was designed for my personal opinion. As you are designing the general framework (LGPL it) you can attach ather parts that is not opensource.
It is relativelly easy decide (with you're benefactor) what modules should be LGPL and which not. If a module could benefit from the OpenSource movement LGPL it.
The rest you can keep nice and hidden.
You're problem of course is finding the balance. I would personally try and get the benefactor to agree to release everything to GPL once a certain time or alternativelly certain events occur (version is not maintained anymore, company goes bust). This will benefit the company as well as you in the long run as unsupported version will generate a user community and this user community will mean more potential clients.
As it's business software the chances are that there is a considerable amount of support revenue that will be generated even from old version in GPL, LGPL.
What about coding the thing to the Interface?
So the OSS framework remains OSS and has well defined interfaces that proprietary plug-ins can implement.
Language specific features would help too. For example in Java jar files (code archives) can clearly separate "my code" from "your code" and the Factory classes can instantiate plugins dynamically without being aware of their proprietary nature.
IP legal problems, like any legal problem, are highly fact-dependent. Yes, it may cost you some money to get a legal opinion. I guarantee it will cost you MUCH more if you don't and have a disagreement later. According to the latest AIPLA (American Intellectual Property Law Association) survey (2001), an IP dispute with $1-3 Million at stake will cost approximately $500,000 to litigate. On the other hand, you can probably get a decent legal opinion for about $10,000 depending on the complexity of the issues.
Recap: $10K for an opinion that minimizes the risk later vs. $500,000 to litigate plus all the headaches / publicity / business interruptions of litigation. You decide.
Laws affecting technology will always be bad until enough techies become lawyers.
They'll give it away and then try to charge people for it (Just make sure you keep the copyright and only sell them the right to distribute!)
Let SCO fight your legal battles. They should have plenty of experience by then.
Kinda reminds me of the the current Liberal ad campaigning on CNN have been pushing "Those atrocious Mothers". That indignent, compulsive and daangERous (spooky music) demographic have been known to have hide around corners to scare children shitless and taking *great* pleasure in innocences lost with a taste of pure lemon juice. The humanity.
Identified by high pitched squawking, jeers and laughter. Common phsyical appearence sometimes squash breasted short hair and/or bowlegged. These people are to be concidered armed and very dangerous. They are not to be confronted in anyway, please contact your local police department immediately.
BTW-is it me or has cpac and cnn liken unto "Americas' Dumbest Criminals Caught on Tape". I'm refering to the medium and not the content.
----------------Artificial wombs (...on two legs)-----------------
This allows Sun to defend against licensing violations as they come up (since there is no ambiguity as to who owns what). They also sell a commercial fork with some proprietary extras (more fonts, extra file filters) to the business community with no worries.
In the past, one of the projects that I worked, we seperated the client from the server. The server side was to be GPL, the library to interface was LGPL, and then the client side was to be closed. We were also suppose to create a simple web front-end to the server using the library so that it would encourage development. However, that was 2.5 years ago in colorado, just before the tech meltdown (thank you govenor owens for such wise picking of tech companies to come here and then fold ).
The author is developing a framework, which is to be OSS (of some sort). He's also (potentially) developing another body of code, which is specific to one company and closed.
The question is how to separate the two. The GPL is almost certainly inappropriate, as its purpose in life is to infect the "linked" code and force it to be released under GPL as well.
The LGPL exists precisely for this reason. It does not require the linked code to be released under GPL (or LGPL). If you can separate the framework and the app, then this may be the way to go.
(If you can't separate the framework and the app, then it's not really a framework! Maybe a bit of redesign would be needed to keep the separation between modules clean.)
Dual licensing doesn't really solve the problem. Or, rather, it only solves it for one single customer and one single release. You could craft a license for this user that allows them to keep their code, while also releasing the framework under, say, GPL. But then when the customer wants an update, they can't just go and grab the GPL version of 1.1 and use it without GPL'ing their code. And their original license wouldn't apply to any updates. Rather than try to track every customer and every release so that you can keep reissuing special licenses, it would seem to make more sense to adopt a license without the "viral" quality of GPL in the first place.
If you're willing to allow one customer to use the framework in a proprietary product, then it would seem that you don't have a major ideological free-software axe to grind, and thus don't need the GPL stick to go with your software carrot. So it seems you might as well be willing to allow anyone to use that framework in their code. In which case, any of the simpler and "really free" licenses such as BSD would do.
If you do want just this one company to have special access to the framework -- perhaps as some sort of competitive advantage, since they employ you, or the reverse, in an attempt to have a reason for them not to fire you -- then dual licensing with the public license being GPL (to try to shut down other commercial competition) might be the way to go.
Can anyone give examples of 'acts' that constitute putting something in the Public Domain?
You probably don't want to wait to find out what type of licensing decisions Diebold makes now, as people already are helping them with programming problems.
I'm pretty sure that I've seen contracts where employers attempt to claim that anything you create (which is in a field related to your work) while employed by them is theirs, whether done on "company time" or not. Now, I realize that the best thing to do would be to refuse such a clause, but assuming that didn't happen, is it legally enforceable?
WMBC freeform/independent online radio.
Software licensed under an "open-source" license is
<it><b><blink>NOT </blink></b></it>
in the public domain!!1!!!oneone1
Liberal (adj.): Free from bigotry; open to progress; tolerant of others.
Remember, you are holding all the legal cards regarding the code at this point. They are just holding some money.
We have done this sort of thing for several years, and never found an acceptable broad license and contract provision to cover it. The only things that has worked well is to base the agreements on specifications, saying "implementations of interfaces marked A are ours, implementations of interfaces marked B are yours". Of course, the specification always changes (evolves, matures), so there is a constant review and negotiation process. So you end up saying (in the agreement) something like "the parties will from time to time meet and confer to extend the specification, and set the licensing for new or modified interfaces in the same manner as has been done already in Exhibit 1".
It is a good idea to specify the general principles by which the code will be covered by this license or that, but the explicit division with a list of interfaces (or modules or components) should override the general principles. You can always amend the agreement later. If the relationship has broken down to the extent that you can't amend the agreement, then there is probably no point anyway to amending it. Then, at least what you have done up to that point is covered by the explicit decisions already made. Just don't go too long without a review and decision process. (It's good engineering anyway to review the specifications and agreements periodically, so that the customer gets what he wants and you have a consistent, considered design.)
In the end, if you don't have a good relationship, all the contract language in the world won't necessarily save you from grief.
Keep the code bases separate. There should never be any doubt what you claim belongs in one category or the other. Put a clause in the agreement that has the customer waive rights to protest the decision if he hasn't done so within some specific period of time from having become aware of the way you have classified things. Of course, during the review period you can't release any of the code to the public (or GPL or whatever), in case it turns out your decision was inappropriate, else you will have released your customer's proprietary code which might be a breach of contract or trade secret law.
Doesn't the BSD License cover this. Basically AFAIK you can have your open source stuff out however any changes made can be kept closed source and sold as you see fit
HTH
Rgds
Rus
Cheap UK and US VPS
I know all the everything should be free zealots will scream at this but look at Linus himself this is exactly what he advocates! Richard might faint and rant but someone has to wake up and put OSS into the real small business and desktop world.
If however you intend to also use closed source Windows software then you are screwed. Unless your in the business of creating a modified Windows plus OSS software business system framework, at which point you might produce something better than MS and quickly lose business to a clone from Microsoft itself!
OH THE SHAME I fell off the wagon and use sigs again!
Look at any moddable game, but perhaps specifically at anything out of id software - they decide a "cut off" point for their functionality: stuff that's "core" to the engine goes in an EXE, stuff that should be moddable goes in a DLL. (Grossly over-simplified). Would a similar distinction apply to your stuff, perhaps in reverse? Anything that goes in the framework DLL is Open Source?
Like the IP-stack in BSD... everyone knows it was invented by Linux Torwaldis in 1974, but because the GPL has never stood up in court, BSD corporation (under orders from SCO IMHO) relinced it and claims it as theirs because their licence is better.
I can't tell whether you are trying to troll, or be funny. Either way, you can't seriously believe that BSD got it's TCP/IP stack from "Linux Torwaldis" (It's Linus Torvalds). Linux actually took the BSD TCP/IP stack, but later replaced it with their own version.
I've thought about it for a while, and decided you were a troll... but I already typed my reply up, so you have to put up with it now.
Not Free(as in beer). Free(as in "I'm free to beat you over the head for being a dumbass")
Under the Berne convention, and various local laws depending on where you are, there's some rights that are inalienable, and cannot be transferred to the public domain even if you want to!
One simple example is artist recognition -- if Richard Stallman publishes and article and places in the Public Domain, he hasn't given me the right to strike his name from "by Richard Stallman" and insert my own name. He doesn't have the right to do give away that right, as it's inalienable.
"Inalienable rights" is a strange concept to Americans in particular, where *everything* is a commodity, but there's international laws and treaties that in some cases supersede the cultural rules.
Regards,
--
*Art
if(company.offering.you.a.large.truck.load.of.cash ) {
take.the.money.and.run();
}
else {
stick.to.your.principles();
}
Licensing is tricky, and it fundamentally affects what you can and can not do later on - once it's Open Source, it's hard to go back. .plan file indicating world domination in 3 releases...
Here's what I'd do : hire a lawyer !
Work out why you want to go the Open Source route - it's morally good, and can make good business sense.
But if you're building an application that is very specific to a particular industry, it may not make sense. For instance, if you're writing software to automate the day-to-day running of a law firm, you prob. won't get much community input; you say you have a framework (check out www.jcorporate.com for ways of dealing with the "framework/application" licensing issue), but how much of the framework is generically interesting ?
As a business, Open Source is a very powerful way of getting traction with a piece of software. But you also have to feed it, keep the community happy, administer the rights of people to commit to CVS, ensure the project retains momentum - it's no free ride. And we really don't need another projet on sourceforge with a "pre-alpha 0.001 release" checked in 3 years ago, and a
Open Source is absolutely right if your project makes sense to the OS community, and if you can expect significant contributions from the community in return. Don't go Open Source because you feel you should to retain street cred.
If you do decide to go OS, I'd suggest taking your code base, and take each source file - write the names on index cards - and split them into "Open", "Proprietary", "Not sure" (ideally with your sponsoring company). Hopefully, this process will help you decide where the boundary lies - it's a lot easier to decide when you're looking at concrete source files than discussing it in the abstract on slashdot...
That should make sorting out the rest of the files fairly straightforward.
Oh, and get a lawyer.
It's all very well in practice, but it will never work in theory.
>>Fennemore Craig counsels clients on: Internet and e-commerce issues; protection and licensing of patents, copyrights, trademarks, and trade secrets; and branding strategies (collectively referred to as intellectual property). The intellectual property practice group includes attorneys with technical degrees and attorneys with business degrees. All have extensive experience with Internet and high technology issues. Clients include a range of domestic and international businesses from Internet start-ups to large multi-nationals, in industries ranging from computer software and hardware to pharmaceuticals, toys, games, optics, and electronics.
It's a start...
Error encountered in IAWebSig.clsSig.Create: Last Procedure: sPrc_Ins_tblSig
At least one person understood what the actual question was :)
I think it depends on what you mean by "general business application framework."
For instance, I've written a web content-management and application development API, and released (sorta) the API under the Library GPL agreement.
If I understand what I've done correctly -- and I think I do - - anyone can download my API, link to it, and build whatever the hell they want to on top of it, and distribute that application as they see fit, with our without their application's source code, for profit or not. They *must* redistribute *MY* api, however, with the source code, license notification, blah blah blah blah.
As long as they do *not* add or alter the code to the API, and *only* build on top of it, that's all they have to do. However, if they make changes or additions to the API code itself for whatever reason, they *must* distribute the source code for that change to the API. (In which case, it's probably in their best interest to *not* make proprietarily beneficial changes to the API.)
However, what's to stop them from creating a call _similar_ to those I've got in my API, but saying "uh-uh. this isn't a part of your API, but is instead a similar, but PROPRIETARY API that just happens to play nice-nice with your own API."? The answer: probably nothing. Yeah, it's a dick move, but what corporation isn't built on a giant pile of dick moves upon dick moves upon dick moves? My only hope is that someone wouldn't do this, but there's generally nothing you could do to stop them if they wanted to take that wise-assed approach, except maybe tell them to get bent because you're no longer supporting them. (Or, make your own dick move and upgrade the API with lots of neat bells and whistles, but release that version with a very hefty enterprise license fee. *evil grin*)
Without knowing your specifics, I can only assume that your situation is similar to mine. I'd say that if you're asked to change the framework itself, that it's a change that should be open-sourced, but if it's a change to the application built on top of the framework, it's probably their's to do with as they please.
Ed R.Zahurak
You know, oblivion keeps looking better every day.
If it's public domain, there's no copyright on it, and you can't enforce any license. Public domain means that there are no restrictions on it at all.
And oddly enough, it isn't thought to be sufficiently free. (Or Free, or phree or
> I say targeted because we have not yet selected a
> licensing model and placed the code in the public
> domain
Are you going to license it or place it in the public domain? You can't do both.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
For Helix Community, we have a dual-licensing model which gives the community an OSI certified license (RPSL), and a more commercially focused license (RCSL). Additionally, there are components that remain proprietary.
Where do you draw the line? That's always tough, but having the dual-license makes it easier to err on the side of opening up "too much".
Rob Lanphier
Helix Community Coordinator
I put together a small team of people I knew who were also interested in the same general thing, and who were all fleeing like lemmings from the boo.com meltdown, and we thrashed out a rough design and worked out a budget and, issues of funding and business admin aside - sheesh startups - we built a bespoke sattelite reinsurance exchange based on cocoon, tomcat, apache server, outrigger and the jini1.0 stuff. we built it in three layers. the first, as the end result was to be a web app, was in retrospect not dissimilar to apache struts but tied cocoon to the javaspace (you can see more detail on this at O'Reilly's OnJava site) and used xsl to render the pages. The little bit of bespoke code we wrote to shuffle objects between cocoon and the space we dubbed Crudlet and declared it to be open source targeted, and registered crudlet.org. The package name was org.crudlet. The next layer provided the generic b2b exchange and negotiation layer. We called it tennis because it represented a series of exchanges across a net. It too provided very generic functions and so was also open source targeted as org.curdlet.tennis as it builds on crudlet. The final layer contains the actual business knowledge - What is an offer of capacity on M$300 worth of Ariane 5 launch. What's the launch schedule for the next few years etc etc. What's a reinsurer? These things all went into a com.risk2risk package that extended the classes in tennis and crudlet and was considered to be proprietary to the company.
We recruited developers from the various OSS projects we used when we could, and made ot very clear to new recurits how the code layers were structured. We also got complete approval from the Board of Directors to pursue this strategy. The fact that I was one of three like-minded technical directors also helped of course. But we were well outnumbered by the suits who were very sceptical at first. A further project grew out of the team - a kind of javasapce backed version of hibernate or castor - called javastore but it never really went anywhere.
Much of what we open sourced was rapidly superceeded by things like Struts and Hibernate and Karajan (which grew out of crudlet) and when the whole reinsurance industry melted down post Sept 11 2001 and the whole project was put on ice by the investors, the only code that was really iced was the proprietary layer. The developers showed incredible loyalty, committing bug fixes on their very last day of work that kind of thing, and I still keep in touch with many of them.
The business arguments were all around costs. OSS == cheaper. Developers will work for less if they get to keep their code after the project is done. Developers can be excited by things other than money. As long as the basic rate is comfortable for them, and that's always a subjective matter. Sure there are other good reasons for OSS, security, corporate tranparancy and accounability, due dilligence etc, but the bottom line with investors is always the bottom line. Anything else is just woolly for most of these people. Also the ethos of open source permeated the team - everyone worked on the inside of a huge oval shaped ring of desks. lots of power mac g4s running osx, a nice rack with some great hardware in it, a groovy office in soho, cvs servers, a network admin who loved his job. and everyone being paid to write code 90% of which they would get to keep afterwards.
I used to have a better sig than this, but I got tired of it
You might also want to see the ghostscript model. Artifex develops a commercial version, then releases an open source version a year later. This allows them to keep the "crown jewels" for a year to benefit from financially.
I believe Apache also sells commercial licenses.
Basically, if you do the work, you own the copyright. As another poster said, make sure you don't lose that control.
"Software should not be owned! So don't place your work into the public domain!"
--RMS
The Open Source Initiative has a number of certified open source licenses intended for precisely the purpose you describe (if I understand you correctly). See http://www.opensource.org. One example is Eclipse which is licensed under the Common Public License. This license is non-viral and allows derivative products to be licensed under more proprietary terms. (Although of course the open source bits remain open source.) IBM (and other companies) have commercial products based on Eclipse. See http://www.opensource.org/licenses/cpl.php.
Any boundary you draw between the open and the closed part will likely turn out to be sort of artificial. When you work for your customer you will inevitably also think about improvement of the open source part of your software. On the one hand this makes it hard to impossible to maintain a clear separation. On the other hand this might give you the freedom to decide after the contract what belongs where -- if your customer is willing to accept this. If not, you are in trouble. You may end up implementing things where they don't belong, and waiting for somebody else to implement it again for the open source version. Mind that your customer may want to be the IP owner of everything you create specifically for them.
I'm working in a research institute. We were a similar situation when we sold a modified version of some software we created in the course of a research project. In our case the situation was rather simple as the system consists of three tiers, a core system, a user interface backend, and a user interface frontend, which made it possible draw a boundary between the core system and the features the customer wanted to have added, the latter being mostly user interface things. However, we also had to modify the core in order to implement everything, so it was a matter of agreement that the core system remains ours in its entirety.
Conclusion: If you make any enhancements specifically for a customer, make soure that working for that customer does not inhibit further development of your software. This is something to consider even if no open source licensing is involved.
I've had to deal with the same problem several times, as I've built a number of specific applications based on a common underlying framework, to which I retain the copyright etc.
Frequently, in the course of developing a specific application, enhancements to the underlying libraries are needed (thus the dual code-base and liscensing problem). I have always had good luck explaining to the firms who hire me that I can save a great deal of time (an money) when developing their application by utilizing my libraries. I agree to grant them a long-term liscense to use my libraries as a condition of the contract. My contract also spells out that any changes made in the underlying library are copyrighted by me, even though such changes may have been mandated by, and created as part of, their project.
I've had a couple of companies question this arrangement (huffy lawyer types mostly). I explain that I'll be more than happy to write a product entirely free of my libraries, but that doing so will doubtless add several hundred billable hours to the development/debugging cycle. They quickly conclude that as long as I agree not to charge ongoing fees for the use of my libraries they'll happily grant me the copyright.
So far, it's worked like a charm. If a feature is specific to their business, it goes in the application code, if it has broader application, it goes in MY code, I bill for the hours, and I have an even better set of libraries to dangle in front of the next client.
I agree, this is exactly what I've done at my work.
:=)) ), and it basically requires you to subclass my main class, one subclass for each table. Here, subclassing for normal usage is surely OK. But what about subclassing and replacing some of my methods? Would this form a derivative work or just be allowed use?
:=) ). A class could be subclassed to add new and specialized functionallity, like spesializing a database connect method to the weird set-up at work or just adding a closely related method which usage fits best within a subclass. To override a existing method to FIX IT or IMPROVE IT in some way, should be a violation of the license, as such changes should be commited back to the open source community.
I've developed (on my spare time) a python library for generating HTML text. I have released the library as LGPL on Sourceforge (the library is called forgetHTML, btw).
Now, as I started using the library at work, I found some bugs and small additions (more tags). Clearly submittable.
I used it inside the company product. Clearly company's property.
I then generated a special table class with support for sorting by column. As this is a general purpose class, with no interest at all for my employer (the project is for managing and monitoring network resources) this is submittable.
I then use this table class in a view to present services and sort them according to response times. No change of the LGPL-code, just usage. Clearly company property.
Now what I tend to wonder is the technical terms used in licenses like GPL and LGPL. They are clearly directed for code compiled from C and it's like, and linked together.
Now, the problem turns up with those libraries that are not just some compiled binary module to link with. What about python modules? Classes can be subclassed with proprietary code. Will that be legal? Will manipulating parts of classes from code outside (like changing the socket-module so a socket-call will go through your spesialized timeout-socket) be ok?
If subclassing is not OK, what about code that is meant to be subclassed? If it is OK, what about code that is not meant to be subclassed? Should authors of such software append to the license their view of subclassing?
I've also created a database abstracter library (named forgetSQL - as my html library is named forgetHTML
The issue here is if the author of the newly formed method is 'inspired' by looking at the original source or just looks at the API and 'guesses' what the method must do in addition to his addition.
IMHO users of my libraries should be able to use the normally, just as users of programs should be able to use them freely as the program. (Except for FrontPage, which explicitly tells in the license that pages created should not talk negative about Microsoft
My view tends to go with something that is disputable in court, what is really an improvement and what is just localization? Different people would feel different on these cases. Although, if you read the top of my post, honest programmers should be able to make a pretty good guess by them self.
What are your views on this? How do my license intension fit with my choice of LGPL?bAnd - which license other than LGPL could be best for my code according to my view (all patches are mine or my friends, it's easy to relicense any later versions)
How do Java-people feel about this? I'm technically capable of subclassing java.util.ArrayList and create a new version with the original behavour, but with say a improved indexing method. I might or I might not have looked at the source code (downloadable from Sun). I'm not looking in answers regarding Suns source license (I can read it my self), I'm looking for the general view from the Java developers, as Java products tends to come with classes and APIs freely available and usable, both with open souce and closed source versions.
Stain, vel! - http://stain.portveien.to/ Stian Søiland - stain@nvg.org - Trondheim, Norway
Was how do the Doj's lawyers feel about putting people in jail for trying to educate themselves? This area of law is under intense academic debate with solutions such as compulsory licensing being discussed. Enforcing a law to bring down a for-profit cd-stamping ring is one thing, it's completely another to throw a security researcher in jail for circumventing an ebook ROT-13 encryption scheme or make university students serve time for trading files.
what I've done in situations like this is just distribute the two separately. however these are usually custom apps that are only used by a small number of folks, not sold in a shrink-wrap box. I don't work on code that is sold that way because I only work on code that is distributed freely or not at all. your mileage may vary.
1) distribute your open source code under the GPL or whatever.
2) give your closed code to the client with patches for the GPL code, tell him to download the GPL code, install the pataches, then install the app. The closed code has a license (contract rather) that says what terms it can be distributed under..
That way, you keep them separate, and your client can't misappropriate your GPL code for his own wishes.
Don't listen to the FUD from folks on here about the GPL. When you have the copyright on the code, you can do anything you want with it.
And it isn't becuase some company that already has a monopoly can take the work, extend it in a non-compatible way and break all existing implementations, patent the change and threaten to sue anyone who attempts to interoperate. This is exactly what MS did to Kerberos.
http://creativecommons.org You may recall Prof. Lessing from his fight against the Mickey Mouse Protection Act (Eldred vs. Ashcroft). Createivecommons provides some fully worked out licensing schemes, providing a variety of options. From your brief description, I conjecture you might want to look up "Conservancies" on their site.
There is Case/Common Law that will require you to repay your customer every penny they gave you for that software if you begin giving it away for free, or "substantially" less than what they paid for it. From your post, you don't seem to be too swift when it comes to legal issues and instead of talking to an attorney you are posting to Slashdot, so you must have some self-destructive streak or you have been taken in by the communists and globalists looking to screw your parents and kids by brainwashing YOU.
Open Source means that when a company goes under or a company stops making the product there is a chance that its faults can be fixed with out need the company that made it. Now this does not mean that you are alowed to install it on more computers than your licence allows. Just that if it need fixing you do have the option of using you own programmer. Now I would not class microsoft shared source as a Open Source licience as you cannot fix your copys ie complier is forbiden from being used. A better option is that all mods have to be sent to microsoft inside 30 days of the change unless granted special permission not to. This would detect copyprotection remove attacks or if there was a copyprotection remove attack they were just as unlicence as what they are now that could have been a clause in the contract. Now this allows repairs to be made and tested by out side company microsoft would gain from the faster patch time and better testing of patches. Ie a broad range of hardware users to recieve beta patches.
There are almost no programs that could not be Open Source and Open Source software save companys money because that can see the source code and to change programs translation can be done from one format to another reducing data entry. Now are we in a free market or are we not. Open Source makes software a free market where the best and the cheapest live and the rest die. Now I don't think companys in the software market want to have to truely fight head to head as they will have to spend a lot of money to keep up with the game.
Open Source is not the end of the game it is just the start of a new stage where pirates loss there markets to stuff like linux and high grade apps have to be looking over there shoulder looking for the next attack. Poor grade products will no longer cut it. Main reason why microsoft is only now fixing a lot of faws that should have been fixed years ago.
-Completely Free---
Public Domain - no copywrite, use however you like
BSD - use however you like, just say thankyou, please...
-Mostly Free-------
LGPL - use however you like but give back/make available changes made to this library (keep clear line between end of library and start of app)
-Limits Use--------
GPL - use but product must also be GPL
Open Source(tm) - look but don't touch, or touch but don't sell/distribute, or look but don't write anything remotely like this or we'll sue. (see: Proprietory, NDA)
NDA: look but don't tell or do anything else we specify.
Proprietory - must work out a deal with copywrite owner
Dual License - use determines license (ie. KDE - GPL or Proprietory)
----------------
(Correct me if I'm wrong on any of the above.)
So the question is really, do you want other people to use it your code?, for free or only with permission/fee?, and do they have to share?.
If you really can't make a distinction between where your library ends and where your app starts (apart from the fact that you should probably clean up your code) you can still release the bits you want as LGPL and everyone has to share their additions except you (as the owner of the copywrite). But then if someone else then mixes in their own LGPL code into it you still have to play by the rules of that LGPL if you want to use this new version. Hmm.. ok, maybe its not so simple...depends if you're really just wanting free developers to extend components for you (while keeping other bits your own) or if you just want to be generous and if you get anything back that you can use that's just a bonus.
Perhaps maintain two completely separate programing teams? They can talk to each other all they like, but peopel only write code for their own project. It should then be fairly easy to let them work out the most rational choice of what code belongs in which project. Once the project matures a bit and the lines are clearly drawn you can relax the rules and let people work on both.
-
- - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
Let me give a more specific example - Let's say a month from now the client comes to me and says "Hey, we want the UI layer to be able to dynamically generate UI from XML screen definitions. I would make an argument that this is non-business specific, and therefore belongs in the framework, while they may make the argument that it was their idea, and should be considered part of their proprietary IP.
If we do disagree, what measuring stick do we use to determine if the proposed code is framework or proprietary? And if we still disagree, what is the process for arbitrating a final decision?
Just in the interests of keeping everyone up to date we have agreed to the following:
1) Any enhancements to functionality that is already represented in the framework will remain part of the framework.
2) When new functionality is introduced during the course of the project it will be evaluated to determine if it should be in the framework or remain proprietary. The employer would have final say on where the line is drawn (I can always walk away if I really feel strongly about it).
Relicense all the code to this new company in whatever form they prefer. The original open-licensed code will still stick around, and people can keep adding to it...
...but you can't merge their additions back into the non-open version...
No, you're mistaken.
The rights that the parent poster is talking about are what are called the "moral rights" of the author. Unlike copyright, they are nontransferrable and last in perpetuity. Many countries have strong laws protecting the moral rights of the author (France, I believe) while others have fairly lax laws (the US, for instance, and Canada).
Moral rights are often associated with (and in some cases protected by) copyright law, but in truth they are a concept orthogonal to copyright.
Moral rights are rights that an author has in relation to his or her work regardless of who owns the work. Moral rights do not protect "intellectual property" -- as such -- rather, they protect the reputation and vision of the author of a work. While an author may transfer his copyright (for instance, voluntarily, or in the course of his employment), he may not transfer his moral rights.
In North America, this usually means authors enjoy the right of attribution, where, in some jurisdictions, the author has the right to have her name associated with her work, or decline to have her name so associated.
In other systems of law, an author's moral rights go on to include rights regarding revisions/distortions of the author's work (right of integrity), the right to prevent one's name from being associated with works one did not create, and the right of an author to purchase all existing copies of her work and to prevent further sale (should she change her mind about what she's written, painted, etc.)
While a work in the public domain is not subject to copyright, it may very well be subject to various moral rights, depending on where you live.
If you want to know more, there's always Google.
bacchusrx.
Life after capitalism? The participatory economics project
No, because everyone likes camel claw. Except for GNAA. They like camel hump.
Mod me offtopic, but Linuxmagazine had an in depth report on POPfile in their May 2003 issue and a little blurb(?) in the July 2003 issue. It's a mail filter that learns, completely written in Perl and works on Windows, Mac Linux and Unix. Seems like a great piece of software. I can't find the link otherwise I'd post it....sorry
I think I can say that I can relate to your situation but my situation is still quite different. I spent the last year unemployed and working on my open source project. I was committing code to sf.net from the start with a BSD like license. I chose BSD because I didn't want any eventual employers to have a problem with the GPL's tough terms and decide that I couldn't use the code.
In the end (about two months ago), I really lucked out and started working for a very small financial company. They have little to no technical expertise and have left me to my own devices.
I still have to draw the line, just as you will, between application and framework code. For me that has been pretty easy to do so far. I understand that I am the party that has an interest in contributing to open source, not my employer. And by working on my open source project on company time I am basicly forcing the company to donate my time to open source
I justify this in my mind by saying the company is reaping the benifits of the last year while I was working on the project while unemployed.
So there are some similarities between your situation and mine. Take from it what you will. And try to keep the agreements as informal as possible.
Hopefully this article isn't too old so you don't get a chance to read this. I only read /. on weekends now ;).
The best way to write a closed-source program using open-source code would be to make it very modularized, and keep all the OS modules visible while the custom-coded stuff hidden?
In a related note: I've been playing around with Mesa lately, and thinking that once I get the knack of it I might build a 3dGL engine for myself (I've build a small one before on DirectX). Now, does this mean I must reveal where I call the Mesa functions, or just keep the Mesa modules themselves seperate (a non-issue in most cases)? If I must reveal where I make calls to Mesa, I could see 2 solutions:
Make the engine, make the source visible, and use it as a wrapper for whatever apps uses the engine.
Or, alternately, could I hide the full source, but make an "attachment" of sorts that documents the various functions, anywhere these is a call to the OS source, but omits anything that doesn't (complicated, and annoying).
Really, I think that having the engine open-source is great, and companies have done this. The actual game content (environment code, graphics, etc) can be held under private ownership - which means that you can sell it, but anyone could make their own game based on your engine?
At least I think this is how it would work. Please feel free to correct me, as I could use the advice anyhow.