Re: namespace protection compatible with the OSD?
e to think. It doesn't limit the right to fork at all, but it does somewhat carve out an API namespace; the example of MS using something like this to prevent Win32 reimplementation is probably a good example, where they'd put a license like this on their Win32 spec. This doesn't seem to be at all the same thing. Nobody has to execute a license of Microsoft's in order to implement the same API's as Windows, unless doing so involved creating a derivative work of some copyrighted material. That's precisely what I'm saying. What's the copyright on the documentation for the Win32 API as provided by MS? What you're proposing sounds like it could be accomplished using trademark, and avoiding that whole sticky copyright-of-API's issue altogether. Notice that what repels you about my proposal would still be possible in that case, e.g., MS suing Wine developers for trademark violation. At least with the proposed copyright, your right to implement compatible implementations would still survive. Brian -- Frank LaMonica VA Linux Systems Inc. [EMAIL PROTECTED] (512) 378-3003(512) 378-3004 fax begin:vcard n:LaMonica;Frank tel;fax:1 (512) 378-3004 tel;home:1 (512) 378-3003 tel;work:1 (512) 378-3003 x-mozilla-html:FALSE org:VA Linux Systems Inc.;Professional Services adr:;;114 South Prize Oaks Dr.;Cedar Park;TX;78613;USA version:2.1 email;internet:[EMAIL PROTECTED] x-mozilla-cpt:;26656 fn:Frank LaMonica end:vcard
Re: OpenLDAP license
Dave J Woolley wrote: From: Frank LaMonica [SMTP:[EMAIL PROTECTED]] I agree with you completely. BSD is one of the only software licenses that allows PEOPLE the freedom they need to establish their own business objectives. I would go even further to say that there are only three [DJW:] There are different balances. BSD favours businesses that use the software but means that the original author may not benefit as much. Open source is most likely to happen when both parties gain a benefit. Dave, The original author will never lose the ability to benefit from his or her own work. Under BSD, they may not directly benefit from additive work by other people, but that should not be the point of the initial release. BSD software is released to fulfill a need where something is lacking. The open source software is not intended to generate any revenue directly, but, if it is useful in some commercial setting, then it can be used to generate revenue there. That is a good thing! Keep in mind that if the value of the software that is opened derives from the fact that it IS open, i.e., it fills a void in an otherwise freely available, royalty free pipeline, then it will have given its full benefit to all parties. I contend that the only necessary and sufficient areas of software that derive their value from the fact that they are open source lie in the data formats, API's and OS infrastructure. Other software, that is not a part of those three areas, may have value from being open source, but it is not NECESSARY in order to maintain the most beneficial use of open source technology. On the other hand, anything that closes up any part of those three areas creates an environment that is not SUFFICIENT to maintain the benefits of open source to the industry. Regards, Frank -- --- DISCLAIMER - Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of BTS. -- Frank LaMonica VA Linux Systems Inc. [EMAIL PROTECTED] (512) 378-3003(512) 378-3004 fax begin:vcard n:LaMonica;Frank tel;fax:1 (512) 378-3004 tel;home:1 (512) 378-3003 tel;work:1 (512) 378-3003 x-mozilla-html:FALSE org:VA Linux Systems Inc.;Professional Services adr:;;114 South Prize Oaks Dr.;Cedar Park;TX;78613;USA version:2.1 email;internet:[EMAIL PROTECTED] x-mozilla-cpt:;26656 fn:Frank LaMonica end:vcard
Re: Open Software Side Effects
David, That's correct. There are many more factors that could exist, but I was trying to narrow the focus to those which are necessary and sufficient. Many people are confused, and even distanced, by open source rhetoric. The principal source of those reactions lie in our failure to understand and promote the aspects of open source which will bring success to the computer industry in OUR society. Why, where, and how will business benefit from open source more than it would from proprietary software? My contention is that open API's, data formats, and OS infrastructure are the ONLY aspects of open source that are both necessary and sufficient to generate the most possible benefit to business in our society. Licensing issues come into play because that is the legal mechanism we use to define and control the use of our open source resources. The BSD license does nothing to force PEOPLE to do anything. It merely maintains the open source availability of any piece of software which anyone has chosen to license under its terms. If people understand that the true economic value of a piece of software inures from its open source nature, then that software will continue to fulfill its role as an open conduit of other IP that can be used to generate the profits a business in OUR society requires in order to survive. The better we educate the industry on these issues, the more likely it will be to reject any software that attempts to secure some competitive advantage by closing up the API's, data formats, or OS infrastructure. Companies who are funding the development of critical open source software understand the importance of freely accessible, royalty free avenues which encourage innovation and competition. I believe that our challenge is to educate the industry in order to thwart all attempts to secure a proprietary foothold into what must remain an open pipeline. I don't believe a license which attempts to control the use of the software will do the job. People will do it once they understand it is in their best business interest to do so. Regards, Frank David Johnson wrote: Switching topic titles... On Sunday April 15 2001 09:29 pm, Karsten M. Self wrote: This goes beyond the legal issues of free software, but my own list of factors is slightly more extensive: 1. Development methodology... 2. A software architecture... 4. An economic model... 6. Open standards... Since Frank's post was trying to list the necessary and sufficient factors for Open Source, it seemed as if you were trying to do the same. I would not characterize the above points as necessary attributes of Open Source. Rather, they are common side effects of Open Source. You could certainly have projects that are open but which don't have the above attributes, and you could have closed source projects that do. Of course, projects that don't have the above factors would have a higher "forkability" attribute... -- David Johnson ___ http://www.usermode.org -- Frank LaMonica VA Linux Systems Inc. [EMAIL PROTECTED] (512) 378-3003(512) 378-3004 fax begin:vcard n:LaMonica;Frank tel;fax:1 (512) 378-3004 tel;home:1 (512) 378-3003 tel;work:1 (512) 378-3003 x-mozilla-html:FALSE org:VA Linux Systems Inc.;Professional Services adr:;;114 South Prize Oaks Dr.;Cedar Park;TX;78613;USA version:2.1 email;internet:[EMAIL PROTECTED] x-mozilla-cpt:;26656 fn:Frank LaMonica end:vcard
Re: IPL as a burden
Gregor, I like the terminology you used: "source included software (SIS)". SIS would be much better than a closed source, proprietary alternative, but I don't see any incentive for open source programmers to contribute to such a program. If a company went out of business or ceased to produce the application, SIS would at least provide an option to people so they could recover their investment in data which was created by the application. A better protection along those lines would be a totally free, open, and fully documented data format. Of course, that would require work on the part of the application vendor, work which they may believe they have no financial incentive to produce. I would argue that their incentive to produce such a set of documentation is larger than that which could exist for an open source developer to contribute to a SIS program. It could cause their application to become the defacto standard for that class of applications, and it would be a strong incentive to use in a sales situation where potential customers are concerned about protecting future access to their data. It would not be "open source" by any of the accepted definitions, but it would have a lot more value than proprietary alternatives. Frank Gregor Hoffleit wrote: On Tue, Jan 16, 2001 at 06:54:22PM +0100, Manfred Schmid wrote: It is indeed interesting that GPL does not address the matter ofrunning a GPLed program. From a legal standpoint it might be interesting, if the OSD is an inegral part of GPL or not. From a non-legal standpoint I would argue that OSD #7 covers that matter. By no way the OSD is an integral part of the GPL (the GPL was there long before the OSD came into existance). Well, the GPL says this: "Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does." and "6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License." I.e. the GPL doesn't restrict the act of running the program, and if somebody else redistributes the program, he can't impose any restrictions on running the program either. I think the GPL is quite explicit at this point. In fact, I have to say it once again: Contrary to its name, OSD is a set of guidelines, but not a strict definition of what makes up Open Source software. Take all the reactions from the crowd here, and you will see that the unrestricted right to run a program is inherent to the concept of Open Source software. What you're suggesting is a different concept, something like "source-included" software. Maybe that's a third way (fifth, seventh ?) and maybe it's viable, but please don't try to suggest that you're running inside the concept of Open Source software. Gregor begin:vcard n:LaMonica;Frank tel;fax:1 (512) 378-3004 tel;home:1 (512) 378-3003 tel;work:1 (512) 378-3003 x-mozilla-html:FALSE org:VA Linux Systems Inc.;Marketing adr:;;114 South Prize Oaks Dr.;Cedar Park;TX;78613;USA version:2.1 email;internet:[EMAIL PROTECTED] title:Strategic Director of Multi-Media x-mozilla-cpt:;-1184 fn:Frank LaMonica end:vcard
Re: IPL as a burden
Andrew J Bromage wrote: G'day all. On Wed, Jan 17, 2001 at 10:17:41AM -0800, Frank LaMonica wrote: I like the terminology you used: "source included software (SIS)". SIS would be much better than a closed source, proprietary alternative, but I don't see any incentive for open source programmers to contribute to such a program. As I understand it, interDAT will be offering them money. Cheers, Andrew Bromage Andrew, Please clarify or expand on that statement. Regards, Frank begin:vcard n:LaMonica;Frank tel;fax:1 (512) 378-3004 tel;home:1 (512) 378-3003 tel;work:1 (512) 378-3003 x-mozilla-html:FALSE org:VA Linux Systems Inc.;Marketing adr:;;114 South Prize Oaks Dr.;Cedar Park;TX;78613;USA version:2.1 email;internet:[EMAIL PROTECTED] title:Strategic Director of Multi-Media x-mozilla-cpt:;-1184 fn:Frank LaMonica end:vcard
Re: Request for approval: IPL 1.0
Ralf,
There are many entities who release what they claim are "OpenSource" licenses,
but differ from the GPL or LGPL. Each such license places additional burdens on
the entire open source community. Those burdens devolve from the inevitable
interactions between software licensed under various licensing terms. In the
case of your proposed "IPL" license, there are even more serious concerns. It
appears that many sections of the license were not written by either a native
English language speaker, or someone with any training or experience in U.S. law.
Incorrect use of grammar, tense, and terminology which carries specific legal
meaning in U.S. law, will create a nightmare for anyone who tries to interpret the
intention of your document.
If you really feel that you need a new license, and you feel that the text must be
in English, I suggest you work with a good U.S. lawyer.
Regards,
Frank
Ralf Schwoebel wrote:
Hi Everybody,
hereby we release our OpenSource license as announced in the last
Open magazine. We are sure that we fullfill the basics from the
http://www.opensource.org/osd.html
page, but we already got some feedback like:
"...there is no need for an additional license..."
from the german jurisdiction point of view, we totally disagree.
We kindly ask for serious comments.
--
best regards,
Ralf "puzzler" Schwoebel
CEO, intraDAT international inc.
11250 Roger Bacon Drive (#3)
Reston, VA 20190
Tel.: 703 796
** snip
intraDAT Public License
Version 1.0.0
---
Please read this Agreement carefully before using, copying, modifying or
distributing the intraDAT Public License Code ("IPL Code"). It will only
be
licensed to you if you first accept the terms of this Agreement. By
using,
copying, modifying or distributing the IPL Code, you indicate your
acceptance
of this license and all its terms and conditions for the IPL Code or
works based
on it. Nothing other than this license grants you permission to use,
copy,
modify or distribute the IPL Code or its derivative works. If you do not
agree
to the terms of this Agreement, promptly notify the provider of the IPL
Code
and delete the IPL Code and all copies of the IPL Code immediately from
any of
your storage media. You are not allowed to separate or to modify this
License
from the IPL Code.
Note: This license is not identical to any of the GNU Licenses published
by
the Free Software Foundation. Its terms are substantially different from
those
of the GNU Licenses.
Copyright of this Text: intraDAT, Wilhelm-Leuschner-Strae 9-11, 60329
Frankfurt am Main, Germany and Alexander Eichler, Graf von Westphalen
Fritze
Modest, Marsstrae 33, 80335 Mnchen
1. Definition
1.1. "Distribution" means to copy the IPL Code in part or total for or
to one
or several third parties. This includes both the active copying (e.g. in
form
of a transmission) as well as to place the IPL Code in part or total at
the
disposal of third parties (e.g. ftp server or CD-Rom).
1.2. "Distributor" means somebody who distributes, different from
intraDAT.
1.3. "Documentation" means the documentation given in electronic or
paper form
for users and/or developers. Documentation will be provided in English
language.
There is no obligation for any other language, but parts of the
Documentation
might be given additionally in other languages.
1.4. "IPL Code" (intraDAT Public License Code) means the Software as
licensed
by intraDAT under these clauses in form of source and/or object code.
User will
find the exact definition of "IPL Code" in form of program names and
version
numbers on www.intradat.com.
1.5. "Source Code": The source code for a work means the preferred form
of the
work for making modifications to it. For an executable work, complete
source
code means all the source code for all modules it contains, plus any
associated
interface definition files, plus the scripts used to control compilation
and
installation of the executable code. However, the source code
distributed need
not include anything that is normally distributed (in either source or
binary
form) with the major components (compiler, kernel, and so on) of the
operating
system on which the executable runs, unless that component itself
accompanies
the executable code;
1.6. "User" means anyone who receives, uses or develops the IPL Code,
different
from intraDAT and anybody else acting in behalf of intraDAT.
1.7. "Modifications" means any changes made to IPL Code.
2. License
2.1. The IPL Code is copyrighted by intraDAT under national and
international
law.
2.2. For the IPL Code and Documentation intraDAT hereby grants you a
world-wide, non-exclusive license, subject to third party intellectual
property
claims:
(a) to use, reproduce, modify, display, and perform the IPL Code
and/or
Re: IPL as a burden
Ralf, I think you have misunderstood my comments. I have no problem with companies making money in an open source environment. My comments did not refer to money in any way, they were directed at the human element - i.e.,, time - that it takes to negotiate the interactions between all of the licenses used by players in our community when many pieces of software are used as components of larger projects. I also deliberately avoided stating my personal opinions regarding the use of the GPL, LGPL, or any open source license. For the record, I believe that only API's, data formats, and OS infrastructure code needs to be open source. Any time company A has to pay a toll to company B for the right to interact with company C, then there is a problem. That has nothing to do with the license discussion at hand, but is just in reply to your divergence to philosophy.Back to your IPL proposal. The license may be approved by some Washington law firm, and if you feel it is adequate, then it is obviously your decision. I just gave you my opinion - an opinion you solicited. If you were just looking for an endorsement of your proposed license, then I apologize for interfering. Regards, Frank Ralf Schwoebel wrote: Frank LaMonica wrote: but differ from the GPL or LGPL. Each such license places additional burdens on the entire open source community. Those burdens devolve from the inevitable Dear Frank, thanks for the input, but I have to disagree. The lack of the word money is the burden of the OpenSource community and even companies like VA or RedHat have to feel that these days. And the GPL comes from a time when students changed the world and coolness was a skill. Now we have 2001 and the idea of Open Source needs a kick, because we need applications now and everybody thinks its cooler to work on an operating system, not an application. We see no other possibility than enabling people to charge money for sources without violating the basics of OpenSource: Anyone is allowed to use the software, everybody has access to the sources, etc. pp. This money goes to the developers and they can pay their bills. And by the way: Our license is approved by a very good and accepted lawyer in Washington DC (some senators and HUGE software vendors agree to that) and is suitable for the Virginia law, since software licenses have to fit the state laws, not the federal law in the US. -- best regards, Ralf "puzzler" Schwoebel CEO, intraDAT international inc. 11250 Roger Bacon Drive (#3) Reston, VA 20190 Tel.: 703 796 begin:vcard n:LaMonica;Frank tel;fax:1 (512) 378-3004 tel;home:1 (512) 378-3003 tel;work:1 (512) 378-3003 x-mozilla-html:FALSE org:VA Linux Systems Inc.;Marketing adr:;;114 South Prize Oaks Dr.;Cedar Park;TX;78613;USA version:2.1 email;internet:[EMAIL PROTECTED] title:Strategic Director of Multi-Media x-mozilla-cpt:;-1184 fn:Frank LaMonica end:vcard
Re: IPL as a burden
Manfred, Most users of software don't consider the availability of source code in their purchasing decisions. Why? Because they are not in the business of writing software, they are simply using an application as a tool. I suspect that most of the people on this list do not fit into that category. They do care about the source code, and they are generally in a position to make good use of it to support whatever application they are using. Should a normal application user care about source code? I suggest that a published data format is much more important to a typical end user than is the availability of source code. As a matter of fact, if an application doesn't have a published data format then a prudent user should reject it completely, regardless of how well it does the job of creating data. An application is a program that manipulates data. The user of any application almost always cares more about the data created than they do about the program used to create that data. The reason why a normal user should care about the open source nature of the application they choose to use is because that guarantees them the protection they need for the data they create. One step below the application source code level of protection is the data format used within the application to encode and/or store that data. An application typically embeds a storage methodology into itself, which it uses to store and retrieve data. If an application vendor only publishes their data format, and doesn't provide the application source code, then a non technical user might actually have a better form of protection for their purposes - provided, of course, that the application vendor didn't lie about the format. In that scenario, if an application vendor ceased to provide a suitable application, the end user could find some way to retrieve the data and to then use another application to continue their work. If the data format were only visible by virtue of the source code, first - on the good side - it would prevent the application vendor from lying and it would be a strong guarantee of data protection to the user, but - on the down side - it would require that someone who wanted to continue working without the original application, have to take the time, and have the expertise, to reverse engineer the data format by examining the application source code in order to have another application built that would allow the user to continue working. If the data is very complex, and, especially if it is created incrementally at numerous places within the application source code, it could be a major undertaking to understand the full extent of the data formatting. Would you put your money into a bank that would not allow you to recover it if the bank went out of business? We have the FDIC to protect us in the financial world, but what would you do if your firm found another application that better suited its business needs, and there was no way to move your legacy data to the new system? Could you afford to, and would it even be possible to recreate that data? Open data formats would protect your investment. That also would greatly simplify the license issues. Do you need to have a complex license to protect data formats or API's? I suggest that information of that nature should be totally free and open, licensed with something as simple as the BSD (XFree86) style license. We should encourage open, standard data formats and API's. Companies who create their value by writing application which create and manipulate your data could then recover their investment by charging suitable fees for their application. There would be no business need to insist on open source applications unless the vendor has been proven guilty of past deception, such as things like having hidden API hooks in an OS to enable better performance of their own applications. Companies who are guilty of those type of practices should be punished by requiring all of their source code to be open, and all of their data formats to be accurately documented and published. Regards, Frank Manfred Schmid wrote: Hi Brian You seem to labor under a very strange idea. That idea is that open source developers are "not paid." Exactly where did this idea come from? Every open source developer i know is quite well compensated and generally gets paid a certain amount of their time to work exclusively on their open source projects of their choice. Any consulting group will set aside research and development costs to further their code base. This is one of the persistent myths that non open source companies have about the open source software movement ie the developers are largely college students who are not paid. All the open source developers I know are highly compensated professionals. Programming skills are rare and highly prized. I doubt very much that there are legions of unpaid starving programmers out there. The Open
Re: IPL as a burden
Andrew, You may be correct about saying people would require source if they knew more about it, however they have to care about it to some degree first before they will, in general, take the time to learn about the issues. If you read the rest of my posting, you would see that I continued on by saying the people on this list are exceptions - they do care about the source code. Unfortunately, we are the extreme minority. I go on to show how open data formats may be a lever which can be used to open the eyes of those users who sit fat, dumb, and happy using proprietary software that locks up their data in hidden formats. Once they have reached the realization that the protection of their own data, and their ability to freely access that data are two issues they should care about, we may be able to get them to care more about open source code. BTW, your analogy about a car is no longer valid. Almost all new cars are controlled by proprietary programs running in embedded processors that can only be accessed by very expensive equipment that is tightly controlled by the car company. The days of tuning your own car without a computer are over, we've lost the automobile war :( Frank Andrew J Bromage wrote: G'day all. On Mon, Jan 15, 2001 at 04:36:38PM -0800, Frank LaMonica wrote: Most users of software don't consider the availability of source code in their purchasing decisions. Why? Because they are not in the business of writing software, they are simply using an application as a tool. I think they might take the availability of source into account if they understood it better. When I buy a car, I don't care about tinkering with its innards because I am not a mechanic, and have no aptitude or desire to become one. However, I do insist that my car be servicable by any appropriately qualified mechanic that I nominate. That way, I'm not locked into paying the company I bought the car from every time it needs maintenance. With a car, that means many things including good engineering such as low coupling between independent systems (if I change the colour of the upholstery, that shouldn't make the headlights stop working) transparency (i.e. that the insides of the car are not hidden) and openness (anyone can produce service manuals, spare parts or even a clone of the whole car if they want to). And in the end, I should be able to modify the car to my hearts' content (maybe put in a different sound system, maybe put in a cargo barrier, maybe convert it to run on unleaded petrol or LPG) and sell it to someone else when I don't want it any more, and not have to get permission of the original car manufacturer to do any of these things. Naturally I would wait until the warranty expired (assuming the car came with a warranty) before doing anything not approved by the vendor, but it wouldn't be because the vendor forced me to. Would you buy a car that didn't let you do any of this whether you're a mechanic or otherwise? If I were not a programmer, I'd reason the same way about software. If my purchased software needs maintenance, I don't want to be at the mercy of the company I bought it from. I want to be able to hire any appropriately qualified programmer that I wish, or even do it myself if I think I know what I'm doing; after all, I'm not a mechanic but I can change a tyre with the best of them. I should be able to freely give details of my fixes/enhancements to others, and I should be able to resell the software when I'm finished with it. I should not have to get the original vendor's permission to do it. Would you buy software that didn't let you do any of this, whether you're a programmer or otherwise? This is not the full set of rights provided by Open Source, but if I were not a programmer, it's what I'd be looking for. Cheers, Andrew Bromage begin:vcard n:LaMonica;Frank tel;fax:1 (512) 378-3004 tel;home:1 (512) 378-3003 tel;work:1 (512) 378-3003 x-mozilla-html:FALSE org:VA Linux Systems Inc.;Marketing adr:;;114 South Prize Oaks Dr.;Cedar Park;TX;78613;USA version:2.1 email;internet:[EMAIL PROTECTED] title:Strategic Director of Multi-Media x-mozilla-cpt:;-1184 fn:Frank LaMonica end:vcard
