3 ms·

> Where is the actual license? OK I decided to actually look it up. Here it is: http://info.cern.ch/hypertext/WWW/Policy.html http://info.cern.ch/hypertext/WWW

> Where is the actual license? OK I decided to actually look it up. Here it is: http://info.cern.ch/hypertext/WWW/Policy.html http://info.cern.ch/hypertext/WWW/Policy.html "The definition of protocols such as HTTP and data formats such as HTML are in the public domain and may be freely used by anyone." So back when originally developed TBL seems to have felt the need to declare the public domain nature (implying to me that it was NOT an obvious default). > Writing books about your technology does not mean you somehow own the experience that people gain from reading them. I agree. The creation and design of the API is what allowed Sun to do that. The documentation is merely part of the why Google decided to copy Java and many of it's libraries rather than develop their own API or use a freely licensed one. [Edit: I didn't really mean to agree with "owning the experience" bit but it does give them some rights.] > Spending a lot of money does not entitle you to exert however much control you feel you deserve. Agree. Copyright gives specific rights and there are also fair use rights that should possibly be strengthened. > "Intellectual property" is a balance between the interests of creators and the interests of society. I largely agree. I would like it the case that I could fully agree but I don't think that balance currently exists (especially on copyright durations and I think for software the source should be published or escrowed and then released when copyright expires). I also don't like discussing "Intellectual property" as that leads to sloppy thinking and overbroad claims, it is better to discuss the specific types, patents, copyright, design patents, trademarks separately. The balance is also set by legislation and the judiciary should not have that much discretion (although they should have on fair use issues). > Giving first movers complete control over APIs, formats, and languages that become popular would enable a new wave of rent-seeking, very much like the patent trolling we see now. The trade off is the incentive to create and promote new platforms and the breadth of the right to implement them. For me this is an issue of fair use and competition law plus market solutions of people avoiding platforms where alternative implementations are not possible. There is a useful discussion to be had about fair use rights to copyrighted API's but I'm not sure the incompatible Dalvik would be fair use even if a compatible alternative was, we are deep in the grey area here. I would add as I have in other places that you need to consider how you would feel if it was old Sun in the Oracle role and MS in the Google role? Would this not be an egregious case of "embrace, extend extinguish"?

haberman 13y ago
> "The definition of protocols such as HTTP and data formats such as HTML are in the public domain and may be freely used by anyone." The definitions: I'm pretty sure this means that you can copy the documents themselves. This distinguishes it from standards documents by bodies like ISO where the standards documents themselves are copyright. Here's another example: in the SCO lawsuit against IBM, why did they not attempt to claim copyright infringement over APIs? That would have been a much easier case to make than copyright infringement of the code, as Linux does in fact "copy" the APIs of UNIX. Also, as another poster pointed out, if APIs were copyrightable then BSD UNIX would never have happened. > The trade off is the incentive to create and promote new platforms and the breadth of the right to implement them. No one would be incentivized to create platforms unless they could lock out competitors? WINE/ReactOS hasn't stopped Microsoft from developing the Windows API. Mono hasn't stopped them from developing .NET. Companies that create platforms get natural benefits from developing platforms: it puts them in a position of leadership and ahead of everybody else. > I would add as I have in other places that you need to consider how you would feel if it was old Sun in the Oracle role and MS in the Google role? Would this not be an egregious case of "embrace, extend extinguish"? Copyright law is not a tool for preventing anticompetitive business practices. It's not copyright's job to prevent "embrace, extend, extinguish." But if Microsoft (for example) decided to implement the Dart APIs as their development environment for apps on Windows Phone, I don't see the problem with that. "Embrace, extend, extinguish" would be if Google took a platform that already had a J2ME ecosystem and started distributing their own J2ME SDK that was targeted at the same developers and devices and introduced proprietary extensions that would make the Google-J2ME apps incompatible with the Oracle-J2ME apps.
- josephlord 13y ago
  SCO? They did. They just didn't own rights that had not already been given up by their predecessors. Check your BSD history. Various actions and omissions of copyright registration and explicit copyright notices which were then required led to the BSD settlement. I didn't say there could be no incentive without copyright but that it is part of the balance. .NET doesn't support the argument that much though, it could be seen as a counter reaction to losing the legal action over the J++ embrace, extend, extinguish attempt against Sun's Java. I see embrace, extend in a wider way but that isn't a key argument.

haberman 13y ago

> "The definition of protocols such as HTTP and data formats such as HTML are in the public domain and may be freely used by anyone." The definitions: I'm pretty sure this means that you can copy the documents themselves. This distinguishes it from standards documents by bodies like ISO where the standards documents themselves are copyright. Here's another example: in the SCO lawsuit against IBM, why did they not attempt to claim copyright infringement over APIs? That would have been a much easier case to make than copyright infringement of the code, as Linux does in fact "copy" the APIs of UNIX. Also, as another poster pointed out, if APIs were copyrightable then BSD UNIX would never have happened. > The trade off is the incentive to create and promote new platforms and the breadth of the right to implement them. No one would be incentivized to create platforms unless they could lock out competitors? WINE/ReactOS hasn't stopped Microsoft from developing the Windows API. Mono hasn't stopped them from developing .NET. Companies that create platforms get natural benefits from developing platforms: it puts them in a position of leadership and ahead of everybody else. > I would add as I have in other places that you need to consider how you would feel if it was old Sun in the Oracle role and MS in the Google role? Would this not be an egregious case of "embrace, extend extinguish"? Copyright law is not a tool for preventing anticompetitive business practices. It's not copyright's job to prevent "embrace, extend, extinguish." But if Microsoft (for example) decided to implement the Dart APIs as their development environment for apps on Windows Phone, I don't see the problem with that. "Embrace, extend, extinguish" would be if Google took a platform that already had a J2ME ecosystem and started distributing their own J2ME SDK that was targeted at the same developers and devices and introduced proprietary extensions that would make the Google-J2ME apps incompatible with the Oracle-J2ME apps.

josephlord 13y ago
SCO? They did. They just didn't own rights that had not already been given up by their predecessors. Check your BSD history. Various actions and omissions of copyright registration and explicit copyright notices which were then required led to the BSD settlement. I didn't say there could be no incentive without copyright but that it is part of the balance. .NET doesn't support the argument that much though, it could be seen as a counter reaction to losing the legal action over the J++ embrace, extend, extinguish attempt against Sun's Java. I see embrace, extend in a wider way but that isn't a key argument.