Re: Clarification of GPL
Mahesh, > The nearest analogy from literature I can think of at the moment is X > being a grammar text book and Y my essay, which conforms to grammar > in that text book. Is my essay a derivative of the grammar book? Example is too far-fetched. What if Y were a separate book with extensive treatment of the exercises presented in X ?? Y could not exist without X - the prior publication. Yet copyright AFAIK treats it as an independent work. Certainly as long is it is being distributed as a separate volume. Abe Kornelis. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Must publish vs. must supply
- Original Message - From: Chris F Clark <[EMAIL PROTECTED]> > Me: > > Obviously, item 2 must be under some restrictions, or there isn't any > > "must" in your 3. > > Abe: > --> I do not agree. The main restriction is that you keep your > modifications private. The base line is: either keep them private > *or* distribute to the public. Nothing in between. > > I'm sorry I misunderstood you also, and I apologize if I hijacked your > ideas and took them in a direction you didn't intend for them to go. --> No problem - I kinda like these discussions. > Avoiding "selective" secrecy (keeping modifiers (creators of derived > works) from publishing only to their customers, but not to the world) > is a reasonable goal for one to attempt to achieve in a license. --> Ok, thanks! > I hope that the OSI board finds your license conformant. --> Thank you. > It is still a step in the correct direction in my book. --> Sorry, I don't quite understand this remark of yours. What is the intended meaning in (more) plain english? (I'm not a native speaker and am easily confounded by implied meanings, expressions and the like - but am always willing to learn) Kind regards, Abe. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Must publish vs. must supply
- Original Message - From: Chris F Clark <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, March 13, 2003 6:48 PM Subject: Re: Must publish vs. must supply > On Wednesday 12 March 2003 01:34 pm, Abe Kornelis wrote (editted > silight by me in []: > > >I'll stress my point one last time (you're bored stiff > > already, I don't doubt) I would offer the recipients of my software > > three choices: > >1) make no modifications. > >2) make mods and keep them private [under what conditions?] > >3) make mods and publish to the public, either by > > [3a.] publishing yourself > > or by > > [3b.] passing a copy of the modifications to me. > > Obviously, item 2 must be under some restrictions, or there isn't any > "must" in your 3. --> I do not agree. The main restriction is that you keep your modifications private. The base line is: either keep them private *or* distribute to the public. Nothing in between. I am not intending to force anyone to publish modifications that were made only for private (in-company) use. The motivation behind this? I would love it if some large company picks up my published source, enhances it, etc. etc. and releases its modifications to the public. I would find it terrible however, if they'd adhere to the letter of the license by supplying source code to their clients, without ever letting their modifications leak out (back) into the public. In the mainframe world this would be an entirely feasible scheme. > Moreover, I have no qualms that it prevents Chinese dissidents (or Al > Queda memebers or whomever) from making private derived works. --> Don't expect them to bother too much about restrictions in any license text. But at least they can't legally do that. > -Chris Clark > One personal aside: I have been greatly pleased that the participants > in this debate have chosen to try to consider the merits of each point > soberly and with a minimum of inflammatory rhetoric. I understand > that many of these points are volatile and could easily produce more > heat than light Thank you. --> My pleasure! Abe Kornelis. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Must publish vs. must supply
- Original Message - From: David Johnson <[EMAIL PROTECTED]> > > I would offer the recipients of my software > > three choices: > >1) make no modifications. > >2) make mods and keep them private > >3) make mods and publish to the public, either by publishing > >yourself or by passing a copy of the modifications to me. > > That's was not what I understood the term "must-publish" to be. > Certainly your definition is acceptable, non-onerous, and obviously > Free. Many OSS and FS licenses already have these provisions. --> Then I must have been unclear when I first formulated my question to this list. Sorry about that. And thank you for your support! Kind regards, Abe. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Must publish vs. must supply
- Original Message - From: Mark Rafn <[EMAIL PROTECTED]> > Any group should be able to share > modifications among themselves without the outside world (including the > original author) being aware of it. --> I do not regard open-source as a one-sided mirror - if it is to work at all, then it must have two equal faces. I give away my software for free - to the public. If you use it, ok! If you modify it you either keep your modifications private or you make your modifications public just like I did with the original. I'm even willing to make this easy for you by publishing the modifications for you in case you prefer not to do so yourself. I can very well understand the desire of some to circulate modifiactions within a limited circle - but that conflicts with the restrictions I intend to license my software. If you cannot live with that, fine, please do not modify the software, keep your modifications private, or choose some other software to serve your needs. I'm not going to try and 'convert' you to share my point of view. But I do want us to understand each other's point of view. I do not believe my proposal is in conflict with the OSD, nor do I believe that it violates the spirit of open source. If you do not agree on these points, I would gladly learn your arguments. > You're not compelled to write nor distribute open source software. But if > you want the benefits of doing so, you must do so fully. --> Well, that's exactly my point, except that I would also say that you're not compelled to use or modify open source software, but if you want the benefits of doing so, you must live by its rules. This I expect to be the cause of us two interpreting the above (at least seemingly) in opposing ways. Kind regards, Abe. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Must publish vs. must supply
- Original Message - From: John Cowan <[EMAIL PROTECTED]> > Chris F Clark scripsit: > > > Clearly the FSF has decided that hording of software by corporations > > (as long as they don't distribute it) should be one of their freedoms. > > The same applies to individuals. Do you want to be required to publish > every little dink you make to GPLed software? How often? With what > granularity? After every change? After every CVS commit? --> No thanks - what a horrible bother! > I continue to think the GPL's attitude sensible: if you distribute the > program, you must distribute the source. --> That's exactly my point. However, since my software lives in a mainframe world - which differs in many ways from the PC and unix-worlds - I want to ensure that such sources will be made available to the public - not just a few companies who will stash it and do nothing with it. That's the fast lane to 'software imprisonment'. > There is no question of imprisonment. No one should be forced to become > a distributor, IMHO; those who distribute can reasonably be expected to > be willing to incur certain obligations. --> Again: agreed entirely! And if they don't like the obligations, there is always the alternative: pay for a different license for that software. > John Cowan Kind Regards, Abe. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Must publish vs. must supply
- Original Message - From: Chris F Clark <[EMAIL PROTECTED]> > My only point in entering this debate was to point out that the > license restrictions suggested by Abe Kornalis do reflect that legal > precedent and also reflect the desires of other software authors. > Restricting the rights of others to make secret (and perhaps even > private) derived works is a right that copyright law has established > is within the authors domain. --> Speaking strictly for myself: secret derivatives of my software are ok with me - it's only when distribution comes to play a role that I would demand that distribution may be done to a selct group but never without publishing to the public. > Unless one can find specific reason why > it violates the open source (or free software) definition, I think > such a license should be considered open source (and/or free > software). Now, perhaps the privacy concern is sufficient to make the > license not free software. However, I don't think it violates the > open source definition--just my opinion again. --> What I currently have was taken from various licenses that already have been approved by the OSI board. If such clauses are deemed to violate the OSD, then it must be a matter of wording, not of principles. > -Chris Clark > > Again, a personal request: Please do not send me personal copies --> Check Kind regards, Abe Kornelis -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Must publish vs. must supply
- Original Message - From: David Johnson <[EMAIL PROTECTED]> > > My only point in entering this debate was to point out that the > > license restrictions suggested by Abe Kornalis do reflect that legal > > precedent and also reflect the desires of other software authors. > > Restricting the rights of others to make secret (and perhaps even > > private) derived works is a right that copyright law has established > > is within the authors domain. > > True, but legal precedence is not a guarantee of OSD compliance. --> Agreed. > Of course, I am not arguing that must-publish clauses are against the > OSD (even though it may sound like I am). My personal opinion is that I > don't like them, and would not touch source code covered under one with > a ten foot pole. --> You may find this strange, but neither would I. That is, unless I would be allowed to keep my modifications private. If ever I decide to distribute, I'd be happy to do so to the public. (And given an opportunity to let someone else do the job for me - I wouldn't hesitate to send my modifications to the original author.) I'll stress my point one last time (you're bored stiff already, I don't doubt) I would offer the recipients of my software three choices: 1) make no modifications. 2) make mods and keep them private 3) make mods and publish to the public, either by publishing yourself or by passing a copy of the modifications to me. Am I imposing undue restrictions or obligations this way? As far as I can see, only if you intend to distribute derivatives of my software to a select group with explicit intention of shielding it from the public. Otherwise - is it such a bother to send a copy of your distro to my e-mail account? > There is no specific section of the OSD that a generic must-publish > clause conflicts with. However, it may very well conflict with the > unwritten rule that "there shall be no onerous restrictions." --> just addressed that one. Of course opinions may differ. > David Johnson Kind regards, Abe Kornelis. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Must publish vs. must supply
- Original Message - From: Mark Rafn <[EMAIL PROTECTED]> > > The biggest point in this whole discussion is this simple > > fact: if I do not insert either a must-publish or a must-supply > > clause in my license they can (and probably will) claim that > > their source is available since they'd have to give it to their > > customers - who'd refuse to do anything but store them > > passively. > > IMO, such an ability is absolutely required by open-source software. The > chinese dissident case (Imagine a group of people who want to modify and > share software among themselves, but who will be executed if it is > discovered that they are working on this) is one common way to phrase this > requirement. --> You raise a touchy point. I'll give you two replies. 1) Any solution that I would provide would equally apply to terrorist groups. Replace the Chinese dissidents with Al-Qaeda members - their situations are comparable but the way we think about their motives and goals are utterly opposite! 2) I find it hard to believe that I should feel compelled to help these dissidents to solve their problems, however sympathetic their cause may seem. And if I would I'd still have to solve the conundrum above - without discriminating (see OSD). > This is the choice of such customers. They have source, so they have > control of thier systems. With luck, they're likely to ask you for help > (being the original author) if they decide something is wrong. --> They have their software vendors for support. They pay big bucks for support - no way are they going to ask for help from outsiders. > > As Chris said: a license needs teeth, and this one I deem > > to be one very important canine. > > It needs teeth to protect the software recipients from the software > authors. Teeth that protect an author from the recipients are the > opposite of free. --> It works both ways: users need protection from authors, *and* authors need protection from users who would prefer to both have my cookie (software) and eat it (resell without publishing). > > Is a must-supply (to copyright holder, that is) clause > > preferable over a must-publish (to the public, that is) > > clause, or vice versa. > > Neither qualify as acceptible in my book. --> Not even when there is also an option not to distribute at all? I am not intending that *any* change be published - I only want to enforce that *if* changes are distributed, *then* they must be made available to the public. > I'd be interested to hear > from OSI board members whether this is an area where "free" as commonly > used by the FSF and Debian differs from "open source" as used by OSI. --> It would be very nice to know their opinion. Kind regards, Abe F. Kornelis. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Must publish vs. must supply
Mark, Chris and I appear to share a point of view. Thanks Chris, for your reaction. I feel strengthened by it. Which license do you currently use for open-source distribution? - Original Message - From: Mark Rafn <[EMAIL PROTECTED]> > On Sun, 9 Mar 2003, Chris F Clark wrote: > > > I would like an open source license that > > prevents or atleast substantially "discourages" commercial users who > > wish to use it for closed source applications, but allows them to use > > it when developing open source applications. > > I understand the desire to license software in such a way that it doesn't > compete with your business, but I'm not sure it's compatible with what I > think of as "open source". --> As far as I can see, it appears to be quite common practice to dual-license open software. Free for those who are willing to share their sources, and paid for those who want to use it, but unwilling (loath i.e.) to disclose the source code of their own software to the public. > It sounds like you may prefer a noncommercial sharing license, or a > noncompete license. --> I can speak only for my self: I would strongly prefer an OSI-approved license. > I personally believe that an actual free license gives additional benefits > to the software author (like the satisfaction of knowing the software is > useful and that good pieces can live on in other programs. Also community > acceptance that can (or not, sometimes) lead to better bug reports, > patches, and suggestions for the product. --> It's always fine to know people use my software to their advantage - but I have to make a living, too. To put it bluntly: I cannot afford to give my software away without any restriction, however noble that might seem to some. > But it's not for everyone, and certainly not for all software. If you > intend to sell the software itself (rather than selling support, add-ons, > or other services related to it), you probably want to limit your > competitors from doing the same. --> Nope, not afraid of competition. Just don't want to see my software used in apps that remain effectively shielded from the public while nominally adhering to open-source license requirements. They can use my software for their proprietary software but *not* under an open-source license. The biggest point in this whole discussion is this simple fact: if I do not insert either a must-publish or a must-supply clause in my license they can (and probably will) claim that their source is available since they'd have to give it to their customers - who'd refuse to do anything but store them passively. They're scared shitless to touch such sources at all. They're afraid of reducing the system's robustness (remember, I'm talking about mainframes supporting thousands or more transactions per second, the stakes are high), afraid of losing vendor support, afraid of reducing the software's maintainability. I've seen some strange work-arounds in my career - just to avoid touching something that was made available! Without a must-supply or must-publish clause the sources that were supplied to the customers will rust into eternity without hope of ever being unlocked by those who might be willing to learn, improve, or whatever... As Chris said: a license needs teeth, and this one I deem to be one very important canine. So I return to my original question - which was intended to fathom the thought of the readers of this list: Is a must-supply (to copyright holder, that is) clause preferable over a must-publish (to the public, that is) clause, or vice versa. Or would it be best to leave the choice between the two ways of publishing to the contributor him/her self? So far, I *think* the latter option is looked upon relatively favorably - assuming the silent majority agrees with the discussion so far. Please feel invited to share your comments. Kind regards, Abe Kornelis. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Must publish vs. must supply
> Abe Kornelis scripsit: > > > Not wanting to compromise > > the relation with their software supplier being one fairly > > good reason, habitual secretiveness another one, > > and avoiding to be seen as untrustworthy or undependable > > by their own customers as yet another (very good) > > reason for that. Thus, a selected group effectively > > does not really differ from a closed group. > > In a purely commercial environment, perhaps not. People do, in fact, pass > software to their friends in utter disregard for any licensing features, > however. --> I know. That's not my point - though I seem to have been unclear about this. I *do* want to share my software with all those who might enjoy it, even though there are not that many people who toy around with a mainframe for their own fun. The software is the left-overs of a failed project. I'd really love to see it used by others - but when large software companies join in I'd like to recover some of my money. So they can have the software for free only if they either yield their software to the public (not just to their customers who'd keep it locked up just as well) or they acquire a different (paid) license for using my software. Isn't that the basis of all dual-licensing strategies? So, if John passes a copy to Bob - that's fine with me. And if derived software is being passed along too, I wouldn't think of bothering about legal issues - even when it would formally be a breach of the license terms. But as soon as professional software vendors get into the picture things become quite different, since they tend *not* to share their software with us. If they want my software for free, they'll have to abide by the same rules, i.e. share their software with the rest of us. This can be achieved only if they are required to publish to the public - because the intended recipients of their software will be extremely unlikely to pass the software on, thus effectively shielding the software from the public - which is precisely counter to my intentions. > > --> That would all be quite ok, except that I would like to see > >any changes that are distributed at all being made available > >to the public. How this is to be done, is a choice you can > >make yourself - either hand it to me or publish it on the web. > > I would like to see it too. The question you must ask yourself is > whether you feel strongly enough about it to be willing to use legal > force to compel that result. --> If needs be: yes! Kind regards, Abe. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Must publish vs. must supply
John, thanks again, and once more please find my comments inserted below. - Original Message - From: John Cowan <[EMAIL PROTECTED]> > Abe Kornelis scripsit: > > > > The GPL and the OSL take what I consider to be a reasonable attitude: > > > you must supply changes in source form to people who have received > > > the changed version. If the changed version is published to all, the > > > changes must also be; if the changed version is distributed to a few, > > > ditto the changes; if the changed version is never distributed, the > > > changed version need not be either. > > --> I understand that - it is one of my problems with these licenses: > > I'd really hate it if modifications were to be distributed within > > a closed group - not to the public that is. > > We must distinguish between "to a few" and "to a closed group". Since the > software is open-source, everyone has the right to distribute it further > with or without changes. Speaking of a "closed group" would imply that > the people that I distribute to would have no right to distribute outside > the group, which is abhorrent to the nature of Open Source. --> My apologies for incorrect choice of wording - english is not a native language for me. When I said 'closed group' I intended a selected audience. And even if the receiving audience is allowed to redistribute, they very likely will refrain from doing so. Not wanting to compromise the relation with their software supplier being one fairly good reason, habitual secretiveness another one, and avoiding to be seen as untrustworthy or undependable by their own customers as yet another (very good) reason for that. Thus, a selected group effectively does not really differ from a closed group. > What I was talking about, rather, was the opportunity to make a few > changes and pass along changes and changed version to my friends, > without being asked to make them available on a Web site too. Of course > my friends can send to other friends, and so on. Or they can post the > changed version (and the changes) on their own Web site, and so on. --> That would all be quite ok, except that I would like to see any changes that are distributed at all being made available to the public. How this is to be done, is a choice you can make yourself - either hand it to me or publish it on the web. > Therefore, there is no discrimination; I am simply limited in my obligations > such that I only have to distribute the changes with the changed version, and > all is done. --> Well, even when discrimination is not formally present, it still happens effectively. E.g. when part-time workers receive fewer bonuses it will hurt women more than men, since most men work full-time while lots of women work part-time. (Sorry for the generalization - just trying to make it less abstract) > > > This is quite separate from the question of whether the change is > > > *licensed* to all. No matter what the distribution conditions, anyone > > > who has possession of the change is licensed to use it. > > --> I agree with the latter, but don't understand the first remark. > > As far as I can see, all OSI-compliant distros are licensed > > to the receiver, which makes 'distributing to' functionally > > equivalent to 'licensing to' - except where receiver does not > > comply with the license's restrictions, but that's not (yet) > > relevant when the software is distributed. > > Yes, you are correct. I simply wanted to point out that the fact that my > changes to a GPLed program are licensed for use by all does not mean that > I myself have an affirmative duty to make them available to all. --> In general terms: yes I agree. When it comes to the BXAPL proposal: no, you would have an obligation to either publish to the public or not at all. > > Anyway, I was rather thinking of making things optional: > > 1) keep changes private - no distribution at all > > 2) distribute to the public > > 3) distribute & supply to copyright owner > > Option 1 is obvious, the main difference between choices > > 2 and 3 would be the requirement to make the modifications > > public *yourself* or allow the copyright holder to do so > > in your stead. If you already have a site option 2 might be > > more attractive, if you don't have a site, or you have one > > that is not related to the changes or the software, then > > option 3 might be more attractive since it'd be less of a > > hassle. Is it a bad idea to allow the contributor a choice as > > to how the changes are to be made public? > > I think this is a good feature. --> Thank you. Kind regards, Abe. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Must publish vs. must supply
Bennett, thanks for your reply. Please find my comments inserted in between your tecxt. - Original Message - From: Bennett Todd <[EMAIL PROTECTED]> 2003-03-05T14:34:23 John Cowan: > The GPL and the OSL take what I consider to be a reasonable attitude: > you must supply changes in source form to people who have received > the changed version. If the changed version is published to all, the > changes must also be; if the changed version is distributed to a few, > ditto the changes; if the changed version is never distributed, the > changed version need not be either. NB that there are some interesting points in this neighborhood. At least one software provider explicitly defines "distribute" to include distributing to different offices within a company; they then feel privileged to demand that a company that uses their Open Source product for an in-house project pay them for a commercial-redistribution license, rather than using the open source version, unless they're willing to completely open-source their in-house app. I raised the topic on this list, and got wide-spread agreement from people here that this is compliant with the Open Source Definition, which I must confess disappointed me. --> Understanably so. To me too, this would seem unreasonable. In the current draft for the BXAPL license see http://www.bixoft.nl/english/license.htm a company is viewed as a single entity - therefore internal re-distributions would qualify as 'keeping the code private' not requiring distribution to the public. -Bennett -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Must publish vs. must supply
John, thanks for your reply. Please find my comments inserted in between your text. - Original Message - From: John Cowan <[EMAIL PROTECTED]> > > The BXAPL (see http://www.bixoft.nl/english/license.htm) > > currently has both - which is definitely an overkill, > > even though it grants users the right to keep their > > modifications entirely private. That is: one either keeps > > all modifications private, or they are published to > > public in general. Selective distribution is not > > allowed. Users who fail to comply are obligated to > > supply their modifications upon request. > > As to "must publish", I think it's unnecessary. Those who wish to keep > their mods private will do so whether the license allows it or not: > if they sit on the changed version of the software, no one will know > that it even exists. --> And that would be entirely ok with me. > The GPL and the OSL take what I consider to be a reasonable attitude: > you must supply changes in source form to people who have received > the changed version. If the changed version is published to all, the > changes must also be; if the changed version is distributed to a few, > ditto the changes; if the changed version is never distributed, the > changed version need not be either. --> I understand that - it is one of my problems with these licenses: I'd really hate it if modifications were to be distributed within a closed group - not to the public that is. Distributing within closed groups may lead to discrimination. I concur with the OSI that discrimination is undesirable. Is it a good idea to force distribution to the public? Or am I being over-zealous? > Of course, the distributees may > themselves distribute, but at least there is no unlimited liability to > distribute one's changes to anyone who asks for them. > > This is quite separate from the question of whether the change is > *licensed* to all. No matter what the distribution conditions, anyone > who has possession of the change is licensed to use it. --> I agree with the latter, but don't understand the first remark. As far as I can see, all OSI-compliant distros are licensed to the receiver, which makes 'distributing to' functionally equivalent to 'licensing to' - except where receiver does not comply with the license's restrictions, but that's not (yet) relevant when the software is distributed. So how am I to understand your first remark? > The trouble with the usual kind of "must supply" (which I take to mean > "must supply changes to the original author") --> Right indeed. > is the burden of doing so > for those who make small changes to a large number of works -- people > like Linux distro makers and *BSD groups. If they have to push the > changes to the original author, the original author may be difficult > or impossible to find, or (if corporate) may have gone out of business. > It is much better, if you are going to require such a thing, to let the > distro creator push to you a distribution point (such as a Web site) > from which you may pull the changes yourself. --> There you have a point. Both the copyright holder and the contributor may go out of existence - eventually we all do, don't we ;-) Anyway, I was rather thinking of making things optional: 1) keep changes private - no distribution at all 2) distribute to the public 3) distribute & supply to copyright owner Option 1 is obvious, the main difference between choices 2 and 3 would be the requirement to make the modifications public *yourself* or allow the copyright holder to do so in your stead. If you already have a site option 2 might be more attractive, if you don't have a site, or you have one that is not related to the changes or the software, then option 3 might be more attractive since it'd be less of a hassle. Is it a bad idea to allow the contributor a choice as to how the changes are to be made public? > In general, though, I think all these requirements are over-cautious. > Most people do not want to maintain forks indefinitely -- they *want* to > push changes back to you in the hope that you will integrate the changes > into the mainline distribution, and they will get them back automatically. --> Sorry, John. I disagree. I know a few companies who would be willing to pick up my code, fork it and distribute it both to their customers and to their advantage - and never give anything back. As far as I'm concerned, they can make it proprietary if they want to - but *not* under an open-source license! Kind regards, Abe. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Must publish vs. must supply
Hello all, Some licenses have a 'must publish' requirements, others have a 'must supply' requirement, and yet others have neither. The BXAPL (see http://www.bixoft.nl/english/license.htm) currently has both - which is definitely an overkill, even though it grants users the right to keep their modifications entirely private. That is: one either keeps all modifications private, or they are published to public in general. Selective distribution is not allowed. Users who fail to comply are obligated to supply their modifications upon request. >From various discussions in the past I have surmised that either requirement as mentioned above is not being looked upon very favorably. Which one would be the best to keep in? Is there another way to ensure that modifications are either not published at all or to the public in general - not to a selected audience. Thanks in advance for your comments and thoughts. Kind regards, Abe Kornelis. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
BXAPL - proposed license
Hello all, Some time ago I requested comments on the BXAPL - which is an open-source license currently under development. It is a license which tries to cover two kinds of software, 'normal' software and also - as a separate category - programming tools. The license imposes slightly less stringent restrictions on users of programming tools. Because various sections in the license apply differently for the two kinds of software, the language of the license has become rather unwieldy in places, making the license difficult to read and understand. This was never my intention, so I'm trying to explore alternatives. I have thought of splitting the license into two licenses: one for 'normal' software and one for 'programming tools'. The disadvantage would be that this creates an awful lot of redundancy. Packages containing both types of software would need to include both license texts, etc. Another approach might be to split only those licenses which apply differently for each kind of software. Less redundancy, more clarity - I'd guess. Does anyone have other arguments or ideas? All comments are most welcome. For those who are interested, you can find the last version of the license proposal on our site: http://www.bixoft.nl/english/license.htm Thanks for your attention, Abe Kornelis. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: BXAPL - request for comments
Larry, > Perhaps you're still confusing terms. Those sections of the QPL don't > require that "copyrights of modifications be passed to the copyright > holder." They are simply grant-back licenses, albeit a little awkwardly > phrased. --> I still maintain that BXAPL section 12.5 is a nearly exact copy (semantically, that is, not literally) of QPL sections 3b and 6c toghether. If my understanding of English fails me at this point, what is the difference, please? > > --> Anything that is the author's prerogative under copyright law > > can be licensed to third parties under certain restrictions. > > I don't see where contract law comes in. > > Because many licenses deal with much more than "the author's prerogative > under copyright law." There are many provisions in these licenses that > have no analogue in copyright law at all, including warranty, etc., > etc., etc. --> John Cowan's mail cleared some points you're trying to make here. From his mail I conclude that you are right in pointing out that various provisions in the BXAPL will be unenforcible without invoking contract law - in addition to copyright law. I'll reconsider what this means for the BXAPL. > Damn, that was my most fervent wish. I haven't been getting enough > flames on license-discuss. > > > Why don't you come and see for yourself? Anyway, the > > English seem to like those wigs, so what? Furthermore, > > the French legal system and practices are presumably *quite* > > different from ours - and both will differ from yours and then > > again from the English. Still, intellectual property > > laws are sait > > to be quite comparable due to the international treaties on the > > subject. > > So they say. I just practice here in California and the U.S. --> Does 'practicing' imply that you are still in your apprenticeship ;-) (Sorry, couln't resist the bait) Kind Regards, Abe Kornelis. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: BXAPL - request for comments
Larry, See below for comments. Please find my responses inserted in the existing text. Abe. > > > > B) Copyrights of Modifications to be passed to Copyright Holder. > > > > Found no mention of such a requirement in the OSL. > > > > > > The requirement that downstream licensees who modify the software > > > assign their copyrights to the licensor is entirely > > unacceptable. Why > > > do you need that? The OSL is fully enforceable by the > > licensor even > > > if he doesn't own the copyrights. (This is not true for the GPL or > > > LGPL!) > > --> It was based on QPL, section 2. If it is utterly unacceptable > > then how did the QPL ever get approved? If it hadn't > > been approved > > I never would have used it as a source of inspriation. > > I'm confused. The QPL doesn't require that "copyrights of modifications > be passed to copyright holder." Section 2 in the QPL? I still don't > see it. Your confusion is understandable. Entirely my mistake - apologies offered. Please check QPL, granted rights, section 3b and 6c. > Sorry, I regretted my use of the term "hogwash" as soon as I sent the > email. I just strongly believe that no US judge will enforce anything > other than copyright law terms in a copyright license; if the license is > subject to contract law, however, then contract law terms can be > enforced. --> Anything that is the author's prerogative under copyright law can be licensed to third parties under certain restrictions. I don't see where contract law comes in. > What a court will do in Holland or France is a mystery to me. > Do the judges there still wear wigs and speak in haughty accents? --> You're asking for a flame, but that won't get us nowhere. Why don't you come and see for yourself? Anyway, the English seem to like those wigs, so what? Furthermore, the French legal system and practices are presumably *quite* different from ours - and both will differ from yours and then again from the English. Still, intellectual property laws are sait to be quite comparable due to the international treaties on the subject. Kind regards, Abe Kornelis. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: BXAPL - request for comments
Larry, thanks for your reply. Please find my responses inserted. Abe. > > A) Programming tools and dependent software versus other software > > and derivatives. I have found no mention of this > > distinction in your > > OSL. > > The OSL doesn't need to distinguish among these because it relies on the > statutory definition of derivative works. In my view, the OSL has the > same effect as both the GPL and the LGPL. One license instead of two! --> For some people (most?) people that may be fine. I for one, however, do need to distinguish between the two. > > B) Copyrights of Modifications to be passed to Copyright Holder. > > Found no mention of such a requirement in the OSL. > > The requirement that downstream licensees who modify the software assign > their copyrights to the licensor is entirely unacceptable. Why do you > need that? The OSL is fully enforceable by the licensor even if he > doesn't own the copyrights. (This is not true for the GPL or LGPL!) --> It was based on QPL, section 2. If it is utterly unacceptable then how did the QPL ever get approved? If it hadn't been approved I never would have used it as a source of inspriation. > > E) Recognizability of modifications. Not mentioned in OSL. > Take a look at section 6 in www.rosenlaw.com/osl1.1.html. --> My apologies. English is not my native language. Looked up attribution in the dictionary - is different from attrtition. My fault. I see your point. > > F) Dual licensing. Section 4, right? > Any licensor can license his software under any license (or licenses) he > wants. Of course, if he is licensing a derivative work of someone > else's software, he must honor the requirements of THAT license. If he > is licensing a derivative work of OSL-licensed software, he can only use > the OSL. The same is true for the GPL. --> And the BXAPL. > Entirely up to you. But if you insist on your point B, above, I'll > recommend disapproval of your license. I should also note that, > although this is not legal advice nor intended to create an > attorney-client relationship with you, I believe several sections of > your license are probably unenforceable and of dubious legal effect. In > particular, your claim that your license is not a contract is legal > hogwash. --> This list has recently seen a heated debate over the very issue. I know your point of view. Nevertheless, since so much debate was spent on it, I thought it prudent to make it explicit. Whether or not it is enforcible or hogwash or whatever will - in the ultimate case - be decided by a judge of appropriate jurisdiction. Which will be Dutch in my case, French for Steve Lhomme's case. You may be right when it comes down to American jurisdictions - you're undoubtedly way better informed than either of us on that matter. But when it comes to the Dutch or French case? And even if it is hogwash in some jurisdictions, it is nobody's way and may help to make things clear. Larry, thanks again for your response and your time. Kind regards, Abe. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: BXAPL - request for comments
Larry, thanks for the hint. I've read your license - it is appealing for being short concise, and pretty clear - at least for a lawyer ;-) However, it does not distinguish between software and programming tools, nor does it distinguish between derived software and what we have termed 'dependent software', which is termed in the LGPL as 'software that uses the Software'. In the rationale for the BXAPL we have named 8 requirements that our license would need to fulfill. Since you tried offered your OSL1.1 as an alternative, I'll go over them 1 by 1. A) Programming tools and dependent software versus other software and derivatives. I have found no mention of this distinction in your OSL. B) Copyrights of Modifications to be passed to Copyright Holder. Found no mention of such a requirement in the OSL. C) Copyrights and Patent rights. Ok. D) Disallow object-only distros. I assume section 3 of the OSL settles that. E) Recognizability of modifications. Not mentioned in OSL. F) Dual licensing. Section 4, right? G) Applicable law. Ok, section 11. H) Local langauages. Found no mention of such things. A quick count that the OSL covers 50% of our requirements. So, thanks again, but I will stick with my own license. Kind Regards, Abe. == - Original Message - From: Lawrence E. Rosen <[EMAIL PROTECTED]> To: 'Abe Kornelis' <[EMAIL PROTECTED]> Sent: Thursday, October 24, 2002 8:48 PM Subject: RE: BXAPL - request for comments > Did you consider using the Open Software License? The latest version of > the OSL is now at www.rosenlaw.com.osl1.1.html. I think it will do what > you want. It is an alternative to both the GPL and the LGPL. > > /Larry Rosen > > > -Original Message- > > From: Abe Kornelis [mailto:abe@;bixoft.nl] > > Sent: Thursday, October 24, 2002 12:33 PM > > To: OSI-list > > Subject: BXAPL - request for comments > > > > > > Hello all, > > > > a few months ago, Steve Lhomme and I have requested > > approval for the BXAPL license. That request was a > > bit too rash. > > > > We received various comments and have taken our time > > to create a new and improved version of the BXAPL. > > For an overview of the differences with the preceding > > version, please see below. > > > > We invite all readers on this list to take a look at the > > new version of our license and gladly welcome any > > comments, questions and other remarks you may > > want to e-mail us. The license text can be found at: > > http://www.bixoft.nl/english/license.htm > > > > One of the primary objectives for creating this license > > is to make it possible to distribute both programming > > tools and other software in a single package under a > > single license. > > > > Unfortunately, this requirement has led to a rather lengthy > > and complicated license. We apologize for this circumstance > > but at the same time feel we have done our best to make > > the license text understandable by supplying an explanation > > and an abridged version by way of quick reference. > > > > Thank you all in advance for your time and effort. > > > > Kind Regards, Abe Kornelis. == > > Differences between versions 0.H and 0.J > > > > - Added explanation on Programming Tools and Derivatives > > - Made requirement a in the list of requirements more explicit. > > - Contributor redefined so as to include only the Copyright Holder > > and all other parties supplying Modifications etc. > > Checked all occurrences of Contributor and Distributor and > > changed accordingly wherever necessary. > > This change corrects an omission in section 16, where a claim > > against Copyright Holder was not mentioned as a reason for > > suspending or withdrawing the licensed rights. > > - Definition of Source Code redefined to exclude assembler, > > compiler, linker, etc. > > - User redefined as anyone who 'possesses' a copy of the Software. > > The mere act of receiving the Software therefore no longer > > forces the receiver into a status as User. Also it enables > > any User to quit being a User, simply by deleting all copies > > of the Software. > > I've been thinking to use 'has', 'keeps' or 'owns', but > > as far as I can see, 'possesses' serves best. > > - the word paragraph has been changed to section wherever it > > referred to a numbered section of the license. This was done > > to make it easier to differentiate between sections and > > par
BXAPL - request for comments
Hello all, a few months ago, Steve Lhomme and I have requested approval for the BXAPL license. That request was a bit too rash. We received various comments and have taken our time to create a new and improved version of the BXAPL. For an overview of the differences with the preceding version, please see below. We invite all readers on this list to take a look at the new version of our license and gladly welcome any comments, questions and other remarks you may want to e-mail us. The license text can be found at: http://www.bixoft.nl/english/license.htm One of the primary objectives for creating this license is to make it possible to distribute both programming tools and other software in a single package under a single license. Unfortunately, this requirement has led to a rather lengthy and complicated license. We apologize for this circumstance but at the same time feel we have done our best to make the license text understandable by supplying an explanation and an abridged version by way of quick reference. Thank you all in advance for your time and effort. Kind Regards, Abe Kornelis. == Differences between versions 0.H and 0.J - Added explanation on Programming Tools and Derivatives - Made requirement a in the list of requirements more explicit. - Contributor redefined so as to include only the Copyright Holder and all other parties supplying Modifications etc. Checked all occurrences of Contributor and Distributor and changed accordingly wherever necessary. This change corrects an omission in section 16, where a claim against Copyright Holder was not mentioned as a reason for suspending or withdrawing the licensed rights. - Definition of Source Code redefined to exclude assembler, compiler, linker, etc. - User redefined as anyone who 'possesses' a copy of the Software. The mere act of receiving the Software therefore no longer forces the receiver into a status as User. Also it enables any User to quit being a User, simply by deleting all copies of the Software. I've been thinking to use 'has', 'keeps' or 'owns', but as far as I can see, 'possesses' serves best. - the word paragraph has been changed to section wherever it referred to a numbered section of the license. This was done to make it easier to differentiate between sections and paragraphs within sections. - Defined Licensor in paragraph 2. - Defined Co-licensor in paragraph 2. Note the difference between a Licensor and a Co-licensor. Suggestions for improving on the terminology are very welcome. Added Co-licensors to sections 17 and 18. - Added definition of Licensor to paragraph 2. - Added definition of 'Contribution'. - Added allowance for waiver of entitlement to Source Code of Modifications and/or Derivatives (see section 12.5) because not all Licensors are likely to require such entitlement. - Made it clear that the License is not a contract. - The section numbers in the preamble now link to the appropriate secton in the license. - Corrected various small typos. Changes to the parts of the license document preceding and following the license text are not listed individually, they follow from the above. Changes to the license text: - section 0 - added mixed case sentence - section 1 - copyright extended into 2002 - section 2, Co-licensor - added - section 2, Contribution - added - section 2, Contributor - changed as explained above added provision for transfer of ownership - section 2, Copyright Holder - appropriatte -> appropriate - section 2, Copyright Notice - a copyright notice -> copyrights notice - section 2, Distributor - the public in general -> any third party or parties Modifications etc. -> Contribution(s) - section 2, Licensor - added - section 2, Modifications - added 'changes to Derivatives and/or other Modifications.' - section 2, Programming Tool - 'Any Software' -> 'Any licensed Software' - section 2, Software - Modifications etc. -> Contribution(s) - section 2, Source Code - changed as explained above - section 2, User - changed as explained above - section 3 - software which uses -> software that uses - section 4 - added (twice) 'Appending translated versions, however, is allowed.' added 'Appending translated versions is allowed.' - section 5 - Authorizaton -> Authorization Second paragraph abridged. - section 6 - Copyright Holder's claim duplicated for all other Contributors Contributor -> Contributor and/or Distributor Modifications etc. -> Contribution(s) and some minor rephrasing - section 7 - added 'Since this License is not a contract' second paragraph - which provides -> that provides - sectio
Re: Approval request for BXAPL
From: Steve Lhomme <[EMAIL PROTECTED]> > Forrest J. Cavalier III wrote: > > Abe Kornelius wrote, in part: > > > >>It was intended that "Distributor" designate anyone who redistributes > >>the Software, with or without stuff of his/her own. This would include > >>the Copyright Holder. > >>A "Contributor" was intended to designate anyone who either > >>redistributes the Software, with or without stuff of his/her own, > >>or who supplies home-grown stuff to the Copyright Holder. > >> > >>Thus, as I intended it, a Distributor is *by definition* always > >>a Contributor also, but a Contributor would not be a Distributor > >>if that Contributor does not distribute the Software and/or > >>the homegrown stuff associated with it. > > Seems to go in circle here : > - A "Contributor" was intended to designate anyone who either > redistributes the Software... > - that "Distributor" designate anyone who redistributes the Software... --> Not in a circle. As defined at the moment a Distributor is anyone distributing the Software, and a Contributor is anyone contributing to the Software, either by supplying additional 'stuff' of by distributing it. > And I would rather say a Contributor is a Distributor, but not the opposite. --> I concur that the definitions are prone to misunderstanding. This very discussion proves the point. At some time in the forging of the BXAPL I noticed that nearly all occurrences of Contributor came in the phrase 'Contributors and/or Distributors'. Since the license always has been larger than I wanted it to be it seemed like a good idea to define Contributors as including any Distributors. So that's what I did. Apparently it was not a very good decision. I think I'll have to untangle the definitions and accept an even more unwieldy license text... Anybody got a better idea? > > If so, why did Steve Lhomme write in his message of 4 July: > > > >>A Distributor can be (or not) a Contributor. > > > > (I thought you were working together on writing this license and > > getting OSI approval. Are you disagreeing with each other on this > > point?) > > Yeah we just hoped we clarified all the obscure points together. It > doesn't seem to be the case on this one. --> If it causes confusion so easily, then it really needs mending! > > Is it your position that contributing software to the original copyright > > holder is not "distribution."? --> Exactly. See the definition in paragraph 2, Contributor. http://www.bixoft.nl/english/license.htm#par02a > > What happens when there is more than > > one original copyright holder? Can I send a copy to each and still > > not have it be "Distribution."? > > Sounds a bit tricky. --> Quite indeed. I think the answer is "yes" since you're not supplying it to any User, as defined in par. 2 But I must admit that such a scenario has not crossed my mind when setting up the license. > I think there shouldn't be a link between Contributor and Distributor. > Anyone can be one, the other or both. --> As *currently* defined, you cannot be a Distributor without also being a Contributor, but you might be a Contributor either with or without being a Distributor at the same time. I must admit it is quite counter-intuitive, I nearly put my foot in it myself... Thanks for all of your Contributions, which you have so lavishly Distributed to all the readers of the list ;-) Kind regards, Abe F. Kornelis. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Approval request for BXAPL
Dear all, With Nathan Kelley I have had a discussion, that has halfway turned private, i.e. we both forgot to cc the list. Since Nathan agreed with me that it would be a good idea to let you all in on the discussion, I have made a surmise of the various mails that have not yet been on this list, and adding comments to the last mail I just received from Nathan. Nathan, should you detect any errors, just holler and put all the blame on me. I've already shown how fallible I am, so it's quite ok ;-) Hope you'll all enjoy. Abe F. Kornelis. === From: Nathan Kelley <[EMAIL PROTECTED]> > >> I have read the Bixoft Public License (proposal version). I believe > >> that it is consistent with the Open Source Definition, and meets the > >> requirements for OSI certification. > >> > >> However, I do have a few questions on it: > >> > >> Item 10: The stated intention is to "denote software items that use > >> the Software, but that are not Derivatives of it". But do the > >> provisions of 10 achieve that? What modifications to the programming > >> tools, as stipulated in c), are sufficient to make the output a > >> derived work? > > > > Modifications to the Programming Tools will create a Derived work, as > > dictated by Copyright Law. When I started out, no such thing as > > Dependent Software existed, neither in my mind nor anywhere else. In > > the process of refining however, it dawned upon me, that regarding any > > software made with a programming tool as a Derivative imposes > > unrealistic restrictions on the author of such 'derived' software. So I > > introduced the term 'Dependent Software' and tried to define it as > > software that makes use of the programming tools without modifying > > them. The distinction thus draws upon the Copyright Holder designating > > Programming Tools as such. I tried other approached for making the > > distinction but could not find anything that satisfied. So, as long as > > Dependent Software contains no Modifications to the Programming Tools > > in the Software, it is just that; otherwise it becomes a Derivative and > > must be subjected to the more stringent redistribution rules in the > > license. > > OK. You might then want to use the term "Modifications", capitalised as > shown, to indicate it refers to modifications as per your glossary > definition. Otherwise, it *might* technically indicate that even things > like changing configurations for compilation, like the output path, > could be classified as modifying the Programming Tools, which would make > the output derived. Abe: Such options would normally be passed as invocation parameters, passed on the command line or through a script of some kind. This in no way constitutes a modification. On the other hand, since by copyright law definitions any translation yields a derived work, I wonder how relevant this might be? Output of a compilation or assembly is *always* a derived work, no matter how the compile was done, by which compiler (version), of how it was invoked. Nathan: Yes, it does. And this is a *big* practical problem with Item 10. Use of programming tools licensed under the Bixoft Public License would be very low, because not only could developers be required to distribute their work under the Bixoft Public License (even if they don't want to), but as their software would be a derived work, they could be required to send it to the copyright holders, gratis, at any time, even if they built the entire thing from scratch. This should be fixed in a revised version of the Bixoft Public License. I believe this can be done in one of two ways: 1. Change c) to read "they do not make Modifications to the Programming Tools or their function in any way". Since "Modifications" as per the glossary is limited to source code, c) would only take effect if the programming tools were actually modified at the source level, or Abe: That looks like a very good idea. I don't know why I never put in Modifications as defined. I think it should have been formulated that way. Thanks for suggesting this. Nathan: Great! :-) Nathan: (continued from previous remark) 2. Remove c) altogether, and add a requirement that any Modifications to the Programming Tools are distributed along with the source of the software, along with a notice stating which version of what software from what vendor the modifications apply to. Abe: If I leave it in, the choice is the author's either distribute it as dependent software, including any mod's to the tools, or keep the two separate and enjoy the much larger freedom granted for dependent software. I might make a choice for 'all whom it may concern' but it will never satisfy all of them, so I prefer to leave the decision to those who will bear the 'burden' of living by the consequences of that decision... Nathan: I think you meant "...either distribute it as dependent software, including any mod's to the
Re: Approval request for BXAPL
And yet another one. I have been most inattentive. I'll go stand in the corner... Abe F. Kornelis. From: Forrest J. Cavalier III <[EMAIL PROTECTED]> > > > Also, as written, I think this definition includes > > > compilers and linkers (and more! run-time ld? ) as > > > Source code. > > > > ld is not a Source file. > > The BXAPL says > "Source Code" is "... and any other files or members needed to >create the executables required to properly execute the Software" > > What if special features of ld are used? What if special features > of MSVC are used in the source code? > > gcc is really-high quality software now, but if you dig into any > complicated piece of software at least 10 years old, you can probably > locate well-commented code written a certain way to avoid triggering some > gcc bug. Am I allowed to put a note on the source code which says: > "Only compiles with MSVC 6.0 and later."? > > (I think I know your intent, but that doesn't match how I read > the license.) --> Ok, you've got a point. As defined in par 2 "Source Code" might be interpreted to include any executables etc. required for assembling / compiling / interpreting / executing the Software. This, of course, never was the intention. Gee, you seem to have missed quite a career as a lawyer ;-) Thanks for finding the bug. What can I do to mend the problem? I think I'll add a provision like this one: This includes any software - such as assemblers, compilers, linkers, interpreters, etc. - required for processing the Source Code to make it executable, unless such software is commonly available from one or more third parties, either Gratis or for a fee, in which case such software is not included in the Source Code as defined in this paragraph. Would this be better? All of your comments are welcome. Kind regards, Abe F. Kornelis. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Approval request for BXAPL
And yet another that should have been cc-ed to the list. Shame on me, isn't it? Once again I apologize. Abe F. Kornelis. From: Forrest J. Cavalier III <[EMAIL PROTECTED]> > > > The definition of "User" is too broad. It allows any > > > Distributor to force someone to be a "User" simply by > > > sending them a copy. > > > > But does it arm any part of the license ? Or just a personal feeling ? > > 8.5 seems to have an effect for "Users" --> Well, that's quite a long shot isn't it? > 15 may also. --> That's an even longer shot. > 16 also, but 16 is hard to follow. --> Par.16 relates to patent infringement litigation. To do that a copy of the Software would be required to prove that patent infringement exists. So the Patent Holder would likely be a User. What obligations does par.16 impose? That the Patent Holder pay for use of the Software. So if Patent Holder does not use the Software, no obligations are imposed. If, otoh, Patent Holder does use the Software, then the retribution obligation becomes a negotiable object. > Realistically, I think no court will find you had obligations > if someone sent you a source without request. But what if someone > obtains the source for determination if it infringes a patent? --> Agreed. See above. > Does the license allow them to inspect the software without > obligating them to #16? How? --> Does inspection / scrutiny qualify legally as "use"? I doubt it heavily. I certainly wouldn't expect it to. I think however, that you are right in finding that the definition of User needs a slight narrowing. In fact, I chose the verb "receive" because I didn't know whether "own" or "have" or "possess" would be adequate. Having a copy somewhere on a computer or a storage medium should make the owner a User; discarding all your copy should return any User to non-User status. Right? Anybody happen to know how to formulate this correctly? All suggestions are welcome. Thanks in advance and kind regards, Abe F. Kornelis. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Approval request for BXAPL
This one did not go to the list either. Another resend with apologies. Abe F. Kornelis. From: Forrest J. Cavalier III <[EMAIL PROTECTED]> > [Discussion of Paragraph 6] > > > > The "even if such marks are included" is a problem when you also > > > require (in a separate paragraph) verbatim distribution of the > > > software. I read that as "when there is any trademark in the > > > software, you are not permitted to distribute." > > --> In my opinion that would not constitute the "use" of such > > trademarks. Would this not be so under US law? > > > One way of including marks is as icons and graphics. These may > appear as output during the normal course of running the software. > (splash screens, for example.) They may appear at page headers > and footers of printed pages produced by the software. --> Ok, I see your point. However, as I see it, all Users are allowed to *display* the output of the Software, including any such marks. See par. 8.1. This does not give any right to the mark per se, so distributing Software that contains or displays such marks would not violate any restriction. Using such marks for other purposes would however violate trademark laws in the first place and the BXAPL in the second place (in that order, for clarity's sake). > I'm not a lawyer, but under US law, trademarks have to be > used as a description of something, a description which identifies > the source. --> That is an important point to be taken into consideration by any Contributor wishing to insert a mark into the Software for (re-)distribution. But how does it affect the relation between OSD and BXAPL, I wonder? > If there is a trademark in the software at all, then it must > identify the source. If I am not that source, then I can't > use the mark without separate agreement. --> As I see it, paragraph 8.1 grants you the rights you need for running the Software - with the mark, and for redistributing the Software. > Am I allowed to remove the marks by the BXPL? --> No, check par. 9.1. Of course, if you really wanted to, you might consider requesting allowance to do so from the Copyright Holder and/or relevant trademark owner(s). Kind regards, Abe F. Kornelis. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Approval request for BXAPL
I just noticed I sent this reply without cc-ing the mailing list :-( Therefore now resending with apologies. Abe F. Kornelis. From: Forrest J. Cavalier III <[EMAIL PROTECTED]> > The definition (at General #2) is as follows, and is formatted > thusly: > Contributor: > Any Distributor and/or > any User supplying any Modifications and/or Derivatives > and/or Dependent Software in any form to the Copyright > Holder, but not to any User(s). > > That makes it clear that every "Distributor" is a "Contributor" It was intended that "Distributor" designate anyone who redistributes the Software, with or without stuff of his/her own. This would include the Copyright Holder. A "Contributor" was intended to designate anyone who either redistributes the Software, with or without stuff of his/her own, or who supplies home-grown stuff to the Copyright Holder. Thus, as I intended it, a Distributor is *by definition* always a Contributor also, but a Contributor would not be a Distributor if that Contributor does not distribute the Software and/or the homegrown stuff associated with it. I hope this clears things up a bit. If anyone thinks this explanation is inadequate or not matching with the lecense text, please let me know. Kind regards, Abe F. Kornelis. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Approval request for BXAPL
- Original Message - From: Forrest J. Cavalier III <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, July 03, 2002 4:45 PM Subject: Re: Approval request for BXAPL > This is a very complicated license. Thanks for providing > the remarks and annotations. Very nice. > > After a quick read, I think that it should not be OSI approved, > for numerous reasons, some follow. > > Because the license is so complicated, it is not clear > to me that addressing the following points would be adequate > to make it OSD compliant. I think the two fundamental issues > are > it very much seems to be a EULA, trying to function > under copyright law, and EULA's are hard to get through OSD. --> it never was intended as a EULA. I fail to see why you would classify it as such. Would you please care to explain just how you arrived at this conclusion? > and > the Rationale a) is very difficult to set forth legally. --> It was indeed very hard - ultimately I found it so hard that I gave up trying - to find a 'generalized formulation' for creating the intended distinction. So I had to resort to each Copyright Holder explicitly stating the quality of each Software item, with the default being 'not a Programming Tool' - for practical reasons. Is this legally difficult? As Steve mentioned in his reply, neither of us is a lawyer. > Any license which attempts to make such distinctions must get > extra scrutiny. After all, the license ends up defining > "Programming Tool" as > "Any Software or portion of such Software > that is declared as being a "programming tool" > by the Copyright Holder. Such declaration must > be located in the Copyright Notice." >which I think is ripe for abuse and inconsistency in itself. --> I don't see a loophole for inconsistencies. Any Software item either is or is not a Programming Tool, the distinction being made explicitly (or implicitly when defaulted to No) by the Copyright Holder. As for abuse: if I write a little "Hello World"-type program and designate it a Programming Tool, that would be quite silly, but is it abuse? The only to 'suffer' from the abuse is the Copyright Holder who is giving more freedom to the receivers of the Software than he/she would have done by *not* declaring the program a Programming Tool. Things get more complicated when you write and distribute a set of macros. These might be designated Programming Tools, or they might be distributed as 'not Programming Tools'. In the latter case, any software created with these macros would become a Derivative, implying that any distribution of such Software must be under the BXAPL - which would be a strange restriction - to say the least. Or do you see this differently? > > The definition of "User" is too broad. It allows any > Distributor to force someone to be a "User" simply by > sending them a copy. --> As Steve pointed out, there is no harm in that. A User may do nearly anything with the Software. Serious obligations only raise their (ugly?) head when a User wishes to distribute the Software or any of his/her Derivatives. Certainly the mere fact of finding Software in your inbox does not force you to do anything with it? Or do I take this too loosely? > > The "Source code" definition includes this statement, "Source files > or members that contain obfuscated source do not count > as Source Code." > > "Obsfucated" is not well-defined. I've see a lot of legitimate > source files that appear to be obsfucated. --> Agree. The term "obfuscated" was taken from the OSD. I'm willing to consider any proposal for improvement. > Other OSI-approved licenses have definitions of "Source." --> So? > Also, as written, I think this definition includes > compilers and linkers (and more! run-time ld? ) as > Source code. --> If you prefer to make modifications to the compiled version of your programs rather than by changing the source and then re-generating the objects, load modules, or whatever - have it your way. But you may find it hard to convince others that this would be truly the case. > > Paragraph 6 says, in part: > No right is granted to the trademark(s) of any Contributor even if such marks > are included in the Software. The names of Contributors or any of > their products may not be used in any way without prior written > permission from the pertinent Contributor. Derivatives and/or > Dependent Software may not be named after the Software, nor may > they be given a name that might be confused with the name of any > Contributor or any Contributor's products and/
Re: Approval request for BXAPL
- Original Message - From: Nathan Kelley <[EMAIL PROTECTED]> To: OSI License Discussion <[EMAIL PROTECTED]> Cc: Abe Kornelis <[EMAIL PROTECTED]>; Steve Lhomme <[EMAIL PROTECTED]> Sent: Wednesday, July 03, 2002 1:40 PM Subject: Re: Approval request for BXAPL > > I have read the Bixoft Public License (proposal version). I believe that > it is consistent with the Open Source Definition, and meets the > requirements for OSI certification. > > However, I do have a few questions on it: > > Item 10: The stated intention is to "denote software items that use the > Software, but that are not Derivatives of it". But do the provisions of > 10 achieve that? What modifications to the programming tools, as > stipulated in c), are sufficient to make the output a derived work? --> Modifications to the Programming Tools will create a Derived work, as dictated by Copyright Law. When I started out, no such thing as Dependent Software existed, neither in my mind nor anywhere else. In the process of refining however, it dawned upon me, that regarding any software made with a programming tool as a Derivative imposes unrealistic restrictions on the author of such 'derived' software. So I introduced the term 'Dependent Software' and tried to define it as software that makes use of the programming tools without modifying them. The distinction thus draws upon the Copyright Holder designating Programming Tools as such. I tried other approached for making the distinction but could not find anything that satisfied. So, as long as Dependent Software contains no Modifications to the Programming Tools in the Software, it is just that; otherwise it becomes a Derivative and must be subjected to the more stringent redistribution rules in the license. > Item 16: I could be completely wrong here, but a) seems to effectively > create a situation where patent holders would pay others for use of > their own patents, while all third parties would be allowed to continue > infringement - with the only alternative being to withdraw the claim. Is > this correct? While I would love to see some large patent holders taken > down a peg or two, I believe this will be ruled unenforceable should it > ever get to court. --> Steve already answered this one, but I'd like to add my tuppence: First: an infringement claim does not imply actual infringement until the court's decision has become irrevocable and indisputable. Second: the claim for royalties is for the Software, whether infringing or not. The royalties are not for the patent, since the situation arises only when these are under dispute. It is mainly intended to prevent the 'Patent Holder' from raising a claim and at the same time using the Software without any retribution. If the Patent Holder wants to get something out of his/her patent, then he/she should also be willing to pay a fair amount for using the Software. Third: I did not make this up, I think I have been 'inspired' by the CPL/IBMPL. I just hope they won't sue me for 'lending' from their work :-) Kind Regards, Abe. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Approval request for BXAPL
Dear members of this license discussion list and dear members of the OSI board, We (Abe Kornelis of B.V. Bixoft with support from Steve Lhomme of Mukoli) would have preferred to use an existing OSI-approved license, or a copy of one with only slight modifications. Unfortunately none of the licenses currently approved by the OSI meet all of our criteria: a) Distinguish between software programs and programming tools. b) Require contributors to allow the copyright holder to incorporate any or all of their *distributed* modifications in future releases of the software. c) Treat copyrights and patent rights separately and explicitly. d) Disallow object-only distributions. e) Require that modifications remain recognizable as such. f) Make our dual licensing policy explicit. g) Allow the copyright holder to select the applicable law. h) Allow application of local languages in addition to english. So we needed to create our own - this has become the BXAPL, or the Bixoft Public License. Drafts of this license have been mentioned once or twice in this list, so this may not be too much of a surprise. Since so many licenses seem to be created with only minor differences, we have tried to create a template license, which we think will be usable to many. We request that this license be discussed and welcome any comments. Following are our answers to the requests on the OSI-site: 1. Put the license on a web page in HTML form. --> Done, see: http://www.bixoft.nl/english/license.htm It is a rather large document containing: - Rationale - Preamble, including a summary - Glossary - The license itself - Exhibit - Remarks on each paragraph of the license We will convert it into the same style as the existing approved licenses. You can help us by publishing it in that style yourself to save us the conversion step. ASCII text is preferred if asked to post your license to the 'licence-discuss' mailing list. --> I think that removing the header and trailer of the page suffices to create a piece of HTML that can be copied straight into your template. 2. Tell us which existing OSI-approved license is most similar to your license. --> First drafts were based on QPL and to a slightly lesser extent the MPL. Later we have added elements from IBMPL and various other ones. The draft has been extensively rewritten several times. More details can be found in the draft document. Every paragraph has a 'remarks' link which details the origin of that particular paragraph. Explain why that license will not suffice for your needs. --> See requirements. More is explained in the rationale of the draft document. If your proposed license is derived from a license we have already approved, describe exactly what you have changed. --> Essentially, we've changed nearly everything, for details please refer to the 'remarks' section of the draft document. This document is not part of the license; it is solely to help the board understand and review your license. 3 . Explain how software distributed under your license can be used in conjunction with software distributed under other open source licenses. --> It is intentional that such software can be combined. Which license do you think will take precedence for derivative or combined works? --> For such works the BXAPL maintains its own terms, unless the copyright holder allows otherwise. For Dependent Software (see glossary or paragraph 10 for definition) the matter is the same unless the Dependent Software is distributed in a separate package, in which case *any* OSI-approved license is ok. Is there any software license that is entirely incompatible with your proposed license?. --> The BXAPL is incompatible with the GPL, but it allows dual licensing and thus the two may quite well coexist, if any author chooses to allow it. 4. Send your proposed license by email to [EMAIL PROTECTED] --> That's this mail, isn't it? Indicate in the email whether you want the license posted to the license-discuss list with your identification or anonymously. (We are willing to consider licenses that the author doesn't want posted at all, but since community review is an important part of the approval process, we will have to circulate such licenses privately to individual reviewers: because of this, licenses not posted to license-discuss at all may take longer to approve, and are likely to require more interaction with you.) --> Anybody can mail his/her comments to me, either on the list or privately. You are invited to follow discussion of the licenses by subscribing to [EMAIL PROTECTED] --> Been on it for some time now... 5. If we find that the license does not conform to the Open Source Definition, we will work with you to resolve the problems. --> That'd be nice. 6.
Re: QuantLib License 1.0 submitted for OSD branding
Ferdinando Ametrano wrote: > > finally I'm settling for BSD and I will have to get back to > FSF for GPL compatibility certification. -- BSD allows redistribution of binaries without making the source(s) available. Is that what you want? Regards, Abe. -- Abe F. Kornelis, B.V. Bixoft Het Jaagpad 63, 3461 HA Linschoten The Netherlands phone: +31-6-22755401 To visit our website: either: http://www.bixoft.com or: http://www.bixoft.nl -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Exclusion of international laws
Hello all, Best wishes for the new year to all of you. I have noticed that various OSI-approved licenses exclude the United Nations Convention on Contracts for the International Sale of Goods. First question: why would anyone want to exclude a supranational regulation. I'd suppose such regulations are installed in order to promote international trade... Second question: Once this Convention has been ratified by a country's government I'd assume it has status of law within that country. Is it legally possible then, to bypass such a regulation? I mean, I could write that applciation of regulations relating to racism are excluded from my license X, but I seriously doubt that such a statement would have any consequence: it would simply be overridden by 'the law'. Anybody willing to shed some light on these - to me - murky matters? Thanks in advance, and kind regards, Abe. -- Abe F. Kornelis, B.V. Bixoft Het Jaagpad 63, 3461 HA Linschoten The Netherlands phone: +31-6-22755401 To visit our website: either: http://www.bixoft.com or: http://www.bixoft.nl -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: [Approval Request] Kallisys Reflexive License
Paul Guyot wrote: > > >The idea of applying the license to itself seems > >a clever one, but is incompatible with allowing > >modifications to the licensed work. > > I wonder why. Could you please develop, either regarding Draft 1 > (always interesting) or the newer Draft 2? -- Paul, If modifications are allowed *and* the license applies to itself, then each and every user is allowed to modify the license text... This would mean I could remove the requirement that your copyright notice not be deleted, then I could make a new distribution with the modified license, after replacing your copyright notice with my own. Alternatively I might modify the license so, that it allows me to create a proprietary package from your code, then distribute that with my modifications without releasing that code as open source. All taking and no giving. All in all: a modifiable license amounts to no license at all - it allows the recipient to do anything he/she wishes. If that is your intention, then why bother about the license? It would be easier to release it as public domain software. Regards, Abe. -- Abe F. Kornelis, B.V. Bixoft Het Jaagpad 63, 3461 HA Linschoten The Netherlands phone: +31-6-22755401 To visit our website: either: http://www.bixoft.com or: http://www.bixoft.nl -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: [Approval Request] Kallisys Reflexive License
Paul Guyot wrote: > > >- The text contains a large number of diacriticals > > (in the french sections). Though I liked the > > bilingual version, my browser died while trying > > to print it. Please consider using è > > é etc. for the characters with diacritics. > Both versions are bilingual. The American English or French text > can't be separated. But one is in one column (the one I'm working on) > and the other one in a single column (French, English, French, > English, etc.). They're encoded in ISO 8859-1 and they say so in meta > tags. I wonder what kind of problems you have. I encoded with an > HTML entity (i.e. Œ) because an old version of Netscape I had > didn't print it properly. I'm ready to put entities, but the W3C > recommends to not to when you can send 8 bits texts. -- I don't know on which character exactly the browser died. It *is* a pretty old one (Netscape 3). It works fine with the 'old' standardized diacritical names that can be encoded in 7-bit ascii. I don't know about the newer standard for 8-bit encoding. I assume it is more efficient with regard to bandwidth. If this standard has been approved, I'll not complain. Then it simply is my own problem. > I had a quick look, especially at the interesting (for me) preamble. > You're right about patents, but this isn't an European problem, and > probably not a problem at all. -- Sorry, you're wrong. > Software cannot be patented in Europe, AFAIK. -- Wrong again. Has been patentable for over thirty years, even in Europe. The pertinent patent laws claim that software is not patentable, but attorneys have find a very simple way around it. Now the de facto point of view is: software is not patentable as such, but combined with hardware it's a 'device', which is absolutely patantable. And without the hardware, what use is any software? It's an old and troublesome misunderstanding, fact remains that software can be patented. The european patent office has granted thousands of them over the last few years. If you want to make certain, check the EPO (European Patent Organization), or check the IBM website, which hosts a monstrously large patent database, containing american, european, and japanese patents. > And if they actually are, it's via weird protection methods. -- What you call weird is in fact standard legal practice. > I'm not sure that if you hold a patent (on a technique, since it's > the object of patents) and give free use (under an open source > license) of the form of the technique in a software that you can sue > someone for using this software. -- You could, if you did *not* include a patent license with the copyright license for the software. > What you can do is suing someone who would have not copied the form > (you gave a license to) but the technique (you cannot sue him for > copying the idea in any case, but with a patent, the part of the idea > which isn't the technique is quite small). The problem is that with > programs, the form is very close to the technique. -- That is indeed a problem. Now I'm not a lawyer, but AFAIK there is a lot of jurisprudence (Jurisprudentie in dutch, hope english word is correct) that defines the border, though it still may be a narrow one, there absolutely is a distinction - at least in legal terms and practice. > To give an example, let's say that Unisys distributes under BSD some > C code to compress data with the LZ algorithm. I doubt that they can > sue you if you use their code (they gave you the right to). -- They might license the code wothout the patent. That would allow you to do anything with it that the copyright license allows, *except* to actually tun the program without first obtaining a patent license as well. So you could study it, create derivatives, translate, redistribute, etc. etc. But as soon as anyone plans on actually using that code, or any derivative of it, then the patent license would have to be acquired first. > I also > doubt that they can sue you if you translate their C code to pascal > if the form is respected (except the language of course). -- That would be regarded as a derivative. > So in the > end, I think they can't sue you as long as you're doing computer > programs out of their code. -- Sorry don't understand what you're meaning to say. > I don't know if you had a look at their > patent, but as a software patent, it includes pseudo code. So if they > give you a license on a similar code, they still own the technique, > but no longer this expression of it. -- That might be, I'm not a lawyer. Still I'd be cautious to use such ciode without first checking whether or not the patent holder agrees that you may run that particular software without infringing on their software patent(s). Regards, Abe. -- Abe F. Kornelis, B.V. Bixoft Het Jaagpad 63, 3461 HA Linschoten The Netherlands phone: +31-6-22755401 To visit our website: either: http://
Re: [Approval Request] Kallisys Reflexive License
Paul Guyot wrote: > > Hi all, > > I would like to get the Kallisys Reflexive License (KRL) approved by > the Open Source Initiative. -- Paul, I did a quick read of your license and found nothing that will let me modify the licensed code. I don't know if modifiability is required by the OSD, but it will definitely keep me from using your license for my software. The idea of applying the license to itself seems a clever one, but is incompatible with allowing modifications to the licensed work. Regards, Abe. -- Abe F. Kornelis, B.V. Bixoft Het Jaagpad 63, 3461 HA Linschoten The Netherlands phone: +31-6-22755401 To visit our website: either: http://www.bixoft.com or: http://www.bixoft.nl -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Intel's proposed BSD + Patent License
Russell Nelson wrote: > > Abe Kornelis writes: > > Russell Nelson wrote: > > > > > > [ Please review this license. If you do so promptly enough, we may > > > be able to include it in tomorrow's board meeting. -russ ] > > -- > > This raises some questions. We recently had a lengthy discussion > > on the speed with which licenses are handled by the OSI board. > > It's good to see that speed is attempted, but it leaves me > > wondering when other license proposals (4 in wait, as far as I know) > > will be discussed on a board meeting. > > They're on the agenda also. > > > But speed has its disadvantages. You sent your mail at 11:40 Eastern > > Standard Time. For us in europe that is 17:40. > > We don't meet for another 7 hours from now. > It's obvious that this license will take a lot more discussion. I'm > not going to put it on the agenda (although of course other board > members may choose to introduce it). -- Ok, that's fair enough. I do think it's important that anybody on the list gets a decent chance to react to any license for which approval is requested. Since this seems indeed to be the case, I apologize for my apparent overreaction to your first mail. Regards, Abe. -- Abe F. Kornelis, B.V. Bixoft Het Jaagpad 63, 3461 HA Linschoten The Netherlands phone: +31-6-22755401 To visit our website: either: http://www.bixoft.com or: http://www.bixoft.nl -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
[Fwd: Re: Intel's proposed BSD + Patent License]
Message below forwarded to the list, because I forgot to cc the list on my original reply. Apologies for the confusion. Regards, Abe. -- Abe F. Kornelis, B.V. Bixoft Het Jaagpad 63, 3461 HA Linschoten The Netherlands phone: +31-6-22755401 To visit our website: either: http://www.bixoft.com or: http://www.bixoft.nl Russell Nelson wrote: > > [ Please review this license. If you do so promptly enough, we may > be able to include it in tomorrow's board meeting. -russ ] -- This raises some questions. We recently had a lengthy discussion on the speed with which licenses are handled by the OSI board. It's good to see that speed is attempted, but it leaves me wondering when other license proposals (4 in wait, as far as I know) will be discussed on a board meeting. But speed has its disadvantages. You sent your mail at 11:40 Eastern Standard Time. For us in europe that is 17:40. Those who have enough time in the evenings might have a chance to respond, but people located further east (Australia, New Zealand, Japan, China, etc) will almost certainly receive your mail only after the board meeting will have ended. I would suggest that the people on this list be given at least 48 hours to respond to submission requests. That would give anyone on the list, anywhere on the globe, a reasonable chance to add his/her comments *before* the board meets. Regards, Abe. -- Abe F. Kornelis, B.V. Bixoft Het Jaagpad 63, 3461 HA Linschoten The Netherlands phone: +31-6-22755401 To visit our website: either: http://www.bixoft.com or: http://www.bixoft.nl
Re: Approval request, DSPL v1.1
Julian Hall wrote: > > Following comments I received on version 1.0 of the DSPL, I have > prepared a revision for submission for approval. > > I look forward to receiving your comments! -- Julian, Just a personal remark: I would feel very hesitant to contribute software under this license, since it requires me to pay any taxes on money gathered and spent by 'the Committee'. In supplying free software to anyone, in any way, I'd expect 'free' to work both ways - paying committee's taxes does not count as such. If you see this differently, would you please care to explain? As long as there is a risk that I'll have to pay more taxes than I'll receive from Merit Shares, I'd rather keep my modifications and/or additions to myself. Supplying software for free means - to me - that I want to be free of obligations for that software too. In the context of your license this seems asking too much: may cost money, needs checking the Committee and its decisions, calling for a no-confidence voting, etc. Then there is the point of the Committee's decisions: I have never yet seen such committees in free software land, but such constructions are well known in other areas of society. They all bear the risks inherent to with limiting power to a few people. Our govenrnments are scrutinized by the prress, for what it's worth. I don't expect your Committee to receive as much attention. How do you limit the risks of corruption? The no-confidence road is not much use. Once the Committee has signed a contract the money is gone. No new Committee can revert that. Regards, Abe. -- Abe F. Kornelis, B.V. Bixoft Het Jaagpad 63, 3461 HA Linschoten The Netherlands phone: +31-6-22755401 To visit our website: either: http://www.bixoft.com or: http://www.bixoft.nl -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Motosoto PL remarks
Hello all, I've been reading the Motosoto Open Source License. The following details struck me: 1) the derivation from JOSL is apparent, but somehow Motosoto managed to garble the paragraph numbers. Not a real disaster, just inconvenient. 2) In the paragraph numbered 5, Motosoto chooses dutch law as the applicable law, but they retain the statement about jury trial. Now, I'm not a lawyer, but I do happen to be dutch and to *my* (admittedly limited) knowledge, juries do not exist under dutch law... What happens if you waive your rights to non-exisiting entity? Are they voided? Do their rights become unenforcible? I have a hunch they are shooting themselves in the foot (feet?) by applying the quick-and-dirty method to their changed version of the Jabber Public License. Regards, Abe. -- Abe F. Kornelis, B.V. Bixoft Het Jaagpad 63, 3461 HA Linschoten The Netherlands phone: +31-6-22755401 To visit our website: either: http://www.bixoft.com or: http://www.bixoft.nl -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Open source + commercial
Ravicher, Daniel B. wrote: > > Not to be sarcastic, but good luck trying to delineate commercial from non. -- There's a relatively easy way around that one: the usual commercial distributors guard their source code as their own holy grail. So the Open Source License would be applicable to anyone wishing to use his software for code that is either not distributed at all, or that is distributed under an OSI-approved license. Anyone else will have to acquire a closed license to legally use his software. The distinction as to how the 'derived' software is distributed is much easier to make than the distinction between commercial and non-commercial. I'm not a lawyer, certainly not with regard to american peculiarities of law, but this is the approach I chose on my Open Source License. It has not yet been offered for review, as I feel it takes some more thinking and tinkering to mature. Plus I feel *very* hesitant to add yet another license to the list of licenses pending for certification... Since the matter is under discussion anyway, feel free to take a look at http://www.bixoft.nl/english/license.htm All comments are welcome. Regards, Abe. -- Abe F. Kornelis, B.V. Bixoft Het Jaagpad 63, 3461 HA Linschoten The Netherlands phone: +31-6-22755401 To visit our website: either: http://www.bixoft.com or: http://www.bixoft.nl -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Contamination
Hello all, I have a question regarding contamination. English is not my native language, I'm trying to avoid misunderstanding the OSI concepts. I have a macro library that I would release under an open source license. I want everyone to be able to use and/or enhance the macros in the library freely. BUT: I don't want commercial software packages to use my macros without payment (dual license offering). To make a paid license more attractive the open source license I will use must contain a clause to the effect that any software using my macro library - or part of it - in any way MUST be licensed under the same conditions (as the macro library i.e.) Would this be regarded as contamination? It would still be possible to distribute the macro library with other software without contaminating the other software - you cannot call a macro. However, if the software created with the help of my macro library is being called, then contamination *will* occur. At least, as I currently understand the concept of contamination. Am I right? If so, does anyone have a suggestion how to solve the problem. I really dont want large, rich, companies to save large sums of money on maintenance without paying me for the effort I made to create the macro library (over half a year of full-time labor went into it...) Regards, and thanks in advance, Abe. -- Abe F. Kornelis, B.V. Bixoft Het Jaagpad 63, 3461 HA Linschoten The Netherlands phone: +31-6-22755401 To visit our website: either: http://www.bixoft.com or: http://www.bixoft.nl -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
