Re: Copyright Act preempts the wave theory of light
To OSI License Discussion subscribers, From: Daniel Carrera [EMAIL PROTECTED], Can we stop these posts already? About 280KB worth of e-mail has now be exchanged in discussing this topic, including the 'amusing' spin-off discussions. It's certainly an important topic, if for no other reason than it has ramifications for other licenses beyond the GPL and, indeed, for the nature of Open Source. It also of course affects a large number of products and projects, although that is beyond the scope of the discussions here. But at this stage, it might be worthwhile for all parties to acknowledge widely divergent opinions exist regarding the legality of the GPL (and have for a long time) and that the best way of 'establishing' its' legal basis is still to wait and see how it fares once tested before a court. That may happen during the SCOX vs. IBM litigation. Subject: Copyright Act preempts the wave theory of light A significant number of electrons were, however, severely inconvenienced. Energy is your friend =) Cheers, Nathan. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Why? Re: Will we be sued?
To John Cowan [EMAIL PROTECTED] and OSI License Discussion subscribers, From: Nathan Kelley [EMAIL PROTECTED], From: John Cowan [EMAIL PROTECTED], All good advice, Larry :-) No no no no no no no. It is *not* advice. It is *not* advice. It is only education! Although this posting was written by a non-lawyer, I am not *your* non-lawyer, nor are you my non-client. If you have a specific problem, you should pay your own non-lawyer the big bucks to give you his very own personalized non-answer. My apologies. Allow me to correct the situation: (1) Very educational, Larry :-) should be substituted as that conveys the intention of my last sentence. (2) My previous post was not legal advice and this post is not legal advice either. *ducks and runs for cover* Cheers, Nathan. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Why? Re: Will we be sued?
To OSI License Discussion subscribers, From: Jan Dockx [EMAIL PROTECTED], From: David Presotto [EMAIL PROTECTED], From: Jan Dockx [EMAIL PROTECTED], From: Lawrence E. Rosen [EMAIL PROTECTED], Are we really afraid that we will be sued for damages by something we give away for free (as in free beer)? The recipient may not have gotten your code for free. Anyone can redistribute for money as part of something they build or just with better packaging and/or support. The original contributors can and will be sued for anything that goes wrong; its the american way. If you say so. I understand that for the patent infringement, but for damages, I think it is weird. I would expect the party that made money of it to get sued, and possibly convicted, but not the original authors that put the thing in the public domain. This is not as clear-cut as it looks. Example 1: You create a program and release it licensed under an OSI-approved license. A third party then takes the program and sells it as allowed under the license. A large corporation adopts the program and uses it widely, but suffers damage to its business due to a bug in the program code, which when tracked is code entirely written by you. For all intents and purposes, the program has been configured and operated correctly by the large corporation. You were not a party to the sale of the program by the third party. Example 2: You create a program and release it licensed under an OSI-approved license. A third party then takes the program, makes some changes (effectively creating a derivative work) and sells it as allowed under the license. A large corporation adopts the program and uses it widely, but suffers damage to its business due to a bug in the program code, which when tracked is code entirely written by you. For all intents and purposes, the program has been configured and operated correctly by the large corporation. You were not a party to the sale of the program by the third party. Example 3: You create a program and release it licensed under an OSI-approved license. A third party then takes the program, makes some changes (effectively creating a derivative work) and sells it as allowed under the license. A large corporation adopts the program and uses it widely, but suffers damage to its business due to a bug in the program code, which when tracked is code that has been added by the third party or original code of yours subsequently modified by the third party. For all intents and purposes, the program has been configured and operated correctly by the large corporation. You were not a party to the sale of the program by the third party. In each of the above examples, the fact that the large corporation in question has suffered damage from the use of the program is why they are suing, rather than because they paid for it. The code that was written is deemed to be the actions taken that caused the damage if the code turns out to be incorrect, or worse malicious. For each example, who would you expect the large corporation to sue? What arguments would you expect them to present? How would you respond or expect the third party to respond? And what would you expect the likely outcome to be? This can be a very grey area indeed. (Editorial Note: I know these aren't the best examples, but they illustrate the point). Most all of the OSI-approved licenses help add weight to your response, as the author of the software, through disclaimers forming part of the license body. Nothing can prevent you from being sued or taken to court, but the terms of the license mean all the difference between a judgment in your favour and a judgment in the plaintiff's favour. 1) a) Do I understand it correctly that you _believe_ that you can be sued for damages if code that is distributed for free _fails_, at least in the States? And that a disclaimer as it is presented with most Open Source licenses makes this threat go away? You can be sued for just about anything. Whether the action is successful or not is the matter in question, and how likely it is to succeed or not *and* get the result that the plaintiff's want is another matter entirely. A license can't make the 'threat' go away, but it can make it more trouble than its' worth unless the plaintiff is really serious. 2) An important aspect of the disclaimer seems to be a protection against possible patent infringement. As a single developer we are not able to do extensive patent research, we publish the code, and if anybody later claims that we broke a patent, we want to be protected. a) Do I understand it correctly that you _believe_ that a disclaimer in this respect makes this threat go away? See above. b) If so, how? People are using software, which they found on the net, which they use in good trust, often without them being in a position to read source code or do the extensive patent research themselves. But the software is being used, so the
Re: That Notorious Suit (Slightly OT)
To Daniel Carrera [EMAIL PROTECTED], From: Nathan Kelley [EMAIL PROTECTED], From: Daniel Carrera [EMAIL PROTECTED], From: Nathan Kelley [EMAIL PROTECTED], I had never heard of this stumbling block (not to say that it wasn't there). But I've never heard of someone not wanting to use a GPL product because they weren't sure if the license would stand in court. It's a point commonly brought up by analysts when handing out advice through c|net, BusinessWeek, InfoWorld, and friends. Are those analysts all called Rob Enderle by any chance? Nope. Whenever I see that name attached to an article I skip it. There are others making these claims, and what's odd is they seem to believe them. The odd part is where you don't see these claims, or even inquisition, on proprietary licenses hidden in the shrinkwrap. They assume that proprietary licenses hidden in the shrinkwrap were crafted by people who know what they're doing and don't need to be challenged, and that open-source licenses are by definition not. As Zak pointed out, this is not a logical or cohesive argument. So, we end up with analysts not asking the tough questions, online publications such as those above giving said analysts airtime, and the wrong idea gets conveyed; the association between the GnU General Public License and Fear, Uncertainly and Doubt. This is why you keep seeing very odd opinions and ideas of what the GPL represents, versus what it actually does. But since declaring a license invalid out-of-hand will cause an analyst to be subject to extreme ridicule on the grounds they're straying from their field of expertise, they also claim that, were the GPL to be tested in court found meritorious, that would be proof absolute that you could rely on it not to land you, your colleagues and your customers in a nasty spot. It all sounds very silly, doesn't it? But I've read it enough times to know how the story goes. And each time I see it, I remain surprised at how short-sighted some of these people can be. I believe it will reduce further as Linux-distributions and other technologies become more mainstream, and thus a fact of life. They don't put stock into the GPL apparently because a high-priced team of lawyers didn't create it. That is, of course, a silly point to make, but they make it anyway. And people listen, including The People Who Matter at any given workplace. Sigh... Typical PHB. Unfortunately, yes. I was surprised though, at my current workplace, to find a distinct lack of PHB's in IT areas. It only means that silly decisions and sillier convictions are less per month than the average, though :-( If Linux were BSD there would be no suit, simply because there would be no competition. I agree wholeheartedly with this point. And there wouldn't be thousands of volunteers if they thought they were providing free labor for others, particularly development houses that then released products only for the Windows platform. Fortunately, we're not in that dimension. I hadn't thought of that. That might be part of the reason why the GPL-based projects are so much larger than the BSD-based projects. Zak made good points here about Apache, Perl and PHP. I'll just add that the reasons for not choosing to go with the GPL are as much ideological - from what I've seen, having been close to some projects - as they are with choosing the GPL for the reasons the FSF intends... despite what RMS says about open-source. Cheers, Nathan. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
That Notorious Suit (Slightly OT)
To OSI License Discussion subscribers, By That Notorious Suit I mean the ongoing drama between The Santa Cruz Operation and International Business Machines over breach of contract. I appears that the GnU General Public License, as part of routine proceedings in the case, is to be examined: http://news.com.com/2100-7344_3-5098610.html Reaction to this at Slashdot, OSNews and other sites was predictable. Of course, the opportunity for the GnU General Public License to be weighed, measured, and not found wanting is obvious, as much as the potential consequences if it is found wanting. The next logical step is to ask what flow-on effects a ruling in either direction would have - or might have - on other OSI-approved licenses. Not being familiar with U.S. law, I would appreciate any insights on this point. Also, I'm glad to see an increasing use of open source products at the enterprise level in an open manner. It was not so long ago that the attitude was one of hush hush. Cheers, Nathan. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: That Notorious Suit (Slightly OT)
To Daniel Carrera [EMAIL PROTECTED], From: Nathan Kelley [EMAIL PROTECTED], From: Daniel Carrera [EMAIL PROTECTED], By That Notorious Suit I mean the ongoing drama between The Santa Cruz Operation and International Business Machines over breach of contract. To be picky, Santa Cruz Operation != SCO. Inspite of the apparent connection. Thanks for the correction. *looking embarrassed* Substitute The Santa Cruz Operation for The SCO Group - their official name as per http://www.sco.com/company/profile.html. Of course, the opportunity for the GnU General Public License to be weighed, measured, and not found wanting is obvious, as much as the potential consequences if it is found wanting. The next logical step is to ask what flow-on effects a ruling in either direction would have - or might have - on other OSI-approved licenses. Not being familiar with U.S. law, I would appreciate any insights on this point. 1) Within your scenario, you should also consider the *probability* of the GPL being found wanting. This is an important point. For example, I don't have a contingency plan in the event of meteor collisions. But the probability of one happening is low enough that I'm not worried. That is a debatable point. For every claim that the GnU General Public License is bulletproof, I can probably find a counter-claim that, in one user's words, the GPL has holes you could drive a truck through. Who's to say which is correct with genuine authority and independence? 2) But to address your question anyways... I don't see how a problem with one license can have any effect on another, unless they are very similar. In the event that the GPL is deemed invalid, I would bet that the LGPL would also be deemed invalid, because they have some resemblance. However, the MIT, BSD and X11 licenses would be untouched. They are entirely different. Any grounds under which the GPL is deemed invalid would be very unlikely to apply to any of those. Likewise, I would expect that a positive ruling would give credence to similar licenses, and have no effect on different licenses. I agree on that point. Those licenses are very unlike the GPL. But there are many licenses out there, some of them close to the GPL in fashion. Those could also be in the same boat as the LGPL, and claiming that they have nothing to do with the Free Software Foundation might not help down the track; if it walks like a duck and it talks like a duck, after all... And of course, should the decision go the _other_ way, that being the GPL has not been found wanting, a long-time claimed stumbling block to adoption of GPL'd products would be diminished, or removed entirely. The GPL's near relations would again also benefit. Although this is only a peripheral issue - at least for now - in the proceedings, it could have far-reaching effects. The BSD license is very simple. I can't see it ever having a problem. Also, since it's very permisive, I can't imagine anyone being interested in questioning it. Ditto for MIT, X11 and Apache licenses. I agree on this point, too. Which raises the point that perhaps, were the BSD license used for most open-source projects and were _that_ license the one that IBM was backing, would this whole situation of grander and grander claims by SCO each month or so not have come to pass? For that matter, could the proceedings have moved quicker? IANAL, but this is my take on this. I'm glad you did :-) Cheers, Nathan. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: That Notorious Suit (Slightly OT)
To Daniel Carrera [EMAIL PROTECTED], From: Daniel Carrera [EMAIL PROTECTED], From: Nathan Kelley [EMAIL PROTECTED], From: Daniel Carrera [EMAIL PROTECTED], 1) Within your scenario, you should also consider the *probability* of the GPL being found wanting. This is an important point. For example, I don't have a contingency plan in the event of meteor collisions. But the probability of one happening is low enough that I'm not worried. That is a debatable point. For every claim that the GnU General Public License is bulletproof, I can probably find a counter-claim that, in one user's words, the GPL has holes you could drive a truck through. Who's to say which is correct with genuine authority and independence? Well, my point of view (that the GPL is safe) has over 20 years' worth of testing in the form of the fact that not a single GPL violator (and there have been several) has felt that the could win against the GPL in court, and so each one has preferred to settle the issues out of court. If the GPL were weak, it seems likely that people would have taken advantage of that by now. In the past 5 years, products released under the GPL - specifically Linux-distributions and products designed to run on them - have had an increasing amount of enterprise exposure, backing and support. I can attest to a number of enterprises I know of promoting Linux-distributions as a stable and mature platform for business delivery to the corporate executive. Where the money goes, the suits follow. This current suit definitely won't be the last. As worded, the GPL is hardly weak. But, it doesn't have to be to fail in court, since there are many different angles from which it can be challenged. A plaintiff going to court simply to challenge the validity of the GPL isn't likely to happen; after all, what would be the point? Rather, as with the current suit, the GPL comes up incidentally during proceedings. I have no doubt of the FSF's and open-source community's ability to adapt to piecemeal rulings on the GPL, but that does depend on _what_ the rulings are. Which brings me back to my original question. Now, I wasn't really comparint the probability of the GPL failing with that of a meteor impact. That was just an example. I'm just saying that probabilities should be considered. The point is that not all posibilities are created equal. This is a point that many people seem to miss (I'm not saying you did). But yes, it's also wise to look at as many options as is feasible. Exactly! That's why click-wrap and friends have been such a huge deal on this list and on other forums; what if someone wanted to sue for damages?. The likelihood of a volunteer developer or small development business actually being sued into the ground by an enterprise is slim, but no chances are taken. I agree on that point. Those licenses are very unlike the GPL. But there are many licenses out there, some of them close to the GPL in fashion. Those could also be in the same boat as the LGPL, and claiming that they have nothing to do with the Free Software Foundation might not help down the track; if it walks like a duck and it talks like a duck, after all... In an ideal world, association with the FSF shouldn't matter. A license is (should be) valid if it's language is clear and legal. So if the GPL is valid/invalid, I would expect that similar licenses would be likely to be valid/invalid respectively. I would hope so too. It's really easy to avoid the whole question of which licenses are valid and enforceable and which licenses are not through tarnishing by association. Unfortunately, that's exactly what some will do. And of course, should the decision go the _other_ way, that being the GPL has not been found wanting, a long-time claimed stumbling block to adoption of GPL'd products would be diminished, or removed entirely. The GPL's near relations would again also benefit. I had never heard of this stumbling block (not to say that it wasn't there). But I've never heard of someone not wanting to use a GPL product because they weren't sure if the license would stand in court. It's a point commonly brought up by analysts when handing out advice through c|net, BusinessWeek, InfoWorld, and friends. They don't put stock into the GPL apparently because a high-priced team of lawyers didn't create it. That is, of course, a silly point to make, but they make it anyway. And people listen, including The People Who Matter at any given workplace. I agree on this point, too. Which raises the point that perhaps, were the BSD license used for most open-source projects and were _that_ license the one that IBM was backing, would this whole situation of grander and grander claims by SCO each month or so not have come to pass? For that matter, could the proceedings have moved quicker? Ah... now I can't help but bring up a conspiracy theory... Why is SCO doing this anyways? Ultimately it's because
Re: discuss: Jaluna Public License 1.1
To OSI License Discussion subscribers, From: Benoit Poulot-Cazajous [EMAIL PROTECTED], Please consider the Jaluna Public License 1.1 for approbation. This license can be found at : http://www.jaluna.com/developer/jpl-1.1.html This license is derived from the Mozilla Public License 1.1, with the following modifications (cutpasted from http://www.jaluna.com/developer/license.html) : 1) The license is named Jaluna Public License instead of Mozilla Public License, as it refers to software distributed and maintained by Jaluna, 2) As required by the MPL, all references to Mozilla or Netscape, have been replaced by equivalent references to Jaluna. 3) Sections 6.x of MPL 1.1 grants the right to make new versions of the license to Netscape Communications Corporations. The JPL 1.1 grants this right to Jaluna SA. 4) JPL 1.1 refers to the law of France. I haven't had the opportunity of reading the license in full as yet. However, if the above list is both accurate and comprehensive with regards to what has been changed, then I see no problem with the license being OSI-certified, as only the names have changed. Cheers, Nathan. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Antiwar License
To OSI License Discussion subscribers, From: Sergey Goldgaber [EMAIL PROTECTED], A recent Slashdot article, U.S. Army's Future Combat System Will Run Linux, http://slashdot.org/articles/03/03/02/0216215.shtml?tid=103tid=163 has made me wonder if there could be some way to prevent the military from using software that you release as open source. Some licenses allow free use of the author's software by private individuals and non profits, but require a fee to be paid by corporations. Along similar lines, wouldn't it be possible to create a license prohibiting the use of one's software by the military, the Defense Department, and military contractors? In addition to helping make sure that the work you do does not contribute to murder (in some direct or even indirect fashion), an Antiwar License would be a powerful political statement that I believe could catch on rather quickly in the current atmosphere of protest. However, INAL, and was wondering if any of the more experienced people on this list think this is a feasable idea, or perhaps could even suggest some possible wordings that such a license could use. There are three practical problems with this scenario. As others have pointed out: * The license would be essentially unenforceable. * The license would not be open-source as it would violate the OSD's terms. I would like to add: * The license would serve to undermine the credibility and integrity of open-source. Many authors in the open-source industry, generally being individuals, have been stereotyped in years gone by as either PFY's (usually students) or as old, fat, bearded (only for men, of course) people, the twain alike spending way too much time behind their computers. This is of course patently false, and we can all attest to this. But these stereotypes have only been turned around in recent years in the eyes of the public due to powerful, stable, and cost-effective deliverables, mostly Linux-based, being delivered by reputable companies and businessmen. A license such as this would go against the latter turnaround in perception, and help to reinforce the former stereotypes: Excellent developers, but do we need to listen another student protest? My opinion only, but this issue goes beyond the comfortable confines of this list topic. Cheers, Nathan. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: discuss: No Warranty License.
To Justin Chen-Wells, Rod Dixon J.D. LL.M. and OSI License Discussion
subscribers,
From: Justin Chen-Wells [EMAIL PROTECTED],
From: Nathan Kelley [EMAIL PROTECTED],
From: Justin Chen-Wells [EMAIL PROTECTED],
From: Rod Dixon J.D. LL.M. [EMAIL PROTECTED],
On the other hand supposing some government passes a law:
No citizen shall accept a software license which requires
publishing the source code of a derivative work.
Would we then declare that the GPL is not OSD because it
discriminates against people in that legislative jurisdiction?
No, we wouldn't. But there is a difference between your scenario and
that of the No Warranty License: your scenario says the user can't
accept the license because their jurisdiction say they can't,
whereas
the No Warranty License says the user CAN accept the license, but
they
don't get any of the OSD-guaranteed rights if their jurisdiction
doesn't allow limited liability.
So, let's take one more step along this slippery slope: What about a
license which says:
You must read and understand this license before accepting it.
Discrimination against the illiterate, the blind, the mentally
challenged, and, for that matter, anyone who can't read English?
That only holds if that statement is (a) completely inflexible, and (b)
you interpret it literally instead of on the basis of its intent. On
that basis, none of those groups would be legally able to do things
like buy houses, gain employment, open bank accounts, obtain passports,
or other such activities... but we know that they do every day.
If we really wanted to, we could probably find discrimination in every
sentence of every open-source license on file. But what's the point?
We're interested in the source code being open, and attempting to
compensate for every possible discrimination would get in the way of
that. That's a truism universally, not just for open source.
Those that are blind aren't allowed to drive; that's discriminatory,
but which do you value more: no discrimination, or safe roads? To have
both would be nice, and with technological and medical improvements, we
might be able to have both, but that's in the future. For now, you need
to choose.
Those in the proprietary software business aren't allowed to re-use
code from any software licensed under any OSD-compliant license in
their proprietary products without conforming to the conditions of the
license, making their product nonproprietary; that's discriminatory,
but which do you value more: no discrimination, or open-source
software? To have both would be nice, but until the way the world works
changes, we're stuck with that choice.
Perhaps it's unfair. But life's unfair. What we can do is make it less
unfair without compromising ourselves or our goals. Accepting or
rejecting licenses based on whether they match the spirit of the OSD as
well as the OSD criteria is one such method, including the No Warranty
License.
But if you wave away that you might wave away this:
To use this software you must be legally capable of accepting
this agreement including all of the following terms:
This software is provided AS IS with NO WARRANTY.
We're almost back to where we started. This isn't as explicit as the
NO WARRANTY license but it amounts ot the same thing--someone who
is in a jurisdiction where warranty disclaimers are invalid would be
not be legally capable of accepting this agreement.
Such a statement would be superfluous; if you're not legally capable of
accepting the agreement, then whether or not the agreement says so
doesn't make any difference. A license that had such a clause as this
probably wouldn't make it onto the approved list, since superfluous
statements usually only serve to cause trouble.
If you can't accept that agreement, then you get what rights you would
have had without it; in some jurisdictions that means you can use the
software even without the license; in others, it may mean you have all
the OSD-granted rights. Imagine that, not accepting a license agreement
and getting MORE rights than you would have had!
Unfortunately, most software doesn't give you the option; you click
'Disagree', the software calls an exit(), and you're landed back on
your desktop without the chance to use the software even if you have
every legal right to do so without accepting the license. In this way
licenses tend to strong-arm themselves into being agreed to.
Now if it came to court, not only could the user claim that they were
denied their legal rights to use the software even without a license
(assuming they're in a jurisdiction that has such a right), but the
offending clause would likely be ruled invalid. You saw this too, since
you wrote:
Or maybe you could just write this:
If any part of this license is ruled invalid then the entire
license shall be considered null and void.
An anti-severability clause may be a dumb idea as it's just plain
dangerous. But the license doesn't
Re: discuss: No Warranty License.
To OSI License Discussion subscribers, From: Anonymous Poster, From: David Johnson [EMAIL PROTECTED], I have concluded that the No Warranty License does not conform to the Open Source Definition. The offending clause is as follows: If the following disclaimer of warranty and liability is not valid due to the laws in a jurisdiction then NO RIGHTS ARE GRANTED in that jurisdiction without the express written permission of the copyright holder. This violates Item 5 of the OSD, which states that The license must not discriminate against any person or group of persons.. By not granting equal rights to users, distributors and open-source developers based on factors beyond their clear control (the laws of their jurisdiction), they are being discriminated against. This also violates Item 7 of the OSD, which states that The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.. Users, distributors and open-source developers in affected jurisdictions cannot exercise the rights they are guaranteed under the OSD for OSD-compliant licenses without obtaining additional permission (license) from the author. Further, the only way to effectively enforce this license is to prevent users in the affected jurisdictions from obtaining or using the software, since as I understand it (IANAL, TINLA, CMIW), the wording of a license cannot override the laws of a jurisdiction, nor physically prevent someone from filing a suit on those laws; it might put you in a more favorable position (that, if assent could be proven, the user assented to the terms and has now violated that; what legal significance this would have is questionable), but that's all. Since the offending clause forms the only tangible difference between the No Warranty License and the BSD License, I recommend that the No Warranty License be rejected. Basically, I want a BSD license but I don't want some chuckle-head in a country where warranty disclaimers aren't valid trying to start a legal fuss. The only possible point that could be raised is point #5 of the open source definition. However, I think calling this discrimination against a person or group is a bit of a stretch. Unfortunately, it's not a stretch at all, for the reasons outlined above. The discussion over the past half-year has included a lot of suggestions of ways to get small open-source developers out of the very real threat that an enterprise-level suit could ruin their lives for essentially contributing 'freely' to the world. I think there is some consensus that as laws in a number of countries currently stand, this is problematic at best and impossible at worst, without changes to the relevant Acts. So far, what has saved open-source developers has I believe had little to do with legalities; it benefits no-one, there is not likely to be any cost recovery, it only delays the fixing of the actual technical problems (where these exist), and it makes for really, really bad PR for those doing the suing at a time when it seems like the 'little guys' are readily being squashed flat by the 'big guys' for the sake of the latters' own business and political interests. I agree that steps should be taken to protect authors, but this approach, like the others we have seen that attempt to stop any suit in its tracks, is doomed to failure. It comes down to using a license to attempt to make authors untouchable, a position that any judge will simply not accept. But there's a bigger issue. The author doesn't want some chuckle-head suing him, yet what's to prevent some chuckle-head author from suing users under the same clause? What if I don't know if this warranty is valid in my jurisdiction, and give the software to a friend? Will I get sued because I didn't receive the right to distribute the software? How will the author know you re-distributed it to your friend, since there is no requirement to advise the author? And unless the author has logs from your workstation or ISP at the time (both very hard to procure), how will they prove that you exercised rights of distribution that were not granted to you by the license and that are normally forbidden? And for what reason could they sue you? For potential damages from as-yet unfiled suits from as-yet unknown users? In addition, the warranty covers use of the software, yet I can obtain the right to use the software without having to agree to the license. And here you hit the nail on the head; rights granted to you by law which cannot be overridden by a license except by the licensor granting rights to the licensee. So in such jurisdictions as yours, you can get obtain program and use it, but not do other things such as re-distribute it or make derivatives. Does this hurt you? In a philosophical sense, yes, but in a practical sense, probably not. It does hurt the author though, and since we know
Re: Question about GPL with exception
To OSI License Discussion subscribers, From: Arnaud Quette [EMAIL PROTECTED], We (MGE UPS SYSTEMS) would like to release some code under GPL with exception (file header at the end of this mail), and we need to have confirmation about some points to do things cleanly and surely: 1) As the GPL is an OSI-approved license, is the GPL with MGE exception, that we proposed hereafter, an OSI approved license too ? Or do we have to get an OSI approval for it ? Normally, superficial changes (changing names, dates, etc) that do not affect the actual terms of the license and the way it works do not require a separate approval. This does not qualify as a superficial change in my book. However, you may wish to consult with someone from the OSI for a confirmation on this as I am not a representative of them. 2) Is the below header sufficient for inclusion in the distributed files, or do we need to attach a full GPL license file with those ? This is sufficient as per what the FSF states is required for the GPL (http://www.gnu.org/licenses/gpl-howto.html), provided that the full license is included in a plain-text document along with the distribution. 4) We also want to be sure that we can still extend this exception in the future, on the same released files, in example for allowing a partner to include this files in its proprietary program. Is this possible ? As it stands now, the text appears to grant MGE UPS SYSTEMS the ability to use the code in your proprietary softwares, including changes, without being subject to the terms and conditions of the GPL (whether this is actually the case or not is a question for a legal expert). Assuming this is correct, then anyone who is not MGE UPS SYSTEMS cannot do this, regardless of the circumstances, as they are not granted an exception. There are two ways around this issue: 1) Change the text to say MGE UPS SYSTEMS or its partners so that the exception applies to the parters of MGE UPS SYSTEMS, or 2) When releasing new versions of the software, update the license to grant the exception to additional entities. Anyone who disagrees will therefore not be accepting the terms of the license and will not get rights to redistribute, modify, or create derivative works of the software. Now, neither of these approaches violates the OSD as I understand it, but it is obviously against the spirit of open-source software. Further, authors that are a part of GNU or authors that advocate the GPL will not advocate your product, and will likely refuse to use or work on it, on the basis of your license changes and the fact that their changes could be used in proprietary products. You may wish to consider this. I have not answered your question 3) as I would not be comfortable in giving you any advice on that issue, not being a legal expert. Cheers, Nathan. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: discuss: No Warranty License.
To Justin Chen-Wells, From: Nathan Kelley [EMAIL PROTECTED], From: Justin Chen-Wells [EMAIL PROTECTED], This violates Item 5 of the OSD, which states that The license must not discriminate against any person or group of persons.. By not granting equal rights to users, distributors and open-source developers based on factors beyond their clear control (the laws of their jurisdiction), they are being discriminated against. This also violates Item 7 of the OSD, which states that The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.. Users, distributors and open source developers in affected jurisdictions cannot exercise the rights they are guaranteed under the OSD for OSD-compliant licenses without obtaining additional permission (license) from the author. You have said that this No Warranty License fails to comply because it discriminates against people in a particular jurisdiction. Your reasoning was that the laws of that region are beyond the control of its inhabitants (questionable) and therefore preventing use of the software under a particular legislative regime amounts to discrimination against a group. No, the laws are beyond their clear control, meaning that there isn't a clear path down which they could cause changes to the law to occur for the purposes of this license. Only a few people will be in a position with such a path. Will those be the end users of software with this license? Who knows? There's some merit in that, as for example we wouldn't want to accept a license which said the software could not be used, or could only be used, in a democracy. On the other hand supposing some government passes a law: No citizen shall accept a software license which requires publishing the source code of a derivative work. Would we then declare that the GPL is not OSD because it discriminates against people in that legislative jurisdiction? No, we wouldn't. But there is a difference between your scenario and that of the No Warranty License: your scenario says the user can't accept the license because their jurisdiction say they can't, whereas the No Warranty License says the user CAN accept the license, but they don't get any of the OSD-guaranteed rights if their jurisdiction doesn't allow limited liability. The former is a jurisdiction effectively imposing a ban on Open Source licenses as far as the OSD is concerned; the latter is a license effectively imposing a ban on jurisdictions as far as No Limited Liability goes. Only the latter is within our ability to prevent. I say that we should, on the basis of the violations of Item 5 and Item 7 that I identified. In and of itself I don't think we want to reject a license merely because of an incompatibility between a license and a law that results in the inability of people subject to that law to accept that license. I agree wholeheartedly, but that is not the case with this license. Cheers, Nathan. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Approval Requested for AFL 1.2 and OSL 1.1
To OSI License Discussion subscribers, From: Mahesh T Pai [EMAIL PROTECTED], From: Lawrence E. Rosen [EMAIL PROTECTED], Almost every country specifies that suits for damages should be brought at the place of residence / business of the defendant. You can rarely contract out of that. That is exactly what I want to contract out of, and I can in many jurisdictions. Licensors shouldn't be burdened by having to go to courts all over the world where their licensees happen to be. Licensees have the choice of licensors, not the other way around, in open source software situations. My question is, have those clauses that specify the jurisdiction in which all legal matters are handled for a particular package ever been upheld? Have they ever needed to be? Once again we come back to the value of case law. Cheers, Nathan. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Approval Request: RPSL 1.0
To OSI License Discussion subscribers, From: Rob Lanphier [EMAIL PROTECTED], Here is a link to the RealNetworks Public Source License (RPSL): http://www.helixcommunity.org/content/rpsl We'd like to submit this for consideration as an OSI-certified license. I have read the RealNetworks Public Source License 1.0. I believe that it meets the requirements of the OSD and falls within the boundaries of the spirit of Open Source. If acceptable to the board, this license can be certified as OSI-approved. You may want to proofread (ie. spell check) as there are still a few typos in there, but this is a minor issue. I think one of the main deterrents to reading the license is the fact that it is essay-length; excluding the exhibits, it is 4,143 words long. I know that it took me ~ 10 minutes to read, which by anyones' definition is not an insignificant amount of time. Certainly it is a lot to try and keep in mind at the same time. It is an indictment of the system that a license needs to be this long in order to forgo as many possible loopholes that can and would be abused. Cheers, Nathan. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: [OT] gstephan@assawompset.com
To OSI License Discussion subscribers, From: Nathan Kelley [EMAIL PROTECTED], Sorry to post an OT message, but I wanted to know if other subscribers that post here get a return message from the Assawompset mail system something like this (headers appear to be legitimate): - The addresse had permanent fatal errors - User unknown! Please verify the address and try again. --- SysAdmin Assawompset.Com If so, I'll ask the OpenSource.org postmaster to ask the list owner (if different) to remove the address. I've received a number of replies indicating others are seeing this too, and have sent an e-mail to the OpenSource.org postmaster asking for the list maintainer to remove the address. Cheers, Nathan. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Copyright
To OSI License Discussion subscribers, From: Graham Bassett [EMAIL PROTECTED], There is authority to show that, at least by analogy, equity could allow such specific performance. Multiple developers could be joined in an action or the open community or communities who have overseen the development could effectively represent the interests of such distributed developers. Critically, the organiser of such a community may be seen to have a fiduciary duty to their members as Bulun Bulun was seen to have to his tribe when he coded the dreams of the Ganalbingu people in an artistic fashion. (John Bulun Bulun v R T Textiles Pty Ltd [1998] 1082 FCA per Doussa J [www.austlii.edu.au] 23/08/01): The conclusion that in all the circumstances Bulun Bulun owes fiduciary obligations to the Ganalbingu people does not treat the law and custom of the Ganalbingu people as part of the Australian legal system. Rather, it treats the law and custom of the Ganalbingu people as part of the factual matrix which characterises the relationship as one of mutual trust and confidence. It is that relationship which the Australian legal system recognises as giving rise to the fiduciary relationship, and to the obligations which arise out of it. Aren't code writers the interpreters of our dreams in the digital world? The leader of the community could be the equitable owner of the copyright in the code made by the collective. The organiser's fiduciary role would then be to seek specific performance of any breach for, and on behalf of, the community who have given him or her their trust and confidence as part of the factual matrix in the development of the code. Graham, you make a very good point. Indeed, there is an increasing need to establish liability using measures other than money. I suspect that such measures will be codified in response to the proliferation of no-fee services, though, rather than Open Source software. However, while such measures could be used by Open Source authors to seek redress against proprietary vendors such as you suggest, it could also come back to haunt if a large user of Open Source packages decides to sue, or otherwise go after, their author(s). Admittedly there would be no reason for them to do so, but the possibility can't be discounted. BTW, hello from a fellow Australian :-) Cheers, Nathan. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: a proposed change to the OSD
To OSI License Discussion subscribers, From: Russell Nelson [EMAIL PROTECTED], I'm going to propose a change the Open Source Definition at our board meeting next Thursday. It is simply this: 0) A license may not restrict use or modification of a lawfully obtained copy of a work. Anybody have problems with this? Does this have any problems? We need to clarify to what extent this goes. If this is simply stating that an OSI-certified license must allow people to use and modify copies of Open Source works they have received lawfully, then it won't make a large difference to the existing license landscape, since no-one here that I know of would give props to a license that contained such restrictions. If, however, this clause goes further into saying that no conditions can be imposed on the use or modification of copies of Open Source works that people have received lawfully, then we have to contend with a number of license invalidations (by this I mean licenses no longer being OSD-compliant). As has already been noted, the GPL and LGPL licenses, which are perhaps the most widely-used of all, could be invalidated by this. Perhaps adding the term 'reasonable' to the clause would help. However, this means that, in addition to evaluating the terms of submitted licenses and their implications, we would also have to evaluate the intended application of those licenses. I doubt that we could agree on whether or not that falls within the purview of this list. We are back at the familiar crossroads, where one path leads to the moral high ground, and the other leads to practical feasibility. Until this issue is clarified, we won't know which path to take, but I suspect the latter is the well-beaten one. Cheers, Nathan. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
[OT] gstephan@assawompset.com
To OSI License Discussion subscribers, Sorry to post an OT message, but I wanted to know if other subscribers that post here get a return message from the Assawompset mail system something like this (headers appear to be legitimate): - The addresse had permanent fatal errors - User unknown! Please verify the address and try again. --- SysAdmin Assawompset.Com If so, I'll ask the OpenSource.org postmaster to ask the list owner (if different) to remove the address. Cheers, Nathan. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Simplified Artistic License [osd]
To OSI License Discussion subscribers, From: Robert Samuel White [EMAIL PROTECTED], From: Karsten M. Self [EMAIL PROTECTED], Larry, I can't afford an attorney, as you already know. And I cannot use one of the existing licenses because it does not feel right to me to do so. These are constraints imposed by you. You're welcome to live with the consequences. Don't ask the rest of us to be particularly concerned. I'd strongly suggest relaxing one or more of your constraints. Why? I agree with the point about consulting a legal professional; this is something important to do to ensure that a license is legally worth the bytes its' transmitted on. However, like Apple, IBM, and Sun, Robert has his own reasons for wanting to create a new license rather than use an existing one. What's good for big business has to be good for small business and even individual developers, otherwise we all look like hypocrites when we turn down licenses on the basis of No Discrimination. Yes, we don't need every single developer dreaming up their own license. Most won't go to the trouble unless they really need a new license, and where they have we've been able to call their attention to a suitable alternative that they have then adopted. Robert has cited legitimate reasons why he needs a new license... ...for the original Modified Artistic (eCAS) License: My license is loosely based upon the Artistic License and the PHP License http://www.php.net/license/3_0.txt. The Artistic License is most suitable to my wishes because I wish to maintain some semblance of artistic control over the package while giving the users of the package the right to use and distribute the package in a more-or-less customary fashion, plus the right to make reasonable modifications. The Artistic License does not suffice because (A) I find it to be written in a very complicated fashion (I don't even understand some of the language contained within it); (B) it was largely designed for Perl and C programmers and my package is written entirely in PHP; and (C) it contains too many conditions that I do not feel are necessary. ...for the new Simplified Artistic License, created in response to the resistance to approving the license despite the license being OSD compliant, and promises to the author that it would happen: I believe that there is a need for it, for several reasons: (1) the Artistic License has some archaic conditions within it, (2) it has too many restrictions that are unnecessary to modern day development, (3) it was designed for developers of Perl and artists develop in many different languages. So far, the points behind the need for either of these licenses have not been answered by anyone citing a similar suitable license (only the AFL has been suggested, and Larry Rosen's post on that shows why it is unsuitable); instead, we've helped him adjust his licenses to become OSD compliant, and have then complained that him making these adjustments has formed a moving target, and when accepted as OSD compliant rejected his license anyway on the grounds that he's not an open-source Who's Who personality. Huh? The sense that you _are_ committed is in that your license sets the tone for expectations of others. If you license under a particular set of terms, then change your mind down the road -- whether this is toward more or less liberal terms -- you will almost certainly receive much and harsh criticism. There are a number of examples of sole authors of code who've had licensing terms of their own authorship, who've created significant downstream issues for users of their software by either changing terms or interpretation of their license. That's why OSI certification is important; an OSI-certified license may not be compatible with all other OSI-certified licenses, but the fact that it is OSI-certified gives you an immediate idea of what to expect, and what options you know the license gives you. Everyone here would be rightly suspicious of a license that wasn't OSI-certified that claimed to be open source, and rightly so. If an author is silly enough to then significantly change the terms of their license, then that's their own lookout; it's not our problem. So far, the terms of either license has not changed in any significant way during the approval process... Both end-users and developers should be extremely averse to new licenses, particularly those which emerge from sources or organizations which have little prior visibility or track record. Terms of the major software licenses are well established, well understood, and would seem to be largely stable due to institutional pressures. While the licenses may not be ideal for all uses, they are good enough for many uses, and a reasonable compromise of interests. This is the discriminatory approach I was lamenting above. We can't take a one-size-fits-all approach to license
Re: Simplified Artistic License
To OSI License Discussion subscribers and Robert Samuel White, I have read the Simplified Artistic License. Robert, it mostly complies with the OSD, although I would look into three additional, minor points: (1) The license should define Derived in the Definitions. (2) The license should indicate that derivatives can be distributed under the same terms as this original license (to clarify the license against Item 3 of the Definition). (3) The license should require that, when doing binary distributions, referencing how/where to get the source code in addition to the fact that changes have been made and by whom (to clarify against Item 2 of the Definition). Once those items have been cleared up, I would be willing to call it OSD-compliant (even if it did not become certified). Also, in response to the following discussion... From: Robert Samuel White [EMAIL PROTECTED], From: David Johnson [EMAIL PROTECTED], - You may not charge any fees for the Package itself. However, you may distribute this Package in aggregate with other (possibly commercial) programs as part of a larger (possibly commercial) software distribution provided that you do not advertise this Package as a product of your own. This has been commented on before, but I'm bringing it up again. The no fees clause in the AL is a no-op, is because it allows charging of fees for distribution and media. Your license does not. In the real world we live in, charging for the package itself is equivalent to charging a license fee, so it's not a huge deal that the AL denies it. But without the ability to charge for media or distribution services, your clause does indeed violate the OSD because it becomes impossible to sell the software without first aggregating it with other software. (I'm hoping my wording makes sense to others besides myself...) David, note Item 1 of the Definition: 1. Free Redistribution The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale. Regardless of how we interpret this item, what it _actually_ says is that you can't stop anyone from aggregating the software with other packages and then selling the medium on which those packages are aggregated for a profit; it does not cover at all the selling the software when it has not been aggregated. So in this context, Robert's license actually conforms to the OSD. Now, if the intent of the OSD was to say that you can't restrict anyone from selling or giving away the package, regardless of the circumstances, then the OSD needs to be changed, because that is definitely _not_ what it says right now. Cheers, Nathan. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: discuss: OCLC Office of Research Open Source License
To OSI License Discussion subscribers, From: Russell Nelson [EMAIL PROTECTED], [ Please discuss this license. -russ ] Dears Sirs, We are submitting the OCLC Office of Research Public License 2.0 as a candidate for OSI Certification. Feel free to post the license to the license-discuss list. Let me know if I can assist in anyway. Thank you. Thomas L. Terrall Software Engineer I have read the Online Computer Library Center Office of Research Public License 2.0. Aside from the issues already raised by other subscribers, this license appears to be OSD-compliant. If those other issues are clarified, I would agree with this license being added to the OSI vault of Approved Licenses. Cheers, Nathan. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: discuss: Update for Submitted License
To OSI License Discussion Subscribers, From: Stefan Wachter [EMAIL PROTECTED], (Note: I've removed the HTML tags and cleaned up the layout since there was no HTML-encoded version of the original message. I have left the entire license intact in case you want to use the plan-text version.) Preamble The intent of this document is to state the conditions under which JBind may be used, modified, and copied. The conditions state that the Copyright Holder maintains some semblance of artistic control over JBind and require that the Copyright Holder receives a modest attribution in case that JBind is used in a commercial environment. Since the license text doesn't prohibit changes to the license text itself by third-parties, I will assume standard copyright rules apply to the license text as an original work. The above text violates Item 8 of the Definition, since there is no way for third-parties to use the license without the package it refers to being part of JBind: 8. License Must Not Be Specific to a Product The rights attached to the program must not depend on the program's being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution. Definitions: - Package refers to the collection of files distributed by the Copyright Holder. - Modified Package refers to a collection a files that was created through textual modification of and additions to the Package. - You is you, if you're thinking about using, modifying, or distributing this Package. - Reasonable copying fee is whatever you can justify on the basis of media cost, duplication charges, time of people involved, and so on. (You will not be required to justify it to the Copyright Holder, but only to the computing community at large as a market that must bear the fee.) - Freely Available means that no fee is charged for the item itself, though there may be fees involved in handling the item. It also means that recipients of the item may redistribute it under the same conditions they received it. The definitions you already have above are fine, however, a suggestion: You should add definitions to clarify the terms Commercial, Contributor, Non-Commercial and Use. Use, redistribution, and modification of the Package are allowed provided that the conditions below are met. 1. Redistributions of the Package or a Modified Package in source or in binary form must contain this license. The introductory sentence and Condition 1 above are fine. 2. You may use the Package or a Modified Package in any non-commercial project without limitations. This indirectly violates Item 6 of the Definition: 6. No Discrimination Against Fields of Endeavor The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research. I say indirectly because the text of condition 2 doesn't actually impose any limitations on commercial use; all it says is there are none on non-commercial use. However, by its' presence and by the fact that it explicitly does not mention commercial use, it indicates that there are limitations on commercial use that are not quashed later in the license, which is discriminatory. Note that condition 2 does not violate Item 1 of the Definition since it does not refer to re-distribution, only use. 3. You may use the Package or a Modified Package in any non-commercial product (probably another open source development) only if this license is distributed with the non-commercial product. In the case of both Source and Binary distributions, this indirectly violates Item 6 of the Definition for the same reasons as above. Note that this condition introduces the same sorts of 'viral effects' that the GNU GPL is renown for when it comes to source code, but is otherwise fine For Binary distributions, this condition may or may not also violate Item 9 of the Definition, depending on the circumstances in which a binary package distributed under this license and another package distributed under a different license interact: 9. The License Must Not Restrict Other Software The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software. Note that condition 3 does not violate Item 1 of the Definition since it does not refer to re-distribution, only use. 4. You may use the Package, a Modified Package, or a non-commercial product that contains the Package or a Modified Package in a commercial
Correction (was: Re: discuss: Update for Submitted License)
To OSI License Discussion subscribers, From: Stefan Wachter [EMAIL PROTECTED], From: Nathan Kelley [EMAIL PROTECTED], 4. You may use the Package, a Modified Package, or a non-commercial product that contains the Package or a Modified Package in a commercial environment, e.g. a commercial product, a commercial project, or inside a company only with the written permission of the Copyright Holder. Normally this permission is granted after a modest attribution to the Copyright Holder. This condition directly violates Item 6 of the Definition, since it discriminates against commercial use. In addition, it violates Item 7 of the Definition, since any third-parties that receive a re-distributed version of software under this license need to attain additional permission (license) from the Copyright Holder, even though the original license is not between the Copyright Holder and themselves: 7. Distribution of License The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties. I left out the word 'commercial' in the second sentence of that first paragraph. It should read: In addition, it violates Item 7 of the Definition, since any commercial third-parties that receive a re-distributed version of software under this license need to attain additional permission (license) from the Copyright Holder, even though the original license is not between the Copyright Holder and themselves: Sorry for the confusion. Cheers, Nathan. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: discuss: Modified Artistic License (eNetwizard Content Application Server)
To OSI License Discussion subscribers, From: Robert Samuel White [EMAIL PROTECTED], I have updated the license to avoid the misunderstanding of the condition mentioned by Nathan Kelly. Before: You may not charge any fees for the Package itself. After: You may not charge any fees for the Package itself. However, you may distribute this Package in aggregate with other (possibly commercial) programs as part of a larger (possibly commercial) software distribution provided that you do not advertise this Package as a product of your own. This was borrowed from the Artistic License. I did not include the first two sentences from that license, which said: You may charge a reasonable copying fee for any distribution of this Package. You may charge any fee you choose for support of this Package. Why? Because this could be only two scenarios in which some one might be able to justify a cost in relationship to the Package. Who am I to say what other possibilities may exist? Quoting those two sentences implies a restriction to only those two scenarios. Leaving them out leaves all possibilities open, as long as they do not charge a fee for the Package itself. If you feel the other two sentences are important, please let me know and I will add them, but personally, I tried to design this license to be as open as possible without adding wording that might add unnecessary restriction. This was, in fact, if you read my original post, one of the reasons I wanted to write my own license to begin with. That's fair, but that single sentence in the original license made it at best unclear whether the software could be distributed with other packages in a commercial way. My interpretation was that it didn't, and thus violated item 1 of the definition. The addition of those other sentences makes it clear that it can be, as long as it is not advertised as being part of the fee being charged for the medium on which the packages are being distributed. This is consistent with the requirements of item 1, and with that change, the license is now, is believe, OSD compliant. Cheers, Nathan. Nathan Kelley | [EMAIL PROTECTED] | [EMAIL PROTECTED] -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: variable notification display req.'s
To OSI License Discussion [EMAIL PROTECTED] subscribers, From: Max Privus [EMAIL PROTECTED], Let's say that the copyright display had to appear above any other windows on the screen for 1/10th of a second per the cumulative number of copies distributed by the licensee. Under this formula someone redistributing 100 copies of the software would need to display the copyright for 10 seconds while another party distributing 10,000 copies would have to display the notice for 1000 seconds. Obviously the display requirement becomes onerous past a few hundred copies. The intent here is to inspire high-volume redistributors of the software to adopt a modified , 'commercial' , version of the license and thereby assist in funding the project's development community. * you can assume that all other tenets of the license are OSD compliant. Would this formula constitute a violation of article 7 of the OSD ? 7. Distribution of License The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties. That's a good question. In a strictly technical sense, no; the rights attached to the program would apply to everyone, and there is no requirement to execute an additional license. However, requiring the notice to be displayed for 16 minutes, 40 seconds for the distributor of 10,000 copies would be regarded as unreasonable. The intent of the formula is punitive. Those judging your license for acceptance into the OSI vault would most certainly see that. ..or for that matter would it violate the intent of article 5 ? 5. No Discrimination Against Persons or Groups The license must not discriminate against any person or group of persons. could high volume redistributors be construed as a 'group' ? No. This item, like others in the definition, are about protecting the openness of open source. If, as you say, all other tenets meet the standards of the definition, then the formula wouldn't be a problem; it doesn't prevent high-volume redistributors from exercising their 'open' rights under the license. Cheers, Nathan. Nathan Kelley | [EMAIL PROTECTED] | [EMAIL PROTECTED] -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: discuss: Modified Artistic License (eNetwizard Content Application Server)
To OSI License Discussion [EMAIL PROTECTED] subscribers, From: Robert Samuel White [EMAIL PROTECTED], http://enetwizard.sourceforge.net/license.html Your reasoning behind using this license is quite good. The license is both fair and equitable, and is compliant with the Open Source Definition except for this one point: - You may not charge any fees for the Package itself. This violates item 1 of the Definition: 1. Free Redistribution The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale. If this were fixed, I would welcome this license into the list of Approved Licenses. Cheers, Nathan. Nathan Kelley | [EMAIL PROTECTED] | [EMAIL PROTECTED] -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Query on a P2P EULA
To Seth Johnson [EMAIL PROTECTED], From: David McNab [EMAIL PROTECTED], From: Seth Johnson [EMAIL PROTECTED], Can an open source EULA exclude certain parties and uses? No. As per the definition (http://www.opensource.org/docs/definition.php): 5. No Discrimination Against Persons or Groups The license must not discriminate against any person or group of persons. 6. No Discrimination Against Fields of Endeavor The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research. In order to cover myself against any legal action resulting from actions beyond my control, I've thought of a plan which might actually employ the DMCA to my protection: * Encrypt the source and binary tarballs * Provide a utility which can decrypt the tarballs, given the correct decryption key * Provide another utility which provides the decryption key, upon the user accepting a 'click-wrap' EULA At least your e-mail address appears to be based in New Zealand. Does your use of the DMCA mean the product will be distributed under US law? * I agree to not disclose the existence of this software, its design, architecture, implementation or capabilities, to any company or organisation which acts or has ever acted as a plaintiff (or assisted any plaintiff) in intellectual property legal actions; such groups include Recording Industry Association of America, Motion Pictures Association of America, Business Software Alliance, Microsoft Corporation, Adobe Corporation, Macromedia Corporation etc. This would violate item 5 from the definition, and also be very difficult to enforce. * I will not distribute this software, in source or binary form, to any other party, unless it is packaged in this click-wrap agreement. If I make any modifications to the software, I agree to enclose with my modified version (and/or patches), a copy of the original unmodified source code, and a list of modifications made, and to package all of these in the click-wrap package with this agreement intact This sounds like it violates one of the items of the definition. I'm not sure which one though. My question is - would this scheme have any prospects of standing up in court? Could this prove effective in protecting me from personal liability from some people's usage of the software? If this comes back to the US, then I doubt it. Distributors of other P2P networking tools have had similar indemnification clauses in their licenses, but that hasn't saved them. I can't see you having more luck unless you can show that your software has and is being used for purposes aside from transfers of multimedia files. Cheers, Nathan. Nathan Kelley | [EMAIL PROTECTED] | [EMAIL PROTECTED] -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Approval request for BXAPL
To OSI License Discussion [EMAIL PROTECTED], From: Nathan Kelley [EMAIL PROTECTED], From: Abe Kornelis [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. 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 understand that innocent until proven guilty is a core tenet here. Unfortunately, patent law has always been designed so that the owners of the patents receive monies from those using them. While there isn't really anything wrong with the way item 16 is put together, I still see the fact that a well-worded petition to the judge would see it ruled unenforceable... at which point we get precedent, at which point item 16 becomes essentially useless for protecting open-source developers. Cheers, Nathan. Nathan Phyax Kelley email | [EMAIL PROTECTED], [EMAIL PROTECTED] icq | 4618849 yahoo | phyax -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Academic Free License
To OSI License Discussion [EMAIL PROTECTED] subscribers, From: Lawrence E. Rosen [EMAIL PROTECTED], I am submitting the accompanying Academic Free License for your review and for OSI approval. The online copy of the license is at http://www.rosenlaw.com/afl.html. I have read the Academic Free License v1.0 and have concluded that it meets the requirements for OSI certification. I also agree with the author's stated reasons regarding why this license as opposed to other existing all-permissive licenses. At a time when open source is becoming more common and more academic and commercial ventures are involving such, having properly structured licenses is essential to ensuring that open software stays open. Cheers, Nathan. Nathan Phyax Kelley email | [EMAIL PROTECTED], [EMAIL PROTECTED] icq | 4618849 yahoo | phyax -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: [discuss] License Approval Request: Macromedia Open Source License
To OSI License Discussion [EMAIL PROTECTED] subscribers, From: Tom Harwood [EMAIL PROTECTED], Macromedia, Inc., would like to obtain OSI certification for its Open Source License. The Macromedia Open Source License is based on the IBM Public License, with the following changes per our Legal department: (1) changed IBM to Macromedia, (2) clarify that if Macromedia includes its own open source in its products, Macromedia does not have to state in its documentation where the source code version of the open source material is made available, (3) clarify that Macromedia does not have to include its own copyright notice in the event Macromedia decides to incorporate its own open source materials in its commercial products, (4) require the inclusion of the copyright notice in documentation as well as the software, (5) changed the choice of law from New York to California. A specimen copy is available on our website: http://www.macromedia.com/v1/handlers/index.cfm?ID=23075 I have read the Macromedia Open Source License Agreement v1.0. I believe that it does not meet the requirements for OSI certification, as it conflicts with the Open Source Definition. Specifically: Item 3.IV in the license states that: ...other than in the event that such Contributor is Macromedia, (A) states that source code for the Program is available from such Contributor, and (B) informs licensees how to obtain it in a reasonable manner on or through a medium customarily used for software exchange. This conflicts with Open Source Definition, item 2, which states: ...Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost... The license terms absolve Macromedia from needing to fulfill this requirement in the event that Macromedia does not include the source code for a product with the product itself. If this exclusion were removed, I believe this would allow the license to qualify for OSI certification. A notice advising the availability of source code does not have to be in-your-face; it just can't be buried away. Placing it as a line stating Source code is available for this software upon request. See our site: with a URL into an about box or into a README file would, I believe, be acceptable. Could a subscriber on the list please confirm these points for me? Cheers, Nathan. Nathan Phyax Kelley email | [EMAIL PROTECTED], [EMAIL PROTECTED] icq | 4618849 yahoo | phyax -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Revised Version of Public Scripting License
To OSI License Discussion [EMAIL PROTECTED] subscribers, From: Joshua Colson [EMAIL PROTECTED], In response to David Johnson's concerns regarding the Public Scripting License, we have amended sections and added others, hopefully addressing many of the concerns which he had. The amended version may be found at: http://www.nuleo.org/psl-revised.html I have read the Public Scripting License v2. As it does not contravene in any way the 9 items in the Open Source Definition, I believe that it meets the requirements for OSI certification. Note to subscribers: This license is a strong copyleft, which has the same sort of 'viral effects' as the GNU General Public License. It is in that respect where the main differences are from the QPL. Cheers, Nathan. Nathan Phyax Kelley email | [EMAIL PROTECTED], [EMAIL PROTECTED] icq | 4618849 yahoo | phyax -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: [discuss] License Approval Request: Macromedia Open Source Li cense
To Tom Harwood [EMAIL PROTECTED], From: Tom Harwood [EMAIL PROTECTED], From: Tom Harwood [EMAIL PROTECTED], Thanks, everyone, for your comments. I am summarizing the discussion for Macromedia's Legal department and for the management, my understanding of the issues is: (1) changed IBM to Macromedia, (5) changed the choice of law from New York to California. These are known issues with the IBM Public License. In the short term, the best course of action is to use the Common Public License, which is also derived from the IBM license, with more vendor-neutral wording. Based on some comments, I understand that the community is also OK with a pseudo-templatized license that makes the substitutions described above. The Common Public License is essentially identical to the IBM Public License but with vendor-neutral wording AND an additional clause under item 7 that states the way in which the license can be modified. Using an existing license that does nothing other than change the names, jurisdictions, and similar points should not invalidate the licenses' OSI certification status. Unfortunately, I can't find any statements from the OSI board to this effect. As a member of the community, however, I have no objects to this approach at all. (2) clarify that if Macromedia includes its own open source in its products, Macromedia does not have to state in its documentation where the source code version of the open source material is made available, (3) clarify that Macromedia does not have to include its own copyright notice in the event Macromedia decides to incorporate its own open source materials in its commercial products, There is a business case that argues against these clauses. One of the principal reasons a corporation distributes open-source software is encourage a cooperative relationship with a large community of developers and end users [insert standard business case for open source]. These license terms discourage the formation of this cooperative relationship by asserting unequal rights for one partner. Specifically, unless and until others contribute to Macromedia's open source products, Macromedia retains copyright to all materials and is perfectly free to do whatever it likes with them; it is only when Macromedia wishes to take advantage of the work of other partners in this relationship that the quid pro quo comes into play: the corporation might acquire the copyright to the new work, and again be a free agent, or continue in the freely given, freely accepted mode. Alternatively, of course, the corporation might choose not to use this new work at all, and rely solely on the work of its own engineers. Item (2) is certainly a problem, and I have discussed this in another e-mail. Item (3) is not a problem, as the provisions of Item 3 in the Macromedia Open Source License Agreement v1.0 allow any Contributor, including Macromedia, to distribute the software under its' own license agreement, even if that software includes code others have contributed. Third-parties are not being denied any specific rights that Macromedia has under that Item, provided they contribute to the software. In addition, since Macromedia owns the code it produces, it is perfectly free to make that code available under this license and under a different license simultaneously. This practice is already semi-common within the open source and free software communities. If the license is OSI certified, it should in no way discourage a co-operative relationship with said community of developers and end-users. A license that asserts unequal rights for the originator would normally not be able to gain OSI certification. (4) require the inclusion of the copyright notice in documentation as well as the software, There is concern the term documentation is loose enough to cause these license terms to bleed onto works that Macromedia is in no way associated with. Unfortunately, this list's archive doesn't seem to be searchable, so I have made up an example: One of the products Macromedia may open source is BURG (a tool that generates compiler back ends). If an independent party created a compiler using this back end, and wrote a book about this compiler -- never having modified Macromedia's code in any way, having only used it to generate part of this hypothetical compiler -- then one might argue that the book must include Macromedia's license terms. This would depend if the complier back-end includes code that is copyright to Macromedia and licensed under this license. The output from a program wouldn't normally be covered by the same license as the program itself. If the output is covered by the same license, and the book in question included the source in printed form, then I would imagine that book is effectively distributing the source code, and the copyright + license would need to be included. This is
