Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: namespace copyright, trademark patent question
 <bryan> > I was just thinking about the legal ramifications of namespaces as a way > to control interoperability. It seems to me that a vendor could, with > bad motives aplenty, decide to prohibit other companies via exorbitant > pricing/licensing from building tools that processed their namespace > with the same result as the namespace(or just profit from people > building such tools). </bryan> I believe it is possible to copyright and patent schema. I am not sure whether one could trademark a namespace. There is probably case law about trademarking domian names that is relevant, but I have not looked colsely at this issue. If one can copyright or patent a schema (or any other xml document), then one can also exclude/prevent others from using the schema (or any other xml document). This is not necesarily a bad thing. Indeed, it can be a very good thing. I agree with you, it could be used to control interoperability. Company A who owns schema A could simply exclude all others from writing software around Schema A. This would make interoperability with Schema A (and instances based on it) impossible. This is a bad thing for interoperability, but a for-profit company might reasonably decide to do this if it deemed this were in its best business interests. On the other hand, the ability to copyright and patent schema can be a very good thing for interoperability *if* coupled with an appropriate "general public license" (I'm using "general public license" in a generic sense). Copyright and patent rights are used as the basis for a general public license. The way it works is that a person or organization asserts intellectual property rights (copyright or patent) in software (in this case schema) and then grants a world-wide, royalty free, perpetual license to the public to use the software/schema, provided certain conditions are met. Conditions vary based on the license, but examples of typical conditions are (1) licensees must perpetuate the license and bind new users to it (2) modifications are either (a) prohibited (b) permitted without condition, or (c) if permitted, modifications must be published back to the source (3) reference/attribution back to the source must be perpetuated in copies and derivatives (4) if derivates are permitted, licensees may not charge for them (5) failure to abide by the terms of the licenses is a breach of the license. I have been working on a General Public License (which I'm happy to share with this list if anyone is interested) tailored specifically for schema in different namespaces. The main points follow: 1. There is a distinction between (a) Extended (b) Versioned and (c) Derivative schema. (a) Extended Schema: If schema A in namespace A is the original schema, then an extended schema is schema B used with schema A. There is no change to schema A or elements in namesapce A, but elements from namespace B are added. (b) Versioned Schema: A versioned schema is schema A in namespace A with changes made to it based on a policy or procedure acceptable to the owner(s) of schema A. An owner might be a company or a standards organization that owns schema A and wants to create a new version in a managed way. (c) Derivative Schema: A derivative schema is Schema A in namesapce A that has been altered. Under the general public license that I am writing (which could vary based on someone's needs) (a) Extended schema are permitted to be used with original schema provided that extended schema are published back to the owner(s). (Alternatively, extended schema could be permitted, with no requirement to publish back to the owner(s).) (b) Versioned schema are permitted, provided the owners agree. (c) Derivative schema are not permitted. The policy behind these conditions is that there is a need to extend and innovate to meet ever changing business needs, but this need should not interfere with interoperability and it should now allow people/organizations to copy schema that have taken real and sweat equity to produce. We do not want, for example, a return to the browser wars. Software vendors should not be able to change XHTML (or any other flavor of XML) on a whim. If a change needs to be made, then XHTML should be changed via a process and procedure acceptable to the W3C, the owner. However, if a developer wants to mix elements from a different namespace into XHTML, then I think most people would agree this should be allowed. Whether or not extended elements should be published back to the owners is probalby something to be decided on a case-by-case basis. Suppose Company A spends five years and a lot of money to create schema/namespace A and builds software around it. Company B comes along and in one month, uses and extends schema/namespace A with schema/namespace B and builds software around it. Company B now has a product that has more features in it (A + B) than Company A's product. The products are interoperable if Company A strips out elements/attribute in namespace B, but all of the features/information from B are lost. In this caes, Company A is quite reasonable is requring Company B to publish its schema for use by Company A. I would be interested in any comments you or others have on this topic. Thanks, Todd ========================================= Winchel "Todd" Vincent III Attorney and Technical Consultant Project Director, E-CT-Filing Project Georgia State University College of Law US Office: 404.651.4297 US Mobile: 404.822.4668 US Mobile: 859.489.8077 US Voice : 770.216.1633 US Fax : 770.216.1633 US Fax : 425.955.1526 AU Mobile: 011 61 0408 606 272 AU Fax : 011 61 2 9475 0147 Email : winchel@m... Web : http://e-ct-file.gsu.edu/ 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
