Re: Dual licensing
Le lundi 07 Juin 2004 18:22, Marius Amado Alves a écrit : > > You find many examples, such as Trolltech or MySQL, proposing > > such dual-licensing schemes. Not bcause customers WANT closed > > source, but simply because they also want to make internal > > develpment or internal use which does not fit the GPL or other > > Open Source license. > > Rubbish. All internal development or use fits any open source > licence. Sorry, but a word was missing in my sentence. you should read: Not because customers WANT closed source, but simply because the same customers also want to make internal development or internal use which does not fit the GPL or other Open Source license. -- JCR aka DJ Anubis LAB Project Initiator & coordinator -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Dual licensing
Le lundi 07 Juin 2004 14:46, Marius Amado Alves a écrit : > The dual-licensing requires a market need for *closed* source. How > can this be in line with the open source ideals? > > (Please note I'm not at all against practising the dual-licensing > model, given the current state of affairs.) Why dual licensing should be connected to *closed* source? You find many examples, such as Trolltech or MySQL, proposing such dual-licensing schemes. Not bcause customers WANT closed source, but simply because they also want to make internal develpment or internal use which does not fit the GPL or other Open Source license. If you only propose GPL, you cut yourself from companies who would like to use your software, but must use your software or make it a subproject of non Open Source compatible software, or even, basically, cause they think their specific knowlege in a particular field cannot be shared. Without closed source AND dual licensing, really free software would never (or at least not before the next glaciation) make its own bed in most companies. The 3 models are acceptable, dual-liecnsing does not really break Open Source paradigms. -- JCR aka DJ Anubis LAB Project Initiator & coordinator -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: RFD: BSD/MIT-like licence with European clause
Le jeudi 13 Mai 2004 15:54, Thorsten Glaser a écrit : > >> In addition to that, in most European countries, there's not only > >> the Copyright law, but this droit d'auteur thing. > > > > I'd be interested to learn how does this changes copyright licensing in > > practise? > > Copyright law is bound to a work, while "Urheberrecht" (German term) is > bound to a person (ie, the author). > > I won't write more because I don't know everything and don't like to > publish half-truths, maybe someone else may help. In French Law, at least, copyright may be held by a company while the "droit d'auteur" is always held by the original author. This creates legal issues with most licenses, as only copyright is granted, but no provision is made for author's rights. Practically, an author can delegate copyright to others, such as a software company, but he retains the intellectual ownership. So grantees (copyright holders) can use the legal stuff about copyright infringments and all other matters, but they cannot alegate about intellectual property. At least in France, a copyright delegation MUST be given with a known delay (3 to 5 years), this must be constated by a written assesment. Grantee must resign a new delegataion afeter this time or the delegation is obsoleted. The laws about this are a huge manual known as "Code de la propriété industrielle et intellectuelle" (Industrial and Intellectual Property Acts) and is a nightmare. > > I don't fully see how "to the maximum extent permitted by law" wouldn't > > cover the situations you are worried about? > > You know, lawyer speak is difficult. I've thought about it, but > explicitly saying "Yes, I'm responsible and I didn't put in a > trojan horse by will" into the licence text at least has a > psychological effect. French lawyers insist about a certain formulation in contracts. Copyright things and intellectual rights are considered in France as contracts and must be written according to this f*g formulations. -- JCR aka DJ Anubis LAB Project Initiator & coordinator -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: LAB Public License proposal
Le jeudi 18 Mars 2004 11:20, Mahesh T. Pai a écrit : > Hmm. Same situation pervails in the Common Law tradition too. You will > be interested to know that in law school, we were taught that the > Civil Law tradition (and France was almost always the example) does > not rely much on what the Common law tradition calls `judicial > precedent'; `precedent' is legalese for earlier decisions by the > judiciary. Civil Law Tradition is what is called "jurisprudence" in France. France always put laws over laws, so the result can be a nightmare, even for rally trained lawyers. Courts can decide on one or other of all the texts, and sometimes they even decide using "jurisprudence" modified by a law extension. Sounds confusing enough. > > A confusing L.131-3 from French Intellectual Property act tells: > > "transmission of author's rights is subornidated to the condition > > that each and every transmited right be distinctly mentioned in the > > session act and thet exploitation domain of each transmited right > > be delimited for its destination, place and duration." > > Is this the official translation?? (Will the French ever have > `official' translations of their laws?? *g*) Not offical, as sounds there will never have official translations of the huge law books valid here :-( A full list is however available (in French) on the official government site: http://www.legifrance.gouv.fr/WAspad/ListeCodes > Does this translate mean `granted rights have to be specifically > enumerated; and the granted rights may be used only for the purpose, > time and place for which the grant is made'?? Yes, this text (and jurisprudence seems to enforce) that: 1. each and every grant must be enumerated and justified. 2. Granted rights may only be used for the written purpose and no other, be it implied. 3. Granted rights are only valid for the described place. This is why I used 'world wide' in draft. But we may have to change this when we finish digging in French jurisprudence about the 'world wide' legality on contractual basis. 3. Granted rights must be bounded in time. A new granting agreement must be signed every 3 or 5 years (jurisprudence always choose between those two values, I don't know why). > Do the French have a doctrine of estoppel?? Is it possible for the > French licensee to rely on the statements in the license as a promise > made by the owner of copyright?? Or is that all promises relating to French licensee could try to rely on statements in the license as a promise made by copyright owner. But, if all the legal stuff is not in the license text, the judge will invalidate the license first, as it is stated in first article of the base act (Civil Code): "No one is not supposed to be unaware of the law". > (a) enforcement of a right (b) permissions in a copyright work > > should invariably conform to the Intellectual Property Act you quoted > above?? They should conform, as jurisprudence showed too generic wording is rejected by courts. > > A court decision, while not dealing strictly with free or open > > source software, hits the real problem. A french court decided that > > I guess that this will still apply to F/L/OSS. Sure, it will apply. > Will the whole contract / license be invalidated?? Or will the court > just ignore only the provisions relating to choice of law?? This is a real issue, as courts assume contracts are always signed in conformance with the originating law. Say a french author/vendor having his house/business in France must conform to french laws when granting/selling. But when you are licensee, if the grantor is german, american, chinese, the grantor country law applies. A contract stipulating different laws is judged fully inapplicable. Court just not ignores provisions to choice of law, but thinks grantor tried to overcome law, and thus can be prosecuted. And for Internet, the situation will soon become even worse with the new LSI (A brand new law about security). Wherever you put your servers, being french citizen and resident makes you responsible for whatever is published or distributed via Internet. > Here (in India), choice of law provisions are read in a very > restricted way. If the facts of the case do not, in any way confer Sounds easier than in France. > Why do you need a choice of law clause in the first place?? (sorry if > you have already answered this - I have not followed this thread t > closely). Maybe this message will give you the answer. -- JCR aka DJ Anubis LAB Project Initiator & coordinator -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: LAB Public License proposal
Le jeudi 18 Mars 2004 03:31, Rod Dixon, J.D., LL.M. a écrit : > I do not see an OSD issue for here. Consequently, I recommend approval of > the CUA Office Public License. This license does raise interesting > questions about what appears to be a choice of law matter. I am not sure > why French law is presenting the problem the poster says it does, but > software distributed on the Internet seems capable of a simpler solution > than drafting licenses in the manner proposed by the current draft of the > CUA Office Public License. Sorry if my legal english is not very good. Questions about choice of a law matters, in many ways. Very important discussions raise here if France about the legality of most Free or Open Source licenses. Linux Magazine France, a French Linux monthly publication, raises some issues with Free and Open Source the licenses must cover to be valid. Internet distributed software raises another issue for those lawyers. French law is somewhat complex, as decisions come over decisions, and we have to comply with some judicial labyrinth whenever we have to write down some contractual documents. Licensing is one of the most complex of them. A confusing L.131-3 from French Intellectual Property act tells: "transmission of author's rights is subornidated to the condition that each and every transmited right be distinctly mentioned in the session act and thet exploitation domain of each transmited right be delimited for its destination, place and duration." According to this text, GNU GPL is silent about this question. As a result a court can invalid this license and licensee will have on programs actions not legal in such a case. A court decision, while not dealing strictly with free or open source software, hits the real problem. A french court decided that a right transmission from an author to an editor was illegal and invalid because session duration was longer than the one imposed by law. The contract was nullified as "author's will cannot overide law". The same could be applied if a French author, living in France, decided that applicable law would be Californian courts, which would be considered illegal by law. > After acknowledging the intentions of the > drafter of the CUA Office Public License, sections 4, 10, 11, and 12 seem > oddly worded. For example, it is difficult to unravel the meaning of this > phrase from section 12: "This LICENSE shall be governed by French law > provisions (except to the extent applicable law, if any, provides > otherwise), excluding its conflict-of-law provisions" > > Except when? CUA Office Public Licence and LAB Public License are equally oddly worded. For LAB license, French wording is even worse, as some lawyers only terms are to be introduced for the license be valid. conflict-of-law provisions is a very nasty judicial wording which Europe might face soon (mainly France, BTW) if EEC harmonization imposes changes in juridictions and texts. In such a case, objections shall be laid to EEC Central courts. > At any rate, sections 4, 10, 11, and 12 should > be reviewed to eliminate terms that do not meaningfully add to the > drafter's intent. This license should be easier to read than it is now. > Since I am not providing legal advice, I cannot be more specific. You > would benefit from having your legal counsel review the terms of this > license before finalizing the draft. Well, ease of reading is good, but lawyers do not think of such a user ease. They think in legal obligations and other odd matters, as they would have to support this in case of dispute. Trying to deal with contradictory laws is not an easy game and formalism is required by all courts. This introduces this level of complexity. We had to dig in most OSI approved licenses to find one which could be adapted. Most licenses come from USA entities, without this international legal intricacies. This is why we used CUA model as draft for our work. -- JCR aka DJ Anubis LAB Project Initiator & coordinator -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Fwd: Re: LAB Public License proposal
-- Message transmis -- Subject: Re: LAB Public License proposal Date: mercredi 17 Mars 2004 17:14 From: Ernest Prabhakar <[EMAIL PROTECTED]> To: DJ Anubis <[EMAIL PROTECTED]> Hi DJ, Thanks for your reply - I suggest you repost this to the list, as I think they'd be interested in hearing your responses (perhaps that's what you intended, but this reply came only to me). Alas, I don't have time to help more, but I appreciate your openness and hope you can find some other people to help you with the language cleanup. Best wishes, Ernest Prabhakar On Mar 16, 2004, at 11:59 PM, DJ Anubis wrote: > Le mercredi 17 Mars 2004 02:06, vous avez écrit : >> Hi DJ, > > Hi Ernest, > >> changes are: >>> 10. LICENSE means this document in its integrality, without reserve >>> or disclaimer other than herein published. > > This change is nexessary for compliance for French courts and CPI. I > don't > know if other courts need this full statement. > >>> 3.2. Availability of Source Code. >>> >>> and if made available via ELECTRONIC DISTRIBUTION MECHANISM, must >>> remain available for >>> at least twenty-four (24) months after the date it initially became >>> available, or >>> at least twelve (12) months after a subsequent version of that >>> particular MODIFICATIONS has been made available to such recipients. > > Changing from 12 to 24 and 6 to twelve is only a prudence statement, as > digging in French legal decisions showed this sounds, for judges here, > the > minimal duration for software maintenance. > >>> 3.3. Description of Modifications. >>> >>> In your SOURCE CODE, YOU must include comments marking the beginning >>> and end of your MODIFICATIONS, as well as your name. > > Maybe this sound unuseful, but it helps tracing who changed what when > changes > are not distributed as unified diff files. > >>> .4. Inability to Comply Due to Statute or Regulation. >>> 1. Inform ORIGINAL AUTHOR of statute, judicial or regulation >>> incompatibility and ask for an allowance to specific limitations. >>> Attention: >>> ORIGINAL AUTHOR can allow you to distribute a LICENSE limited >>> COVERED CODE, but you first must ask. > > Again, a French requirement. A license change in terms must be agreed > by > Licensor, even if changes are made to comply with local regulation. > Else, > License is judged as alienated and terminated. > >>> 2. >>> Comply with the terms of this LICENSE to the maximum extent possible >>> You cannot reject the whole LICENSE when only one statement is not >>> acceptable du to regulations, statute or judicial order. Only the >>> relevant statement may be discarded, after informing ORIGINAL >>> AUTHOR. > > The precision is once again to make French lawyers happy. > >> I don't see anything there that would be likely to affect OSD >> compliance. However, Section 4 seems slightly ambiguous - it might >> be >> clearer if you said, "You must comply with all of the following >> conditions, or you must refrain from using the software." or whatever >> the intent actually is. > > Yes, You're right. The sentence will be reformulated. You sound better > than me > with English legal terms. > >> I frankly don't quite understand Section 10, but perhaps that's due to >> the translating back and forth. > > This could be the real problem. French CPI is full of terms and old > french > words very difficult to translate back and forth. > >> To be honest, I am a little unhappy with all the "Attentions".Some >> of them I agree are useful to clarify the intent and purpose of the >> license.Some of them seem more like commentary than clarification, > > I'll dig in them and remove not really useful. > >>> 2. If YOU created one or more MODIFICATIONS, YOU must add your name >>> as a CONTRIBUTOR to the notice described in EXHIBIT A - Lab Public >>> License Required information.. >>> Attention: >>> Fair practice. YOU have to be credited for your work. >> >> Perhaps it is just the language, but this article seems to require you >> to accept -responsibility- for the work, not that other people give >> you >> credit. A minor detail, but since I didn't carefully review all the >> Attentions, I'm not entirely comfortable that all of them support the >> license as intended. > > You're right. This article requires contributors to accept > responsibility for >
Re: LAB Public License proposal
Le lundi 15 Mars 2004 21:35, Rod Dixon, J.D., LL.M. a écrit : > It might help if you highlighted the changes (using color text or bold > facing). Is your explanation as to why you have declined to adopt the CUA > Office Public License limited to the desire to "comply" with regulations in > three jurisdictions? Would you be more specific? > > Rod A highlighted version is on line at http://www.lab-project.net/tests_priv/liclab-annotated.html for review. One of the reson we had to change some things from CUA Office Public License have to do with French laws imposing some legal mentions on all contractual papers or forms. We had to introduce a section for French Government End Users. In final, CUA Office Public License is great, only missing non USA specific legal information. This license only fills the gap. -- JCR aka DJ Anubis LAB Project Initiator & coordinator -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
LAB Public License proposal
Hello, Intending to use the following license for LAB Project, I need your advice and discussion about. It is an adapted version of http://www.opensource.org/licenses/cuaoffice.php modified to comply with both USA, French and EEC regulations. Only some minor formulations and definitions changes and a specific Frenc regulations paragrah were added to comply with 3 regulations. Pre publication is at : http://labsupport.free.fr/liclab.html temporary address before publishing on official project.site. As the text is rather long, I prefer to submit it as link instead of full text inclusion. Thanks for your advice JCR aka DJ Anubis -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: "Open Source" Motif
Raul Miller wrote: > But, if you're trying to produce free (aka non-proprietary) software I > think the GPL winds up being the best license: Or more accurately, if you are trying to induce people to produce free software by licensing your software... > Then again, if your goal is to produce something proprietary, or > potentially proprietary, the GPL is obviously a bad license to use. Or to produce something that is "aproprietary" - it doesn't care wether it is owned or not. The BSD license has not stopped people doing proprietary development or free development on BSD'd works. What operates there is the economics of proprietary branching, where it's cheaper to work with the community than develop alone. The real question is do we want an open inclusive community or a parallel-to -proprietary exclusive community. I'd like to see Motif opened with eventually a BSD license. And CDE too... :) Dj
Re: Can Java code EVER be GPLd, at all?
> Right. Which is why the GPL may not be an appropriate way to copyleft > Java source code! The problem you face is simple. The viral nature of the GPL means that to run a GPL java program means always binding with non-GPL code such as the class libraries. All you can reasonably do is wirefence your code at the API level or package level (I prefer the latter... you can say com.mystuff.lgpl.package.* for example and developers are reminded of it when they import! > Right now nobody can make my code non-free, but my code is not contributing > to the creation of any new free software, and I would like it to. Forcing people to write free software is not, IMO, the way to go. You seem to think that releasing under a non GPL license does not create a circumstance where people will write free software using your code yet *will* write proprietary code with it. If your code is good, everyone will use it. If it places an unreasonable restriction on them (i.e. you may only use this code to write more code with the same license as the former code) then a large set of people will just leave it on the side. The sucessful non GPL open source style projects out there are proof that people are not as self centered and selfish as the GPL presumes. Dj
Re: support requirement
VAB wrote: > Yes. I see your reading in the text, however I wanted to make > it clear that I did not mean it as a threat. I accept that... > It was > the method by which all free *nix (Linux,*BSD,Minix) came > into existence. Well, lesser strength licenses; only one of those is GPL'd though. And that's possibly part of the progression of licenses, as each license advocate reimplements each time. Now we're in wasted effort territory. > Commercial > companies re-implement eachother's applications all the time. IE and > Netscape for example. Generic applications are an interesting case in that you can't really call IE or Netscape "reimplementations" of each other. They are implementations of a browser though. > Yes. I believe it is ethical. I think of computer programing in the > same manner as you probably think of mathematics. I don't see computer program *design* as similar to mathematics. For one, we'd have obvious intuitive rules which always worked to base development on. Coomputer program deign and implementation is a science and an art, engineering and craft all at once. > Should you have to pay a royalty every time you add 2 + 2? I wasn't asking about royalties. I was asking about the ethics. The example postulates you have been given something with some conditions. > Would you expect 12+ year > protection on something as simple as a x-or type operation or other > simple algorithm? Simple algorithms are not the issue. Complex algorithms and techniques, which pass obviousness tests and prior art tests are more likely to accrete patent protection in a more functional patent system which didn't rubber stamp stuff through and let the courts fight it out (which is the current problem for software). > > And there's no copyright on good ideas? So where's the benefit on being open > > with your good ideas? > Your ideas can be expanded, implemented and improved by the community. Hoorah for the BSD license which allows for credit where credit is due then. B) > You benefit because technology advances and because of your contribution > to the community. But if you've lost your ability to exploit your original ideas because the community has gone and reimplemented your ideas and disconnected you from the process, then as I said, where's the benefit in being open? > This positive feedback loop is why > proprietary software is being defeated. Oh sorry missed that. Yes, of course, there is no software industry is there. > It's a function of scale - with a closed > idea you have say 12 employees functioning as a positive feedback loop > for it - 12 good people. If you have 12 people working on something, your team is too big. B) > But if you release your idea, you have a much > larger number of people forming that positive feedback loop that it's > developed in. But now you are unable to exploit your idea. Or at least exploit the idea's implementation as you've given it away. > If you keep a good idea a secret it is of no value to anyone but > yourself. And the people who want to buy that good idea off yourself, or buy products based on that good idea. > Closed systems cannot compete with open systems in open (capitalist) > markets. Hang on... capitalism, which brought us patents to allow ideas to be spread whilst allowing the originator of the idea time and protection to exploit the idea. Except that you've removed that idea of protection so what you have is an accelerated market with no idea capital. > > Due to it's license contamination capabilities. > This is it's mechanism of preserving and guaranteeing freedom. And "expanding freedom"? > The > GPL's viral clause is one of the reasons the license is so well liked > by the Free Software Community. And so disliked by many people I know who prefer open source licenses which don't trigger off chain reactions. I'm sold on the peer review concept of open source, but I'm of the school that considers that you should also be free to fork to closed code. If the open model works, you won't want to but it's a freedom I'm not prepared to give up. > As I > suggested previously, it could be released under a more restrictive > license with out loss of benefits to the company seeking to opensource > it. If there was a demand for such an application in the opensource > community, the community would develop such an application. Or the community could enter into a reasonable discussion on how the license could be changed to ensure their contribution, possibly with a review. In fact, that is something sorely missing; some hard data on how well proprietary projects open up to the open source model and to see if there are any benefits/detrimentals. Actually, is anyone collating that kind of data? Is anyone reviewing how things are working for the vendors who have opened up? Dj
Re: support requirement
Seth David Schoen wrote: > This can be put a little less harshly. I did have my tags on B) > The canonical comment that I think of on this subject is Jamie Zawinski's > phrase "magic pixie dust". > > http://www.jwz.org/gruntle/nomo.html > > Just because something is released under an Open Source license does not > guarantee its the unconditional embrace by the community. Choosing a > standard free license is one thing that could help on that score. But then, if the license is open source or a standard open source license, we still have the possibility that it will *still* get reimplemented. Remember that we started here with the suggestion that the GPL was "magic pixie dust" in terms of community acceptance. Dj
Re: support requirement
[EMAIL PROTECTED] wrote: > It's true, though - not just a threat. If you don't go Open Source, someone > else will do it for you, and there are lots of examples. While I'd not explain > this to someone in terms of a threat, it is a _fact_ they must confront. So, I'm Vendor Q. I have a working product and I make money from it. "Hey, GPL your product" says a section of the community (not necessarily my customers). "Why?" ask I. "Well, if you don't do it then we'll do it for you" comes the response. "So why should I make it easier for you?"... "But we won't duplicate it by looking at your code, but by external reverse engineering". "So you don't need my code"? "Er, no, but it'd be nice if you went GPL". "Why?"... Substitute GPL with "Open Source" and you're still spinning in this problem zone, one which will keep Q from considering opening up. What's the purpose of "Open Source"? (The GPL purpose is transparently obvious) To bring software within "firing range" of the GPL/Clone route? (It's a lot easier to clone something if you have access to a full copy of what you are cloning)... Or to provide tangible benefits to software developers either alone or as a working group within an organisation? Dj
Re: support requirement
"Forrest J. Cavalier III" wrote: > > department. Thus, one of X's _main_goals_ in making the software Open > > Source is that commercial vendors pick it up and _provide_support_ for it. > > > > Thus, their license requires that if you distribute a derived work of their > > program _and_ you provide support on reasonably comparable programs, > > that you provide support for their program too. The provision has no effect > > on organizations like Debian that don't provide support. > > Fix your ISO procedures to say that open source > software doesn't need external vendor support. > > The whole point of open source is that you can write > items into your ISO manuals that say "we can self support > and audit this software, since we have the source > code." Except that the software customer may be ISO certified with no software development capability and no software development cycle. That I suggest is the problem. They can't say "we can self support this code"they have no developers within the ISO certified section of the company. Dj
Re: support requirement
VAB wrote: > A fact rarely mentioned on the list is that release under a > license other than the GPL brings with it the danger that > the software product will be reimplemented under the GPL. > This is likely if Vendor X releases under a license which > is unattractive due to say, required support terms. That reads more like carefully couched GPL blackmail. "Release under GPL or we'll copy your product make it GPL ourselves". That's real scary... especially after the previous discussion of selling the idea of open source code to corporate types. The threat of duplication here is emphasised for not opening up enough, and that's not going to encourage them to open up at all. What are the ethics of duplicating the functionality of an application? Oh, and there's an assumption that Vendor X's application will be sufficently compelling as to take up a position of standardness in it's niche yet there's no assurance of that. I suspect to sell the open sourcing idea within Vendor X, someone's going to need a bit more than a faith that the product will be picked up by the community. Dj
