1

Consider Company ABC, which released a project as open-source under the LGPL. The code is in Java, with packages such as 'com.abc.project'.

I am interested in forking this project (which dates to 2005) to update the technology to modern tools. There will be massive changes to the code. The new project will be licensed under LGPL. Edit: this is a web application, and not a library, for what that's worth.

I'm not sure if I may (or should?) retain the same Java package structure (e.g. 'com.abc.project')?

I suspect that I may do so under LGPL, but I wonder about trademark infringement or otherwise implying an endorsement from the company without their consent.

Michael Easter
  • 23,733
  • 7
  • 76
  • 107
  • 1
    Well, if you're not sure, just ask the maintainers: it's much more about person-to-person communications than about legal texts: lawyers can find trademark infringement anywhere :) – alf Dec 14 '11 at 11:54
  • If you cannot commit to maintaining compatibility with the library you're working (and I feel “there will be significant changes to the code” implies this), you are essentially making a new library and it should be in a different namespace. – millimoose Dec 14 '11 at 12:08
  • I have edited to indicate (a) it is a web-app, not a library and (b) there will be massive changes. Regarding the 'close' vote, LGPL is a pre-existing tag on SO and this seems like a reasonable question. That said, I will migrate to Programmers if enough people vote in that direction. – Michael Easter Dec 14 '11 at 12:26
  • alf, Inerdial, very good points! – Michael Easter Dec 14 '11 at 12:27
  • 3
    I'm voting to close this question as off-topic because it is about licensing or legal issues, not programming or software development. [See here](http://meta.stackoverflow.com/questions/274963/questions-about-licensing/274964#274964) for details, and the [help] for more. – JasonMArcher Jun 03 '15 at 04:11

1 Answers1

2

The naming convention for packages says it should be based on your companies domain name, so regardless of other issues you should probably change it anyway. If you don't you'll run into issues when both your version and the original version are on the classpath.

If you are planning to redistribute your fork to others you should be clear about where it's from and avoid confusion. You do imply endorsement if you keep the name, but it's also confusing for the users of the library if they can't tell them apart when googling and in stacktraces. (If you're just creating a private fork with minor changes you could consider not to bother...)

AVee
  • 3,348
  • 17
  • 17